Auto mode : 80% d'injection

Fin août 2026, Johann Rehberger (wunderwuzzi) a publié une série d'attaques réussies contre l'auto mode de Claude Code — le mode qui, depuis la mi-août, remplace par défaut les demandes de confirmation manuelle par un classifieur automatique. Taux de réussite mesurés : 60 % pour une variante, 80 % pour une autre. Anthropic a fermé le rapport en le qualifiant d'« informatif ». Simon Willison, qui l'a relayé, rappelle que Rehberger est « l'un des chercheurs en injection de prompt les plus crédibles en activité ».

Ce qu'est l'auto mode

Un agent de code comme Claude Code demande normalement une validation humaine avant chaque action à effet de bord : écrire un fichier, lancer une commande shell, appeler le réseau. L'auto mode supprime cette friction : à la place, un classifieur — un modèle entraîné à distinguer une action anodine d'une action dangereuse — décide seul d'autoriser ou de bloquer. L'argument affiché est la fluidité : on laisse l'agent travailler sans l'interrompre toutes les trente secondes. L'argument implicite, celui que le nom « auto » véhicule, c'est que ce classifieur constitue une protection.

C'est cette hypothèse que l'attaque vise. Pas le modèle principal, pas le sandbox — le maillon présenté comme un garde-fou.

La chaîne d'attaque : le shadowing de module

Le scénario testé enchaîne des étapes toutes individuellement plausibles :

1. Redirection initiale. Le serveur distant répond 415 Unsupported Media Type à WebFetch. Claude, coopératif, bascule sur curl pour récupérer le contenu.
2. Archive piégée. L'utilisateur a demandé un résumé du site ; il reçoit une archive ZIP contenant des « enregistrements » encodés et un décodeur binaire fourni.
3. Refus… puis contournement. Claude refuse d'exécuter le binaire inconnu — bon réflexe. Il écrit alors son propre script Python de décodage pour faire le travail.
4. Shadowing. Ce script s'exécute depuis le dossier extrait, qui contient un fichier struct.py malveillant.
5. Import détourné. Quand le script de Claude fait import base64, Python résout d'abord le répertoire courant : c'est le struct.py de l'attaquant qui est chargé, et son code s'exécute.
6. Charge utile. Le module piégé télécharge une seconde étape Python, puis un binaire natif, et ouvre un canal de command and control.

La phrase de Rehberger qui résume tout : « Claude ne fait pas confiance au décodeur binaire fourni, mais il fait confiance à celui qu'il a écrit lui-même. » Le refus initial n'a servi à rien — l'agent a reconstruit de sa propre initiative le chemin d'exécution, et le classifieur a laissé passer chaque étape parce qu'aucune, prise isolément, ne ressemble à une attaque.

Le garde-fou qui se retourne

Le détail le plus embarrassant, souligné par Willison : dans plusieurs cas, une fois la compromission détectée par Claude lui-même, l'auto mode a bloqué la commande de nettoyage. Le classifieur, voyant une commande destructrice — supprimer des fichiers, tuer un process —, l'a refusée, alors que c'était la remédiation. La protection a activement empêché l'agent de réparer ce qu'il venait de casser. Un contrôle de sécurité qui bloque autant les bonnes actions que les mauvaises n'est pas un demi-contrôle : c'est du bruit qui coûte cher au mauvais moment.

Un classifieur n'est pas une frontière

La réponse d'Anthropic est cohérente sur le fond : l'auto mode est « une fonctionnalité de confort adossée à un classifieur best-effort, pas une garantie de sécurité », et la vraie frontière est « l'isolation OS et le contrôle de l'egress réseau ». Difficile de leur donner tort là-dessus. Le problème est ailleurs : entre ce cadrage prudent et un mode nommé « auto », activé par défaut, présenté par ailleurs comme rendant l'injection de prompt « indémontrable », l'utilisateur retient le message rassurant.

C'est le même glissement que celui décrit dans Sortie IA : le nouveau XSS — une protection probabiliste traitée comme un contrôle déterministe. Un classifieur d'approbation partage la nature du modèle qu'il surveille : il a un taux d'erreur, il est sensible au contexte, il est contournable par construction. L'utiliser comme dernière ligne de défense revient à faire garder une porte par quelqu'un qui a une chance sur cinq de l'ouvrir à l'intrus.

Ce que ça change en pratique

Rien de neuf dans les mesures — mais l'incident les rend non négociables pour tout agent qui tourne sans supervision :

• Sandbox obligatoire. Conteneur, VM ou microVM, jamais le shell de la machine hôte. Sandboxer les tool calls pose les couches ; place aux microVM montre que la latence n'est plus un argument pour s'en passer.
• Egress filtré. Un agent qui n'a pas besoin du réseau sortant ne doit pas l'avoir. La chaîne ci-dessus s'effondre à l'étape 6 si le command and control ne peut pas sortir.
• Credentials isolés. Pas de clés SSH, pas de .env, pas de token cloud dans le home de l'utilisateur qui lance l'agent.
• Création de process gardée explicitement. subprocess, exec, fork méritent une règle dure, pas un avis de classifieur.
• Une approbation auto mode n'est pas une preuve. Que l'agent ait pu exécuter quelque chose ne dit rien sur l'innocuité de ce quelque chose.

Le fond rejoint le vrai bilan des coding agents : ces outils sont utiles, mais leur autonomie réelle est en avance sur les garde-fous censés l'encadrer. Et la défense contre l'injection de prompt n'a pas bougé depuis le premier jour : on ne fait pas confiance à la sortie du modèle, on l'isole. Un classifieur qui note cette sortie ne remplace pas l'isolation — au mieux il la complète, au pire il fait croire qu'elle est facultative.

À retenir

60 à 80 % de réussite, ce n'est pas une faille exotique à corriger : c'est la démonstration qu'un classifieur d'approbation ne relève pas de la catégorie « sécurité ». L'auto mode fait gagner du temps, et c'est très bien tant qu'il tourne dans une boîte dont les parois, elles, sont déterministes. Le jour où il est la seule paroi, le taux de réussite de l'attaquant devient un paramètre de configuration — pas une anomalie.