Claude Code peut être trompé par un dépôt GitHub apparemment fiable et exécuter un logiciel malveillant sans identifier le danger. Des chercheurs du Mozilla Zero Day Investigative Network (0DIN) ont montré qu’un attaquant pouvait ainsi accéder aux droits du développeur, à ses clés API, à ses fichiers de configuration et à ses identifiants.
Un dépôt GitHub apparemment fiable suffit à piéger Claude Code
L’attaque ne repose ni sur un code d’exploitation visible ni sur une commande shell manifestement suspecte. Elle commence par une page GitHub contenant des instructions classiques pour installer et configurer un projet.
Pendant l’installation des dépendances, un message d’erreur affiche une commande censée corriger le problème. Un développeur pourrait l’examiner avant de la lancer. Claude Code la considère comme une étape normale de l’installation et l’exécute.
Les instructions malveillantes sont récupérées via DNS
La commande charge d’abord un script shell. Celui-ci consulte ensuite un enregistrement DNS TXT contrôlé par l’attaquant pour récupérer une valeur de configuration.
Cette valeur est exécutée comme une nouvelle commande. Claude Code télécharge alors le logiciel malveillant depuis l’infrastructure de l’attaquant.
Les pirates peuvent obtenir les mêmes droits que le développeur sur la machine compromise. Ils peuvent aussi récupérer des clés API, des fichiers de configuration et des données d’authentification.
Ces informations peuvent servir à compromettre d’autres systèmes ou à surveiller des utilisateurs grâce à des accès API déjà autorisés.
Aucun code malveillant n’apparaît dans le dépôt
La charge malveillante n’est jamais stockée dans le dépôt GitHub. Les instructions dangereuses sont récupérées uniquement pendant l’exécution, par l’intermédiaire du DNS.
Claude Code enchaîne alors toutes les étapes : lancement du script, lecture de la valeur DNS, exécution de la commande et téléchargement du malware.
Cette méthode complique fortement la détection. Une analyse du dépôt ne révèle aucun fichier suspect, puisque le contenu malveillant reste hébergé sur une infrastructure externe jusqu’au déclenchement de l’attaque.
Selon Mozilla, cette technique est presque impossible à bloquer avec des contrôles traditionnels.
Chaque commande devrait être validée avant son exécution
Les chercheurs recommandent d’obliger les agents IA à afficher les commandes d’installation avant de les lancer. Le développeur devrait pouvoir les examiner et les approuver une par une.
Cette validation devrait aussi couvrir les scripts et le code récupérés pendant l’exécution. Sans cette visibilité, un agent IA peut lancer une commande distante sans que l’utilisateur puisse en vérifier le contenu.
Une autorisation générale accordée au début de l’installation ne suffit donc pas. Chaque nouvelle commande et chaque ressource externe devraient être contrôlées avant leur exécution.
La supervision humaine doit rester active à chaque étape
Le principe du human-in-the-loop consiste à maintenir un contrôle humain sur les actions d’un agent IA. Dans ce cas, une simple confirmation ne permet pas de repérer une attaque répartie sur plusieurs étapes.
Le développeur doit pouvoir voir les commandes exécutées, les serveurs contactés et les scripts chargés. Sans ces informations, une instruction banale peut déclencher une chaîne malveillante complète.
Les entreprises qui utilisent des agents IA dans leurs environnements de développement doivent former leurs équipes à ces nouvelles méthodes d’attaque. Le développeur reste la dernière ligne de défense avant la compromission du réseau de l’entreprise.
Eric Thomas suit l’actualité de Windows, des logiciels, de la cybersécurité grand public et des outils web. Il s’intéresse aux mises à jour système, aux nouveautés informatiques et aux solutions pratiques qui améliorent l’expérience numérique au quotidien.
