Comment un dépôt propre pousse un agent de code à ouvrir un reverse shell

De quoi s’agit-il ?

Le 29 juin 2026, SecurityWeek a relayé une preuve de concept de l’équipe 0DIN de Mozilla (les chercheurs Andre Hall et Miller Engelbrecht) qui répond à une question dérangeante : une personne qui ne contrôle rien d’autre qu’un dépôt GitHub public peut-elle obtenir l’exécution de code chez quiconque ouvre ce dépôt avec un agent de code — sans committer une seule ligne de code malveillant ? Leur démonstration répond oui. Un développeur a demandé à Claude Code une chose ordinaire, « fais tourner ce projet fraîchement cloné », et un shell interactif s’est ouvert sur sa machine, connecté au serveur d’un attaquant.

Le résultat est une classe d’injection de prompt indirecte propre aux agents de code. Ces outils reçoivent l’autorité de lire des fichiers, exécuter des commandes shell et faire des appels réseau. Une fois cette autorité déléguée, le contenu non fiable d’un dépôt — notes d’installation, fichiers README, jusqu’au texte d’un message d’erreur — devient un canal d’instructions que l’agent suit sans qu’un humain ne relise vraiment chaque étape.

Comment ça marche

La preuve de concept publiée découpe l’attaque en trois pièces qui, isolément, paraissent banales. Le dépôt fournit des instructions d’installation d’apparence normale dans un README ou une issue. Un paquet local est écrit pour « échouer en fermeture » : si vous l’utilisez avant une étape init, il lève une erreur claire et utile vous invitant à lancer cette étape — un schéma de développement tout à fait ordinaire. Et l’étape init appelle un script d’installation qui va chercher une valeur de configuration depuis une source externe, puis l’exécute.

Le point critique tient à l’origine de cette valeur. Au lieu de figurer dans le dépôt, elle est servie depuis un enregistrement DNS TXT contrôlé par l’attaquant. Sur le plan conceptuel, le script d’installation fait l’équivalent de « résous cet enregistrement DNS, puis exécute ce qu’il renvoie » — l’anti-pattern bien connu qui consiste à injecter directement une valeur récupérée dans un shell. Le dépôt ne dit jamais ce que contient la valeur, et celle-ci est encodée, si bien qu’aucune signature de reverse shell n’apparaît en clair, ni sur le disque ni sur le réseau. La charge réelle — un reverse shell classique en une ligne — est ici volontairement masquée : elle n’est pas nécessaire pour comprendre le résultat.

La chaîne se déroule ensuite d’elle-même. L’agent lit les fichiers et installe les dépendances, tente d’utiliser l’application, tombe sur l’erreur attendue, lit le message d’erreur et lance le correctif documenté comme une simple reprise sur erreur. Ce correctif déclenche le script, le script résout l’enregistrement DNS, et la commande décodée s’exécute sous l’identité même du développeur. Comme le résument les chercheurs, l’agent « n’a jamais décidé d’ouvrir un shell — il a décidé de corriger une erreur ». Le reverse shell se trouve à trois niveaux d’indirection de tout ce que l’agent a réellement évalué : un message d’erreur auquel il a fait confiance, un script qui a récupéré une valeur, et un enregistrement DNS qu’il n’a jamais vu. Dans le terminal du développeur, la seule sortie visible est deux lignes anodines d’« environnement prêt ».

Pourquoi c’est important

L’impact démontré est un shell interactif complet tournant avec les privilèges du développeur. Cela expose tous les secrets de l’environnement — clés cloud, clés d’API, jetons de gestion de code source — et laisse à l’attaquant une fenêtre pour établir de la persistance (déposer une clé SSH, ajouter une tâche planifiée) avant que le shell ne se ferme. Comme la charge réside dans un enregistrement DNS plutôt que dans le code, elle peut être remplacée à tout moment sans aucun commit ni rien à comparer pour l’outillage, et un simple lien de dépôt partagé dans une offre d’emploi, un tutoriel ou un message de messagerie atteint tous ceux qui l’ouvrent avec un agent de code.

Ce qui rend la chose difficile, c’est qu’aucun défenseur ne voit l’ensemble. L’analyse statique du dépôt voit une résolution DNS. La supervision réseau voit une résolution de nom ordinaire. L’agent voit une étape d’installation pré-autorisée. La malveillance n’existe que dans la composition — entre le dépôt, l’infrastructure DNS et la confiance du développeur envers l’agent — et aucun des trois systèmes n’est examiné conjointement. Il s’agit d’une démonstration de chercheurs, pas d’une compromission signalée : il n’y a pas de victime confirmée dans la nature, et cela doit se lire comme un avertissement sur une faiblesse structurelle plutôt que comme un incident actif.

Défenses

Le correctif le plus direct est la visibilité sur ce qu’une étape d’installation va réellement faire. Un agent devrait exposer non seulement la commande qu’il s’apprête à lancer, mais aussi le contenu de tout script que cette commande invoque et tout ce que ce script récupère à l’exécution, afin qu’une action « lance le correctif documenté » ne puisse pas se transformer silencieusement en exécution d’une valeur externe. Traitez la génération d’une commande et son exécution comme deux décisions de confiance distinctes.

Pour les équipes comme pour les développeurs individuels, les recommandations convergent vers le moindre privilège et l’isolation. Faites tourner les agents de code sur des dépôts inconnus à l’intérieur d’un bac à sable ou d’un conteneur jetable dépourvu de véritables identifiants, afin qu’une étape d’installation détournée n’atteigne rien de sensible. N’exportez pas de secrets de production dans l’environnement shell où opère l’agent. Restreignez le trafic réseau sortant à une liste d’autorisation pour qu’un shell fraîchement lancé ne puisse pas « rappeler la maison », et méfiez-vous des séquences d’installation qui résolvent des enregistrements DNS TXT ou qui injectent du contenu récupéré dans un interpréteur. Surtout, traitez les instructions et scripts d’installation des dépôts que vous n’avez pas écrits comme du code non fiable, quoi que recommande un outil d’IA — la discipline déjà prescrite par le « lethal trifecta » et la « Règle de deux pour les agents » : ne jamais laisser un agent non supervisé combiner l’accès à des données privées, l’exposition à du contenu non fiable et la capacité de communiquer vers l’extérieur.

Statut

Il s’agit d’une preuve de concept divulguée par une équipe de recherche reconnue, non d’une vulnérabilité produit avec un identifiant attribué. Le tableau résume les faits clés.

Élément	Détail
Source	0DIN (Mozilla), « Clone This Repo and I Own Your Machine »
Chercheurs	Andre Hall, Miller Engelbrecht
Divulgation	Juin 2026 (largement relayée le 29 juin 2026 via SecurityWeek)
Technique	Injection de prompt indirecte → reprise sur erreur de l’agent → charge hébergée en DNS → reverse shell
Démontré sur	Claude Code ; s’applique aux agents de code disposant d’un accès shell autonome
Impact	RCE sous l’identité du développeur, exfiltration de secrets, persistance
Statut	PoC de chercheurs ; aucune exploitation confirmée dans la nature

Les deux sources citées datent des 30 derniers jours. L’enseignement est architectural : tant qu’un agent de code exécute un « correctif » sans exposer ce que ce correctif finit par lancer, les dépôts non fiables restent un canal d’exécution — et la défense se joue dans le bac à sable, le contrôle du trafic sortant et le fait de traiter les étapes d’installation tierces comme du code non fiable, non dans la recherche, au sein du dépôt, de mauvaises chaînes de caractères qui n’y ont jamais été.