Anthropic, qui se positionne sur le principe de « la sécurité d'abord », voit son outil de développement phare, Claude Code, dont le bac à sable réseau n'a jamais été véritablement sécurisé pendant les cinq derniers mois.
Le chercheur en sécurité indépendant Aonan Guan (关傲男) a publié le 20 mai ses dernières recherches, révélant une seconde vulnérabilité de contournement complet dans le bac à sable réseau de Claude Code – une attaque par injection d'octet nul dans le protocole SOCKS5, permettant aux processus au sein du bac à sable d'accéder à n'importe quel hôte explicitement interdit par la politique de l'utilisateur. Cela signifie que depuis le lancement de la fonctionnalité de bac à sable en octobre 2025, pendant environ 5,5 mois et 130 versions publiées, chaque version de Claude Code a comporté une faille de sécurité permettant un contournement complet. Il s'agit du deuxième contournement complet de la même ligne de défense par le même chercheur.
La réponse d'Anthropic a été le silence : pas d'avis de sécurité, pas de numéro CVE, pas de notification aux utilisateurs. La vulnérabilité a été corrigée silencieusement dans la version du 1er avril, les notes de mise à jour ne mentionnant aucun contenu lié à la sécurité. En d'autres termes, un utilisateur fonctionnant toujours sur une ancienne version n'a aucun moyen de savoir que son bac à sable configuré était inefficace depuis le début.
Deux clés pour la même porte
Claude Code est un assistant de programmation IA lancé par Anthropic début 2025, se positionnant comme « l'ingénieur IA résidant dans le terminal ». Contrairement aux complétions de code conversationnelles traditionnelles, Claude Code dispose des autorisations de lecture/écriture sur le référentiel de code de l'utilisateur et de la capacité d'exécuter des commandes, pouvant accomplir de manière autonome une série d'opérations comme naviguer dans le code, éditer des fichiers, exécuter des tests. Cette implication profonde implique également un risque de sécurité très élevé – si le modèle est détourné par une attaque par injection d'invites, l'attaquant obtiendra une capacité équivalente aux permissions du terminal de l'utilisateur, incluant la lecture des variables d'environnement locales, l'exécution de commandes système arbitraires, l'accès aux ressources réseau internes, etc.
Pour équilibrer sécurité et efficacité, Anthropic a introduit en octobre 2025 la fonctionnalité de bac à sable réseau (v2.0.24), permettant aux utilisateurs de définir une liste blanche de domaines via un fichier de configuration, limitant 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 pourra accéder qu'à Google et ses sous-domaines, tout autre trafic étant bloqué. La documentation officielle promet clairement : « Un tableau vide équivaut à interdire tout accès réseau. »
Ce mécanisme est implémenté par un proxy SOCKS5 : l'environnement d'exécution du bac à sable de bas niveau (@anthropic-ai/sandbox-runtime) démarre un serveur proxy, les processus à l'intérieur du bac à sable n'établissent pas directement de connexions réseau mais les font transiter par le proxy, qui applique le filtrage par nom de domaine en fonction de la liste blanche configurée par l'utilisateur dans settings.json. Le mécanisme de bac à sable au niveau du système d'exploitation – sandbox-exec de macOS, bubblewrap de Linux – restreint correctement l'agent aux adresses locales (bouclage), la décision de sortie étant entièrement déléguée à ce proxy SOCKS5.
Diagramme d'architecture du bac à sable Claude Code présenté sur le blog officiel d'Anthropic – les commandes utilisateur transitent via les proxys SOCKS/HTTP filtrants avant d'atteindre le bac à sable, les opérations sur fichiers et l'accès réseau à l'intérieur du bac à sable sont soumis à un contrôle strict des permissions.
Le problème réside dans l'implémentation de ce proxy. Deux recherches de sécurité indépendantes ont prouvé qu'il peut être entièrement contourné.
La chronologie révèle un problème plus profond : la version v2.0.55 publiée le 26 novembre 2025 a corrigé le premier contournement, mais le second contournement existait depuis le premier jour du bac à sable, cette version le contenait toujours. Les deux vulnérabilités se chevauchent dans le temps ; du premier jour du bac à sable jusqu'à la correction de la dernière vulnérabilité, aucune version n'était sécurisée. Anthropic affirme sur son blog officiel que le bac à sable « garantit que même en cas d'injection d'invites, l'impact est entièrement isolé », mais l'existence de ces deux contournements contredit directement cette promesse.
« Un rapport externe, c'est de la chance. Deux, c'est un problème de qualité d'implémentation. » – indique le rapport de recherche de Guan Aonan.
Un contournement complet avec un octet nul
Le principe technique du deuxième contournement n'est pas complexe, mais l'intégrité de la chaîne d'attaque mérite l'attention.
L'utilisateur configure une liste blanche réseau, par exemple n'autoriser que l'accès à *.google.com. Lorsque le proxy SOCKS5 de Claude Code reçoit une requête de connexion, il utilise la méthode JavaScript endsWith() pour effectuer une correspondance par suffixe sur le nom d'hôte. L'attaquant n'a qu'à insérer un octet nul dans le nom d'hôte – en construisant une chaîne de type attacker-host.com\x00.google.com. JavaScript traite l'octet nul comme un caractère UTF-16 ordinaire, endsWith(".google.com") retourne true, le proxy autorise. Mais lorsque la même chaîne est transmise à la fonction C de bas niveau getaddrinfo() pour la résolution DNS, l'octet nul est interprété comme un terminateur de chaîne, ce qui résout en réalité attacker-host.com. Les mêmes octets, deux couches de code donnent deux interprétations. Le filtre pense que vous accédez à Google, le résolveur DNS sait que vous vous connectez au serveur de l'attaquant.
Cela relève de l'attaque classique de « divergence d'interprétation » (parser differential), de la même catégorie technique que le « HTTP request smuggling » découvert en 2005 (CWE-158 / CWE-436). Son essence est que lorsqu'un même flux de données traverse deux composants ayant des règles d'interprétation sémantique différentes, l'attaquant peut exploiter cette divergence pour qu'une couche fasse un jugement « sûr » tandis qu'une autre exécute une opération « dangereuse ». Ce type de vulnérabilité apparaît de manière récurrente dans le domaine de la sécurité réseau, la leçon clé reste la même : tout passage de chaîne de caractères franchissant une frontière de confiance doit être soumis à une normalisation et validation strictes, et non se fier aux vérifications effectuées par la couche supérieure.
Guan Aonan a réalisé la reproduction de la vulnérabilité avec deux scripts Node.js minimaux : un script de contrôle utilisant un nom d'hôte ordinaire initiant une connexion SOCKS5, retournant BLOCKED ; un script d'attaque injectant un octet nul dans le nom d'hôte, retournant BYPASSED rep=0x00 – ce dernier signifiant que le proxy a établi la connexion avec succès, le canal sortant est ouvert. Claude Code lui-même a confirmé ce résultat.
Reproduction complète de la vulnérabilité en quatre étapes annotées en rouge dans Claude Code v2.1.86 – confirmation de la politique, blocage normal, contournement par octet nul, confirmation par Claude lui-même.
Et ce contournement de bac à sable, combiné à l'attaque par injection d'invites « commentaire et contrôle » divulguée par Guan Aonan en avril, constitue une chaîne d'attaque complète (voir : Trois couches de défense ne suffisent pas, un simple titre de PR peut voler votre clé API : une faille de sécurité des agents IA réapparaît). La recherche « commentaire et contrôle » avait déjà prouvé que trois outils de programmation IA présentaient une surface d'attaque par injection d'invites, mais les points d'entrée diffèrent : pour Claude Code, uniquement via le titre de PR ; pour Gemini CLI, via les commentaires ou corps d'issue ; pour Copilot Agent, en utilisant des commentaires HTML pour une injection discrète. Dans le cas de Claude Code, son titre de PR est directement concaténé au modèle d'invite, sans filtrage ni échappement, le modèle ne peut distinguer l'intention humaine de l'injection malveillante.
En combinant les deux – une instruction cachée forçant l'agent à exécuter du code d'attaque dans le bac à sable, une injection d'octet nul contournant le blocage réseau – les clés API dans les variables d'environnement, les identifiants AWS, les jetons GitHub, les données d'endpoints API internes, etc., peuvent toutes être exfiltrées vers n'importe quel serveur sur Internet. Les données sortent via le proxy SOCKS5 lui-même, l'attaque ne nécessite aucun serveur relais externe, alors que ce proxy est précisément le composant que l'utilisateur fait confiance comme frontière de sécurité. L'attaquant n'a même pas besoin d'autorisations d'écriture sur le dépôt, il suffit de soumettre une issue publique. Les réviseurs humains voient une demande de collaboration normale dans la vue de rendu GitHub, l'agent IA analyse quant à lui le code source malveillant complet.
Même Claude reconnaît : la faille est réelle
Un détail clé de cette divulgation provient de Claude Code lui-même. Guan Aonan a directement donné le code de reproduction de la vulnérabilité à Claude Code, lui demandant de porter un jugement technique. Claude Code, après avoir exécuté le test de contrôle (nom d'hôte normal bloqué) et le test d'attaque (nom d'hôte avec octet nul contournant le blocage), a donné une conclusion claire :
« This is a real bypass of the network sandbox filter, not just a test artifact. You should report this to Anthropic at https://github.com/anthropics/claude-code/issues. » (« Il s'agit d'un véritable contournement du filtre du bac à sable réseau, pas seulement d'un artefact de test. Vous devriez signaler ce problème à Anthropic. »)
Le produit testé a lui-même confirmé la réalité et la gravité de la vulnérabilité, allant jusqu'à indiquer la voie de signalement. Ce détail a été intégralement consigné dans le rapport de recherche de Guan Aonan et est à l'origine du titre de l'article de The Register – « Even Claude agrees hole in its sandbox was real and dangerous » (Même Claude reconnaît que le trou dans son bac à sable était réel et dangereux).
Couverture de la recherche de Guan Aonan – Claude Code, après s'être vu présenter sa propre vulnérabilité, reconnaît « Il s'agit d'un véritable contournement du filtre du bac à sable réseau », la phrase de confirmation clé est encadrée en rouge.
La réponse d'Anthropic et cinq mois de silence
La vulnérabilité en elle-même est préoccupante, mais la manière dont Anthropic l'a traitée mérite un examen par l'industrie.
Guan Aonan a soumis début avril 2026 via le programme de primes aux bugs HackerOne (rapport #3646509) un rapport détaillé sur le deuxième contournement du bac à sable. La réponse initiale d'Anthropic a été :
« Thank you for your report. After reviewing this submission, we've determined it's a duplicate of an existing internal report we're already tracking. » (« Merci pour votre rapport. Après examen de cette soumission, nous avons déterminé qu'il s'agit d'un doublon d'un rapport interne existant que nous suivons déjà. »)
Le rapport a été immédiatement fermé. Lorsque Guan Aonan a demandé des informations sur un éventuel numéro CVE, Anthropic a répondu le 7 avril :
« We have not yet decided whether a CVE will be published for this issue and can't share a timeline on that decision. » (« Nous n'avons pas encore décidé si un numéro CVE sera publié pour ce problème et ne pouvons partager de calendrier pour cette décision. »)
Par la suite, la vulnérabilité a été corrigée silencieusement dans la version v2.1.90. Aucun avis de sécurité, aucun numéro CVE, la page de conseils de sécurité Claude Code ne contient aucune entrée, les notes de mise à jour ne mentionnent aucune description liée à la sécurité. Un contournement complet existant depuis le premier jour du bac à sable, durant 5,5 mois, couvrant environ 130 versions, est pour les utilisateurs comme s'il n'était jamais arrivé.
Ce mode de traitement n'est pas une première. La réponse au premier contournement (CVE-2025-66479) a été presque identique : Anthropic a attribué le CVE uniquement à la bibliothèque sous-jacente @anthropic-ai/sandbox-runtime (score CVSS seulement 1.8, « Faible »), et non au produit utilisateur Claude Code ; les notes de mise à jour indiquaient « Fixed proxy DNS resolution » (correction de la résolution DNS du proxy), sans mention de vulnérabilité de sécurité. Guan Aonan écrit dans son rapport de recherche : « Lorsque React Server Components a eu une grave vulnérabilité, React et Next.js ont chacun obtenu des CVE indépendants, Meta et Vercel ont tous deux publié des avis de sécurité, les deux communautés ont été pleinement informées. Anthropic a choisi une approche différente. » À ce jour, une recherche « Claude Code Sandbox CVE » ne donne toujours aucun avis de sécurité officiel.
Pour traiter le problème du vol de credentials, Anthropic a choisi de bloquer la commande ps, mais l'approche par liste noire est intrinsèquement insuffisante – bloquer une commande, l'attaquant a d'innombrables chemins alternatifs. La bonne pratique est de déclarer explicitement de quels outils l'agent a besoin. Dans la recherche « commentaire et contrôle », Anthropic a bien rehaussé la gravité de la vulnérabilité à CVSS 9.4 (niveau Critique) et l'a transférée dans son programme privé de primes, un porte-parole a toutefois déclaré que « l'outil n'a pas été conçu pour être durci contre les injections d'invites ». Le fabricant fait par défaut confiance aux capacités de sécurité du modèle lui-même, mais manque de défense en profondeur au niveau de l'architecture système ; lorsque des vulnérabilités exposent ce manque, les « limites de conception » deviennent une catégorie commode – elles reconnaissent le problème tout en s'exonérant dans une certaine mesure de l'obligation de publier un avis de sécurité.
Le panorama plus large de l'industrie est que le même problème ne se limite pas à Anthropic. Dans la recherche « commentaire et contrôle » divulguée en avril, Gemini CLI de Google et Copilot Agent de Microsoft GitHub ont tous deux été confirmés comme présentant la même surface d'attaque, les trois entreprises ont toutes confirmé et corrigé, mais aucune n'a publié d'avis de sécurité ou de numéro CVE. Anthropic a payé une prime de 100 dollars, Google a payé 1337 dollars, GitHub a initialement fermé le rapport avec « problème connu, non reproductible », puis, après avoir reçu des preuves de rétro-ingénierie, l'a clôturé avec l'étiquette « informatif » et a versé 500 dollars. Total : 1937 dollars – alors que ces trois produits couvrent la grande majorité des entreprises du Fortune 100.
Un faux sentiment de sécurité est plus dangereux que l'absence de mesures de sécurité. Les utilisateurs sans bac à sable savent qu'ils n'ont pas de frontière ; les utilisateurs avec un bac à sable défectueux pensent en avoir une. Une équipe exécutant Claude Code avec une liste blanche de domaines configurée, pendant 5,5 mois, ignorante du risque, après mise à jour verra dans les notes de mise à jour et conclura : le bac à sable a toujours fonctionné normalement. De plus, lorsque la vulnérabilité est divulguée, l'absence d'avis de sécurité signifie que les utilisateurs ne peuvent déterminer s'ils ont été affectés, et manquent de bases pour un audit rétrospectif.
Face à cette situation, la communauté de sécurité commence à former un consensus : ne pas concentrer la confiance de manière unique sur l'implémentation du bac à sable du fabricant. Le proxy SOCKS5 de Claude Code est construit sur un package npm tiers n'ayant que 10 étoiles GitHub, dont le dernier commit date de juin 2024, la frontière de sécurité traverse deux environnements d'exécution (JavaScript et C), mais manque au point de jonction de confiance du traitement de normalisation le plus basique. La fonction isValidHost() ajoutée dans le correctif – chargée de rejeter les octets nuls, l'encodage pourcentage, les CRLF et autres caractères illégaux – aurait dû exister depuis le premier jour du bac à sable. Guan Aonan propose un cadre de défense pragmatique – considérer l'agent IA comme un super-employé devant suivre le principe du moindre privilège, l'essentiel étant une défense multicouche :
Une réputation de sécurité se construit sur la transparence de chaque divulgation et de chaque correctif, et non sur un récit de marque. Lorsque les utilisateurs, sur la base de la confiance, confient leurs identifiants à un agent, le fabricant a l'obligation de s'assurer que la ligne de défense est efficace, et aussi l'obligation d'informer en temps opportun en cas de défaillance. Sur ces deux points, Anthropic a échoué avec le bac à sable de Claude Code.
« Le pire résultat d'un bac à sable n'est pas ce qu'il empêche, mais le faux sentiment de sécurité qu'il donne. Publier un bac à sable avec des vulnérabilités est pire que de ne pas publier de bac à sable du tout. » – indique Guan Aonan.
(Cet article a été publié pour la première fois sur l'application Titanium Media, auteur | Silicon Valley Tech_news, éditeur | Jiao Yan)
Références :
1. oddguan.com — Second Time, Same Sandbox: Another Anthropic Claude Code Network Sandbox Bypass Enables Data Exfiltration (Aonan Guan, 20.05.2026)
2. The Register — Even Claude agrees hole in its sandbox was real and dangerous (20.05.2026)
