L'outil de programmation AI Claude Code découvert avec une vulnérabilité de sécurité majeure

Anthropic, positionné comme « sécurité d'abord », a eu un sandbox réseau pour son outil de développement principal, Claude Code, qui n'a jamais été véritablement sécurisé au cours des cinq derniers mois.

Le chercheur en sécurité indépendant Aonan Guan a publié le 20 mai une nouvelle étude révélant une deuxième faille complète permettant de contourner le sandbox réseau de Claude Code : une attaque par injection de byte nul dans le protocole SOCKS5, permettant aux processus à l'intérieur du sandbox d'accéder à n'importe quel hôte explicitement interdit par la stratégie utilisateur. Cela signifie que depuis le déploiement de la fonctionnalité sandbox en octobre 2025 — soit environ 5,5 mois et 130 versions publiées — chaque version de Claude Code présente une faille de sécurité complètement contournable. Il s'agit du deuxième contournement complet de la même défense par le même chercheur.

La réponse d'Anthropic a été le silence : aucune notification de sécurité, aucun numéro CVE, aucune notification aux utilisateurs. La vulnérabilité a été corrigée silencieusement dans la version du 1er avril, sans aucune mention dans les notes de mise à jour. Autrement dit, un utilisateur encore en cours d'exécution d'une version ancienne n'avait aucun moyen de savoir que son sandbox était dès le départ inopérant.

Claude Code est un assistant de programmation IA lancé par Anthropic au début de 2025, positionné comme un « ingénieur IA intégré au terminal ». Contrairement aux complétions de code basées sur des discussions traditionnelles, Claude Code possède des autorisations en lecture et en écriture sur la base de code de l'utilisateur ainsi que la capacité d'exécuter des commandes, lui permettant d'accomplir de manière autonome des tâches telles que la navigation dans le code, l'édition de fichiers et l'exécution de tests. Cette intégration approfondie implique un risque de sécurité extrêmement élevé — si le modèle est compromis par une attaque d'injection de prompts, l'attaquant obtiendra les mêmes privilèges que l'utilisateur sur le terminal, y compris la lecture des variables d'environnement locales, l'exécution de commandes système arbitraires et l'accès aux ressources du réseau interne.

Afin d'équilibrer sécurité et efficacité, Anthropic a introduit en octobre 2025 la fonction de sandbox réseau (v2.0.24), permettant aux utilisateurs de définir une liste blanche de domaines via un fichier de configuration, limitant ainsi l'accès réseau externe de l'environnement d'exécution de l'IA. Par exemple, après avoir configuré allowedDomains: [“*.google.com”], Claude Code ne peut accéder qu'à Google et ses sous-domaines, tous les autres trafics étant bloqués. La documentation officielle promet explicitement : « Un tableau vide équivaut à interdire tout accès réseau. »

Ce mécanisme est implémenté par un proxy SOCKS5 : le runtime de sandbox sous-jacent (@anthropic-ai/sandbox-runtime) démarre un serveur proxy, et les processus à l'intérieur du sandbox n'établissent pas de connexions réseau directes, mais les transmettent via le proxy, qui applique un filtrage de domaines selon la liste blanche configurée par l'utilisateur dans settings.json. Les mécanismes de sandbox au niveau du système d'exploitation — sandbox-exec sous macOS et bubblewrap sous Linux — limitent correctement l'Agent à l'adresse de boucle locale, tandis que les décisions de sortie sont entièrement déléguées à ce proxy SOCKS5.

Le schéma d'architecture de l'environnement isolé Claude Code présenté sur le blog officiel d'Anthropic — les commandes utilisateur passent par un proxy SOCKS/HTTP avant d'atteindre l'environnement isolé, où les opérations sur les fichiers et l'accès réseau sont strictement contrôlés par des autorisations.

Le problème réside dans la mise en œuvre de ce proxy. Deux études de sécurité indépendantes ont prouvé qu'il peut être entièrement contourné.

La chronologie révèle des problèmes plus profonds : la version v2.0.55 publiée le 26 novembre 2025 a corrigé la première contournement, mais la deuxième contournement existait dès le premier jour du déploiement du sandbox et était toujours présente dans cette version. Les deux vulnérabilités se chevauchent dans la chronologie : du premier jour du déploiement de la fonction sandbox jusqu’à la correction de la dernière vulnérabilité, aucune version n’était sécurisée. Anthropic a déclaré sur son blog officiel que le sandbox « garantit que même en cas d’injecton de prompt, les impacts restent entièrement isolés », mais la présence de ces deux contournements contredit directement cette promesse.

« Un rapport externe est de la chance. Deux, c’est un problème de qualité de mise en œuvre. » — indique l’étude de Guan Aonan.

Le principe technique du deuxième contournement n'est pas compliqué, mais l'intégrité de la chaîne d'attaque mérite attention.

L'utilisateur a configuré une liste blanche réseau, par exemple en autorisant uniquement l'accès à *.google.com. Le proxy SOCKS5 de Claude Code effectue une correspondance de suffixe sur le nom d'hôte à l'aide de la méthode JavaScript endsWith(). Un attaquant peut simplement insérer un octet nul dans le nom d'hôte — en construisant une chaîne de la forme attacker-host.com\x00.google.com. JavaScript traite l'octet nul comme un caractère UTF-16 ordinaire, et endsWith(".google.com") retourne true, ce qui permet au proxy d'autoriser la connexion. Toutefois, lorsqu'il est transmis à la fonction C sous-jacente getaddrinfo() pour la résolution DNS, l'octet nul est interprété comme un caractère de fin de chaîne, et le nom réellement résolu est attacker-host.com. Les mêmes octets sont interprétés différemment par deux couches de code. Le filtre pense que vous accédez à Google, tandis que le résolveur DNS sait que vous vous connectez à un serveur d'attaquant.

Il s'agit d'une attaque classique de « différences de parseur », appartenant à la même catégorie technologique que le smuggling de requêtes HTTP découvert en 2005 (CWE-158 / CWE-436). Son principe repose sur le fait que, lorsqu'un même flux de données traverse deux composants ayant des règles d'interprétation sémantique différentes, un attaquant peut exploiter cette divergence pour faire en sorte qu'un niveau effectue une décision « sécurisée », tandis qu'un autre niveau exécute une opération « dangereuse ». Ce type de vulnérabilité réapparaît fréquemment dans le domaine de la cybersécurité, et la leçon fondamentale reste toujours la même : tout passage de chaînes à travers une frontière de confiance doit faire l'objet d'une normalisation et d'une validation rigoureuses, et non pas être supposé déjà vérifié par le niveau supérieur.

Guan Aonan a reproduit la vulnérabilité en utilisant deux scripts Node.js minimisés : le script de contrôle établit une connexion SOCKS5 avec un nom d'hôte normal et reçoit BLOCKED ; le script d'attaque injecte un octet nul dans le nom d'hôte et reçoit BYPASSED rep=0x00 — ce dernier indique que le proxy a établi avec succès la connexion et que le canal sortant est ouvert. Claude Code a lui-même confirmé ce résultat.

Reproduction complète des quatre étapes marquées en rouge dans Claude Code v2.1.86 — confirmation de la stratégie, blocage normal, contournement par octet nul, confirmation par Claude lui-même

Ce contournement de sandbox, combiné à l’attaque par injection de prompts « Commentaires et contrôle » révélée par Guan Aonan en avril, constitue une chaîne d’attaque complète (voir : Trois couches de défense ne suffisent pas, un titre de PR suffit à voler votre clé API : la faille de sécurité des agents IA se manifeste à nouveau). L’étude « Commentaires et contrôle » a démontré que les trois outils de programmation IA présentent des surfaces d’injection de prompts, mais avec des points d’entrée différents : Claude Code n’est vulnérable que par le titre de la PR, Gemini CLI par les commentaires ou le corps des issues, tandis que Copilot Agent exploite les commentaires HTML pour une injection discrète. Avec Claude Code, le titre de la PR est directement concaténé au modèle de prompt, sans filtrage ni échappement, empêchant le modèle de distinguer l’intention humaine de l’injection malveillante.

Combiner les deux — une instruction cachée permettant à l’Agent d’exécuter du code d’attaque dans un sandbox, une injection de octets nuls pour contourner la censure réseau — les clés API, les identifiants AWS, les jetons GitHub, les données de points de terminaison API internes, etc., présents dans les variables d’environnement, peuvent être exfiltrés vers n’importe quel serveur sur Internet. Les données s’écoulent directement via le proxy SOCKS5 lui-même, sans nécessiter de serveur externe comme intermédiaire, alors que ce proxy est précisément considéré par l’utilisateur comme un composant de confiance et une limite de sécurité. L’attaquant n’a même pas besoin de droits d’écriture sur le dépôt ; il suffit de soumettre une Issue publique. Les examinateurs humains voient, dans l’affichage rendu par GitHub, une demande de collaboration normale, tandis que l’Agent IA interprète le code source complet et malveillant.

Un détail clé de cette divulgation provient de Claude Code lui-même. Guan Aonan a directement fourni le code de reproductibilité de la vulnérabilité à Claude Code pour qu'il en fasse une analyse technique. Après avoir exécuté un test de contrôle (le nom d'hôte normal était bloqué) et un test d'attaque (le nom d'hôte avec un octet nul contournait le blocage), Claude Code a fourni une conclusion claire :

Ceci est une contournement réel du filtre de sandbox réseau, pas seulement un artefact de test. Vous devriez signaler cela à Anthropic à l’adresse https://github.com/anthropics/claude-code/issues.

Le produit testé a lui-même confirmé l'authenticité et la gravité de la vulnérabilité, voire a activement fourni le chemin de signalement. Ce détail a été intégralement documenté par Guan Aonan dans le rapport d'étude et est devenu la source du titre de l'article du The Register : « Even Claude agrees hole in its sandbox was real and dangerous ».

Couverture de l'étude de Guan Aonan — Claude Code, après avoir été exposé à ses propres vulnérabilités, reconnaît : « Il s'agit d'une contournement réel du filtre de sandbox réseau », avec une zone rouge soulignant la déclaration clé de confirmation

Le vulnérabilité elle-même est préoccupante, mais la manière dont Anthropic l'a gérée mérite une attention plus grande de la part de l'industrie.

Guan Aonan a soumis, début avril 2026, un rapport détaillé sur une contournement de sandbox via le programme de récompenses de vulnérabilités HackerOne (rapport n°#3646509) à Anthropic. La réponse initiale d'Anthropic était :

Merci pour votre rapport. Après examen de cette soumission, nous avons déterminé qu'il s'agit d'une duplication d'un rapport interne existant que nous suivons déjà.

Le rapport a été fermé immédiatement. Lorsque Guan Aonan a demandé des précisions sur le plan de numéro CVE, Anthropic a répondu le 7 avril :

Nous n’avons pas encore décidé s’il sera publié un CVE pour ce problème et ne pouvons pas fournir de calendrier concernant cette décision.

Ce bogue a été corrigé en silence dans la version v2.1.90. Aucun avis de sécurité, aucun numéro CVE, aucune entrée sur la page de recommandations de sécurité de Claude Code, et aucune mention dans les journaux de mise à jour. Une contournement complet, présent depuis le premier jour du déploiement en sandbox et ayant duré 5,5 mois, couvrant environ 130 versions, a semblé ne jamais s'être produit pour les utilisateurs.

Ce modèle de traitement n'est pas nouveau. La première contournement (CVE-2025-66479) a été géré de manière presque identique : Anthropic n'a attribué le CVE qu'à la bibliothèque sous-jacente @anthropic-ai/sandbox-runtime (score CVSS de seulement 1,8, « Faible »), et non au produit destiné aux utilisateurs Claude Code ; les notes de mise à jour mentionnent uniquement « Fixed proxy DNS resolution » (Correction de la résolution DNS du proxy), sans faire référence à une vulnérabilité de sécurité. Guan Aonan a écrit dans son rapport d'étude : « Lorsqu'une vulnérabilité grave a été découverte dans les React Server Components, React et Next.js ont chacun reçu un CVE distinct, Meta et Vercel ont publié des avis de sécurité, et les deux communautés ont été pleinement informées. Anthropic a choisi une approche différente. » À ce jour, une recherche sur « Claude Code Sandbox CVE » ne permet toujours pas de trouver aucun avis de sécurité officiel.

Lors de la gestion des vols d'identifiants, Anthropic a choisi de bloquer la commande ps, mais cette approche par liste noire est fondamentalement limitée — bloquer une commande ne fait que pousser les attaquants vers d'innombrables alternatives. La bonne pratique consiste à définir clairement quels outils l'Agent a besoin d'utiliser. Dans l'étude « Commentaires et contrôle », Anthropic a relevé la gravité du vulnérabilité à CVSS 9,4 (niveau Critique) et l'a transférée à un programme de récompenses privé, mais un porte-parole a déclaré que « cet outil n'a pas été conçu pour se protéger contre les injections de prompts ». Les fabricants supposent par défaut que leur modèle de confiance est sécurisé, tout en manquant de défense en profondeur au niveau de l'architecture système ; lorsque des vulnérabilités révèlent cette lacune, « limitation de conception » devient une catégorie pratique — elle reconnaît le problème tout en exonérant partiellement l'obligation de publier un avis de sécurité.

Le paysage industriel plus large montre que ce problème ne concerne pas uniquement Anthropic. Dans une étude révélée en avril intitulée « Comments and Control », il a été démontré que Gemini CLI de Google et Copilot Agent de GitHub de Microsoft partagent la même surface d'attaque. Les trois entreprises ont confirmé et corrigé la vulnérabilité, mais aucune n'a publié d'avis de sécurité ni de numéro CVE. Anthropic a versé une récompense de 100 dollars, Google de 1337 dollars, et GitHub a initialement fermé le rapport en le qualifiant de « problème connu, non reproductible » ; après réception de preuves d'ingénierie inverse, il a clos le rapport avec l'étiquette « informatif » et versé 500 dollars. Au total, 1937 dollars — alors que ces trois produits couvrent la majorité des entreprises du Fortune 100.

Un faux sentiment de sécurité est plus dangereux qu'aucune mesure de sécurité. Les utilisateurs sans sandbox savent qu'ils n'ont pas de limites ; les utilisateurs avec un sandbox défectueux pensent qu'ils en ont un. Une équipe exécutant Claude Code et configurant une liste blanche de domaines n'a été aucune conscience du risque pendant 5,5 mois et, après la mise à jour, en consultant les journaux de mise à jour, elle a conclu que le sandbox fonctionnait normalement. De plus, lorsqu'une vulnérabilité a été révélée, l'absence d'avis de sécurité a empêché les utilisateurs de déterminer s'ils avaient été affectés et a supprimé toute base pour une audit rétroactif.

Face à cette situation, la communauté de sécurité commence à atteindre un consensus : il ne faut pas concentrer la confiance uniquement sur l’implémentation de sandbox du fabricant. Le proxy SOCKS5 de Claude Code repose sur un package npm tiers n’ayant que 10 stars sur GitHub, avec sa dernière contribution datant de juin 2024 ; sa frontière de sécurité s’étend entre deux environnements d’exécution, JavaScript et C, mais manque de traitement normalisé fondamental à l’endroit où la confiance se croise. La fonction isValidHost() ajoutée dans le correctif — chargée de rejeter les caractères illégaux tels que les octets nuls, l’encodage pourcent, les CRLF — aurait dû exister dès le premier jour du déploiement du sandbox. Guan Aonan propose un cadre de défense pragmatique — considérer l’agent IA comme un super-employé soumis au principe du moindre privilège, avec pour cœur la défense en couches :

La réputation de sécurité repose sur la transparence de chaque divulgation et de chaque correctif, et non sur un récit de marque. Lorsque les utilisateurs confient leurs identifiants à un agent sur la base de la confiance, le fabricant a l'obligation de garantir l'efficacité des mesures de protection, ainsi que d'informer rapidement en cas de défaillance. Anthropic n'a pas respecté ces deux points sur le sandbox Claude Code.

« Le pire résultat d’un sandbox n’est pas d’avoir empêché quelque chose, mais d’avoir donné aux gens un faux sentiment de sécurité. Publier un sandbox vulnérable est pire que de ne pas en publier du tout. » — a déclaré Guan Aonan.

(Cet article est publié en premier sur l'application TiMai, auteur |硅谷Tech_news, éditeur |焦燕)

Références :

1. oddguan.com — Deuxième fois, même sandbox : une autre contournement de la sandbox du réseau Claude Code d'Anthropic permet l'exfiltration de données (Aonan Guan, 2026.05.20)

2. The Register — Même Claude admet que la faille dans son environnement isolé était réelle et dangereuse (2026.05.20)