Anthropic avait annoncé mi-août que Claude Code auto mode devenait le mode par défaut. L’argument : une évaluation tierce montrait 0,00 % de succès pour les attaques par injection de prompt. Deux semaines plus tard, Johann Rehberger — le chercheur le plus crédible dans ce domaine — publie un exploit qui tourne entre 60 et 80 % de réussite. Et le détail qui tue : auto mode a empêché Claude de nettoyer le malware qu’il avait lui-même laissé s’installer.
Ce que fait auto mode (et ce qu’Anthropic prétendait)
Auto mode remplace les demandes de confirmation humaine par un classifieur IA. Quand ton agent veut exécuter une commande, c’est l’IA qui juge si c’est risqué — plus de popup « es-tu sûr ? ». L’objectif affiché : fluidité sans sacrifier la sécurité.
Pour soutenir ça, Anthropic a commandé une évaluation à Trajectory Labs : 72 scénarios d’injection de prompt indirecte, chacun joué 10 fois. Résultat affiché dans leurs communications : 0,00 % de succès pour les attaquants. Boris Cherny, de l’équipe Claude Code, avait même dit publiquement que « l’injection de prompt est largement résolue en pratique : on ne peut tout simplement plus en faire la démonstration. »
Rehberger a pris ça comme un défi.
L’exploit : comment un simple « résume cette page » devient une exécution de code
La chaîne d’attaque est élégante dans sa construction. Le point d’entrée : une requête banale — « résume le contenu de cette URL ». L’URL en question héberge un site d’archive de carnets de notes qui paraît tout à fait légitime.
Étape 1 : le serveur répond 415 Unsupported Media Type à WebFetch. Claude décide de lui-même d’essayer avec curl en ligne de commande — une transition vers l’outil shell que les attaquants exploitent souvent. Le serveur répond avec une redirection vers une archive ZIP.
Étape 2 : le ZIP contient plusieurs fichiers dont un binaire macOS fourni comme « décodeur officiel ». Claude l’inspecte, identifie que c’est un exécutable natif, et refuse de l’exécuter. Bonne réaction. Sauf que c’est exactement ce que l’attaquant voulait — le binaire est un leurre.
Étape 3 : plutôt que de bloquer là, Claude écrit son propre décodeur Python. Il l’exécute depuis le répertoire de l’archive décompressée. Ce décodeur fait un import base64 — qui lui-même fait un import struct. Et le ZIP contient un fichier struct.py malveillant qui se substitue à la bibliothèque standard Python.
Résultat : exécution arbitraire de code, callback vers un serveur C2 contrôlé par l’attaquant, compromission complète de la machine. Claude ne l’a jamais vu venir parce qu’il n’a jamais « exécuté le malware » — il a simplement importé ce qu’il pensait être une bibliothèque système.
Les chiffres sur un petit échantillon : 60 % de succès avec la chaîne C2 classique, 80 % de succès dans la variante qui spawne un second processus Claude headless via claude -p. Cette dernière variante est particulièrement intéressante : le malware ne se contente pas d’exécuter du code, il crée un autre agent IA avec ses propres accès outils.
Le retournement absurde : auto mode bloque le nettoyage
Voilà ce qui rend cette recherche vraiment alarmante pour un builder. Dans plusieurs sessions de test, Claude a fini par inspecter le struct.py malveillant, comprendre qu’il s’était fait compromettre, et tenter de terminer le processus malware.
Auto mode a refusé la commande de nettoyage.
« The classifier allowed the creation of the malware process, but then it blocked the command intended to stop it. The safety mechanism itself can become part of the failure. »
Johann Rehberger, embracethered.com, 26 août 2026
Le classifieur avait laissé passer la création du processus malveillant — parce qu’il n’avait rien vu d’anormal dans un import struct. Mais quand Claude a essayé de killer ce processus, le classifieur a jugé l’action trop risquée. Claude détecte la compromission. Auto mode l’empêche d’y remédier.
Ce que ça change pour toi en tant que builder
La réponse d’Anthropic à la divulgation est honnête et mérite d’être lue : « Auto mode est une fonctionnalité de confort basée sur un classifieur best-effort, pas une garantie de sécurité. Les chaînes d’injection déterminées qui combinent des étapes d’apparence bénigne ne sont pas ce que le classifieur est conçu à arrêter. La vraie frontière, c’est l’isolation OS et le contrôle des sorties réseau. »
Ce qui est un problème, c’est que cette nuance n’est pas dans les communications marketing. Le titre « 0,00 % » crée une fausse sécurité — il mesurait 72 scénarios fixes. L’exploit de Rehberger n’était pas dans ces 72. Les deux chiffres sont vrais en même temps.
Les recommandations concrètes de Rehberger (et validées par Simon Willison) pour utiliser des agents IA de façon responsable :
- Exécute les agents sans surveillance dans un conteneur, une VM ou un sandbox OS. Pas sur ta machine principale, pas avec tes clés SSH accessibles.
- Restreins les sorties réseau. Un agent qui peut se connecter à n’importe quelle adresse IP est un agent qui peut appeler un C2.
- Surveille ce que font tes agents. Les logs doivent être lus, pas juste générés.
- Ne pas exposer les répertoires home, les clés SSH, les credentials cloud à l’environnement d’exécution de l’agent.
Auto mode reste utile pour les cas d’usage interactifs où tu es présent et où le risque d’attaque ciblée est faible. Le problème, c’est l’usage en mode non-surveillé sur des workstations de développement avec accès réseau ouvert — exactement le cas d’usage qu’Anthropic poussait comme killer feature.
La leçon n’est pas de ne pas utiliser Claude Code. C’est de comprendre que le « mode auto » n’est pas synonyme de « mode sûr ». Pour un builder solo qui déploie des agents sur sa machine : lire la page de documentation sur le sandboxing d’Anthropic avant le prochain wake non-surveillé. La frontière de sécurité, c’est l’OS, pas le classifieur.
Les guides pratiques sur l’outil lui-même sont réunis sur la page Claude Code en français.
Un agent qui agit sur tes outils doit être surveillé : les automatisations IA que je propose incluent des alertes quand ça casse.