Le mode automatique de Claude Code exécute un binaire appartenant à l’attaquant lors de l’analyse des bibliothèques tierces. Une seule charge utile suffit pour faire tomber quatre modèles.
Imaginez demander à un agent d’examiner une bibliothèque de tiers. Il lit le dépôt. Il y détecte un binaire. Puis, il exécute ce binaire sur l’hôte. C’est exactement ce que l’AI Now Institute a démontré avec Claude Code en mode automatique. La preuve de concept porte le nom Friendly Fire. Elle transforme une révision de code routinière en exécution de code à distance, c’est-à-dire une RCE complète sur la machine qui héberge l’agent.
Le détail qui fait peur est la simplicité. En effet, l’attaque ne nécessite ni hooks, ni compétences, ni plugins, ni serveurs MCP. Elle ne requiert pas non plus de fichier de configuration personnalisé. Par conséquent, la surface d’exposition vit déjà dans la configuration par défaut.
Quelles versions et quels modèles sont ciblés
L’attaque vise la CLI standard de Claude Code dans les versions 2.1.116 à 2.1.199. De plus, elle fonctionne avec Sonnet 4.6, Sonnet 5 et Opus 4.8 en mode automatique. Il en va de même pour la CLI de Codex 0.142.4 avec GPT-5.5 en révision automatique. En clair, deux fournisseurs et quatre générations de modèles tombent sous une unique charge utile.
Comment Friendly Fire trompe l’agent étape par étape
Le scénario est simple. D’abord, les chercheurs ont placé une copie modifiée de la bibliothèque geopy sur le disque. Puis, ils ont donné une instruction unique en langage naturel : testez la sécurité de ce chemin. Ensuite, l’agent commence à explorer le dépôt. Puis, il lit une documentation qui présente un script d’assistance utile pour les vérifications de sécurité. Immédiatement, il inspecte un binaire qui semble appuyé par un code correspondant. Enfin, il exécute le binaire, car la documentation s’inscrit dans la tâche de révision d’origine. Ainsi, le code de l’attaquant s’exécute sur l’hôte.
Pourquoi l’analyse statique reste silencieuse
Là se trouve le point aveugle. Aucune fonction légitime de la bibliothèque n’appelle le script ou le binaire. Par conséquent, les vérifications statiques traditionnelles restent muettes. D’ailleurs, lorsque les chercheurs ont demandé aux modèles s’il existait une tentative d’injection d’invite dans le code source, Sonnet 4.6 et GPT-5.5 ont laissé passer le matériel. En somme, le même modèle qui exécute échoue lui aussi à auditer.
Une seule charge utile abat quatre modèles différents
La technique circule entre les modèles testés sans modification. Parfois, Sonnet 5 ou Opus 4.8 remarquent que certains fichiers sortent du cadre du projet original. Mais ils poursuivent malgré tout et exécutent. Roey Eliyahu, PDG de Salt Security, résume la question sans ménagement. Pour lui, le problème est structurel. Il naît de la façon même dont ces agents opèrent. Après tout, un texte non fiable parvient à un agent capable d’exécuter des commandes. Et l’agent mêle le code qu’il inspecte aux instructions qu’il reçoit.
CLAUDE.md et agent.md deviennent un contexte persistant pour l’attaquant
Il existe encore une variante plus confortable pour l’intrus. Les chercheurs ont placé les instructions dans des fichiers CLAUDE.md ou agent.md. Ainsi, les agents traitent ce contenu comme le contexte persistant du projet. De cette manière, la manipulation survit entre les exécutions.
Deux scénarios qui s’intègrent déjà dans votre flux Claude Code
Réfléchissez désormais à votre routine. Dans le premier scénario, un mainteneur de bibliothèque intègre des instructions cachées qui orientent l’agent. Des exemples publics antérieurs ont déjà montré des agents destinés à supprimer des suites de tests. Dans le second scénario, une compromission de chaîne d’approvisionnement insère le même contenu dans un paquet populaire. Ensuite, les mises à jour automatiques des dépendances et les jobs CI déclenchent l’agent pour réviser la nouvelle version. Dans ce flux, l’agent ouvre lui-même les fichiers empoisonnés. Le développeur n’y touche même pas.
Pourquoi sandbox et approbation manuelle échouent seuls
Beaucoup misent sur le sandbox comme réseau de sécurité. Cependant, le sandbox perd de son efficacité après que l’agent détient déjà une RCE. À ce moment, l’attaquant explore l’environnement, enregistre les configurations, vole des clés et crée une persistance. L’approbation manuelle a aussi un coût. En effet, exiger une confirmation humaine à chaque commande détruit justement l’automatisation qui a mené les équipes à l’outil. De plus, la fatigue des prompts et le biais d’automatisation affaiblissent ce contrôle humain. Cela empire sous la pression temporelle.
Que faire maintenant sans renoncer à l’agent
La recommandation centrale est claire et gênante. Tout d’abord, cessez de livrer des dépôts non fiables à tout agent doté d’une shell, de clés ou de l’hôte. Ensuite, isolez ces outils sur des machines sans secrets de production. De plus, évitez les montages de systèmes de fichiers aussi larges et les chemins réseau menant à des services internes. Puis, activez une surveillance d’exécution au niveau de l’action. Ainsi, vous verrez un agent exécuter un binaire que le code légitime n’appelle jamais. Enfin, maintenez les contrôles classiques : analyse statique, verrouillage des dépendances, vérification de checksum et révision humaine.
Suivez notre profil sur Instagram !
