Introduction
Un dépôt GitHub sans une seule ligne de code malveillante. Aucune dépendance suspecte, aucun script douteux, rien qui déclencherait vos scanners de supply chain habituels. Et pourtant, à l'issue d'une chaîne d'exécution en trois étapes, un attaquant obtient un shell interactif avec les privilèges du développeur — clés API, variables d'environnement, fichiers de configuration compris. C'est la démonstration que les chercheurs du Mozilla 0DIN (Zero Day Investigative Network) viennent de publier, ciblant Claude Code, Cursor, GitHub Copilot et Gemini CLI.
Trois indirections, zéro code malveillant
Le mécanisme repose sur un enchaînement volontairement banal. Première pièce : un paquet Python apparemment fonctionnel, mais qui refuse de s'exécuter tant qu'une commande d'initialisation n'a pas été lancée. Son message d'erreur suggère explicitement la commande à exécuter. Deuxième pièce : l'agent IA perçoit ce message comme un problème technique ordinaire et l'exécute pour débloquer la situation, sans solliciter la validation de l'utilisateur. Troisième pièce : cette commande d'initialisation invoque un script shell qui interroge un enregistrement DNS TXT appartenant à un domaine contrôlé par l'attaquant. La réponse DNS contient le payload réel — un reverse shell — qui s'exécute immédiatement.
Résultat : une session interactive avec les droits du développeur, et aucun code malveillant n'a jamais transité par le dépôt GitHub.
Ce que vos outils de sécurité ne verront pas
C'est là que réside le défi pour les équipes de sécurité. Les outils d'analyse de composition logicielle (SCA) et les scanners de secrets opèrent sur le code présent dans le dépôt au moment du scan. Le payload, lui, n'existe qu'au moment de la résolution DNS — plusieurs étapes après la phase d'analyse. Les solutions SAST ou de signature de commits ne voient rien d'anormal, puisqu'il n'y a rien d'anormal à voir dans les fichiers sources.
Cette architecture à trois niveaux d'indirection est précisément ce qui rend l'attaque imperméable aux outillages classiques de la chaîne CI/CD. Les contrôles habituels de la supply chain logicielle s'arrêtent au bord du dépôt ; le danger commence après.
L'automatisme comme vecteur
La formulation des chercheurs du 0DIN est particulièrement éclairante : « Claude Code n'a pas décidé d'ouvrir un shell. Il a décidé de corriger une erreur. » Ce déplacement sémantique est au cœur du problème. Les agents de code modernes sont conçus pour être efficaces — résoudre les blocages sans friction, minimiser les interruptions. C'est précisément ce comportement qui devient le vecteur.
L'attaquant ne cherche pas à injecter du code dans le dépôt. Il fabrique une situation d'erreur crédible et délègue l'exécution du payload à l'automatisme bienveillant de l'agent.
Ce que cela change pour votre posture de sécurité
Pour les RSSI et les responsables DevOps, cette démonstration appelle à plusieurs ajustements concrets. D'abord, intégrer le comportement des agents IA dans le modèle de menace : un outil capable d'exécuter des commandes shell est un vecteur d'exécution potentiel, au même titre qu'un pipeline CI/CD. Ensuite, durcir la configuration des agents — désactiver l'exécution automatique de commandes suggérées par des messages d'erreur, ou exiger une confirmation explicite avant tout appel système. Enfin, surveiller les résolutions DNS inhabituelles émises depuis les postes de développement : un enregistrement TXT récupéré depuis un domaine inconnu lors d'une session de code est un signal faible à ne pas négliger.
Mozilla 0DIN recommande que les agents exposent l'intégralité de la chaîne d'exécution — scripts compris — avant de les lancer, plutôt que de faire confiance au seul contenu du dépôt cloné. Gartner, de son côté, a classé l'injection de prompt parmi les quatre menaces critiques de sa feuille de route cybersécurité 2026-2027. Le message est sans ambiguïté : la surface d'attaque des environnements de développement s'est élargie, et les postures défensives doivent s'adapter en conséquence.