Après la fuite du code source de Claude Code, une véritable vulnérabilité critique vient d’être découverte dans Claude Code même par l’équipe Red Team d'Adversa AI. Claude Code intègre un système d’autorisations basé sur des règles d’autorisation (approbation automatique de commandes spécifiques), des règles de refus (blocage strict de commandes spécifiques) et des règles de demande (invite systématique). Cela semble correct et raisonnable. Le problème, cependant, est que les règles de refus peuvent être contournées. « Règles de refus, validateurs de sécurité, détection d’injection de commandes — tout est ignoré », écrit Adversa. Adversa prévient qu’un attaquant motivé pourrait intégrer des étapes de compilation d’apparence authentique dans le fichier CLAUDE.md d’un dépôt malveillant.Tout a commencé dans la nuit du 31 mars 2026. Un ingénieur d'Anthropic pousse une mise à jour de routine du paquet npm de Claude Code. Dans l'archive publiée se glisse un fichier source map ; un artefact de débogage de 59,8 mégaoctets dont la vocation première est de relier le code minifié et obfusqué à son code source original, pour faciliter l'identification des bogues en développement. En production, ce type de fichier n'a rien à faire dans un paquet distribué publiquement.
En quelques heures, l'erreur de configuration dans la pipeline de build a rendu publiques plus de 512 000 lignes de TypeScript constituant le cœur de Claude Code. Le chercheur en sécurité qui a découvert la fuite n'a eu qu'à suivre un lien dans un fichier de débogage pour accéder à l'intégralité du projet. Depuis, le dépôt GitHub de sauvegarde a été forké plus de 41 500 fois. La communauté des développeurs a désormais accès à la feuille de route d'une entreprise valorisée à 380 milliards de dollars.
C'est gênant, mais pas catastrophique pour Anthropic. L’essentiel est que les chercheurs peuvent voir comment Claude Code est censé fonctionner, mais ne peuvent pas le recréer, car la fuite n’inclut pas les poids du modèle Claude, les données d’entraînement, les données clients, les API ou les identifiants. Mais récemment, une véritable vulnérabilité critique vient d’être découverte dans Claude Code même par l’équipe Red Team d'Adversa AI.
Claude Code intègre un système d’autorisations basé sur des règles d’autorisation (approbation automatique de commandes spécifiques), des règles de refus (blocage strict de commandes spécifiques) et des règles de demande (invite systématique). Cela semble correct et raisonnable. Le problème, cependant, est que les règles de refus peuvent être contournées. « Le système d’autorisations constitue la principale barrière de sécurité entre l’agent IA et le système du développeur », rapporte Adversa. « Lorsqu’il échoue silencieusement, le développeur n’a aucun filet de sécurité. »
Le problème découle de la volonté d’Anthropic d’améliorer les performances après la découverte d’un problème de performance : des commandes composées complexes provoquaient le gel de l’interface utilisateur. Anthropic a résolu ce problème en limitant l'analyse à 50 sous-commandes, avec un repli vers une instruction générique « ask » pour tout le reste. Le commentaire du code indique : « Cinquante, c'est généreux : les commandes légitimes des utilisateurs ne s'étendent pas autant. Au-delà de cette limite, nous revenons à « ask » (valeur par défaut sûre — nous ne pouvons pas prouver la sécurité, donc nous demandons une confirmation). »
La faille découverte par Adversa réside dans le fait que ce processus peut être manipulé. L'hypothèse d'Anthropic ne tient pas compte des commandes générées par l'IA à partir d'une injection d'instruction générative (prompt), où un fichier CLAUDE.md malveillant ordonne à l'IA de générer un pipeline de plus de 50 sous-commandes qui ressemble à un processus de construction légitime. Si cela est fait, « comportement : « ask », // PAS « deny » » se produit immédiatement. « Règles de refus, validateurs de sécurité, détection d’injection de commandes — tout est ignoré », écrit Adversa. La 51e commande revient à « ask » comme prévu, mais l’utilisateur n’a aucune indication que toutes les règles de refus ont été ignorées.
Adversa prévient qu’un attaquant motivé pourrait intégrer des étapes de compilation d’apparence authentique dans le fichier CLAUDE.md d’un dépôt malveillant. Cela semblerait routinier, mais aucune analyse par sous-commande n’est effectuée lorsque le nombre dépasse 50. Cela pourrait permettre à l’attaquant d’exfiltrer des clés privées SSH, des identifiants AWS, des jetons GitHub, des jetons npm ou des secrets d’environnement. Cela pourrait conduire à un vol d’identifiants à grande échelle, à la compromission de la chaîne d’approvisionnement, à une violation de l’infrastructure cloud et à l’empoisonnement du pipeline CI/CD.
« Lors des tests, la couche de sécurité du LLM de Claude a détecté de manière autonome certaines charges utiles manifestement malveillantes et a refusé de les exécuter. Il s'agit là d'une bonne stratégie de défense en profondeur », écrit Adversa. « Cependant, la vulnérabilité du système d'autorisations existe indépendamment de la couche LLM : il s'agit d'un bug dans le code chargé d'appliquer la politique de sécurité. Une injection de prompt suffisamment bien conçue, qui apparaîtrait comme une instruction de compilation légitime, pourrait également contourner la couche LLM. »
L'incident, survenu le 31 mars 2026, révèle bien plus qu'une négligence de pipeline : il donne à voir, pour la première fois, l'architecture interne d'un agent de codage IA en production, ses fonctionnalités secrètes, ses mécanismes de protection et ses contradictions embarrassantes. Parmi les premières découvertes qui ont fait réagir la communauté, on trouve un mécanisme d'anti-distillation, « l'undercover mode » (Claude se fait passer pour un humain), ou encore KAIROS, l'agent autonome qui ne dort jamais. Cette fuite permet ainsi aux concurrents d'Anthropic d'anticiper.
Voici un extrait du rapport d'Adversa :
Vulnérabilité critique de Claude Code : les règles de refus sont contournées sans avertissement, car les contrôles de sécurité consomment trop de jetons
L'histoire en 60 secondes
En 1898, le cryptographe Auguste Kerckhoffs a établi un principe que tout professionnel de la sécurité apprend dès sa première semaine : un système doit rester sécurisé même si tous ses composants sont de notoriété publique. En 2026, Anthropic (le laboratoire de pointe en IA « sécurité d’abord », évalué à plusieurs milliards de dollars et qui se prépare actuellement à une introduction en bourse) a commercialisé un produit dont le modèle de sécurité s’effondre si l’on tape plus de 50 commandes à la suite.
- La vulnérabilité : Claude Code, l’agent de codage IA phare d’Anthropic qui exécute des commandes shell sur les machines des développeurs, ignore silencieusement les règles de refus de sécurité configurées par l’utilisateur lorsqu’une commande contient plus de 50 sous-commandes. Un développeur qui configure « ne jamais exécuter rm » verra rm bloqué lorsqu’il est exécuté seul, mais ce même rm s’exécute sans restriction s’il est précédé de 50 instructions inoffensives. La politique de sécurité disparaît silencieusement.
- Pourquoi cela existe : l’analyse de sécurité coûte des jetons. Les ingénieurs d’Anthropic ont rencontré un problème de performances : vérifier chaque sous-commande bloquait l’interface utilisateur et épuisait les ressources de calcul. Leur solution : arrêter la vérification après 50. Ils ont troqué la sécurité contre la vitesse. Ils ont troqué la sécurité contre le coût.
- Ce qui nous a choqués : la correction existe déjà dans le code source d’Anthropic. Leur nouveau parseur « tree-sitter » vérifie correctement les règles de refus, quelle que soit la longueur de la commande. Il est écrit. Il a été testé. Il se trouve dans le même référentiel. Il n’a jamais été appliqué au chemin de code livré aux clients. La version sécurisée a été construite ; elle n’a simplement pas été déployée.
- Pourquoi cela va au-delà d’un simple bug : c’est le principal compromis auquel l’ensemble du secteur des agents IA est sur le point d’être confronté. Dans l’IA agentique, l’application de la sécurité et la livraison du produit se disputent la même ressource : les jetons. Chaque vérification de règle de refus, chaque validation d'autorisation, chaque application des limites du bac à sable représente un coût d'inférence qui est prélevé sur le même budget que le travail de l'utilisateur. À l'heure actuelle, les jetons sont subventionnés par le capital-risque et les entreprises rognent déjà sur les coûts. Lorsque les subventions prendront fin et que chaque jeton sera soumis à une réelle pression sur les marges, l'incitation à ignorer les contrôles de sécurité s'aggravera, et non l'inverse. Anthropic vient de nous montrer à quoi ressemblera cet avenir.
La menace concrète : comment un dépôt malveillant vole vos identifiants
Il ne s’agit pas d’une vulnérabilité théorique. Le chemin d’attaque est pratique, réaliste et exploite un workflow que les développeurs effectuent des dizaines de fois par jour : cloner un dépôt open source et demander à leur assistant de codage IA de les aider à le construire.
Comment fonctionne l'attaque
- Étape 1 : L'attaquant crée un dépôt d'apparence légitime
L'attaquant publie ce qui semble être un outil open source, une bibliothèque ou un modèle de projet utile sur GitHub ou toute autre plateforme d'hébergement de code. Il comporte un fichier README, une licence, un nombre raisonnable d'étoiles (facilement achetées ou générées) et une structure de projet qui semble...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.