Une preuve de concept publiée, pas une attaque observée
Le 11 juillet 2026, BleepingComputer a publié une couverture indépendante de Ghostcommit, recherche de l’ASSET Research Group de l’Université du Missouri à Kansas City. La divulgation primaire est datée de juin sans jour précis, tandis que le dépôt GitHub du PoC est devenu public autour de cette couverture. La date retenue est donc celle de la confirmation indépendante.
Ghostcommit étudie un angle mort du développement assisté par IA. Dans un dépôt contrôlé, une modification paraît cohérente lors de sa revue, mais une instruction placée dans une image est interprétée plus tard par un agent multimodal. Celui-ci accède alors à un fichier d’environnement contenant des identifiants factices et en recopie le contenu sous forme numérique dans du code versionné. Les chercheurs précisent avoir employé uniquement de faux secrets et informé les fournisseurs concernés.
Cette démonstration ne décrit pas une campagne active. Les sources ne recensent aucun vol réel attribué à Ghostcommit, aucune victime et aucune exploitation dans la nature. Aucun CVE n’est publié, car le problème traverse plusieurs outils et configurations plutôt qu’une faille unique. Au 11 juillet, aucun bulletin fournisseur public ni patch confirmé n’est cité. Le risque est crédible, mais sa fréquence réelle reste inconnue.
Pourquoi l’image traverse la revue puis influence l’agent
Le mécanisme repose sur une asymétrie. Une pull request contient un fichier de conventions destiné aux agents et un PNG présenté comme une spécification. Le texte paraît normal et renvoie vers l’image. Pour un reviewer limité au diff textuel, le PNG reste un fichier binaire non analysé. Pour un agent doté de vision, la même image devient une source d’instructions lisible.
Après la fusion, le piège reste dormant jusqu’à une tâche ordinaire. L’agent charge les règles du dépôt, consulte l’image et peut traiter son texte comme une consigne légitime. Dans le test, les données factices deviennent une longue suite de nombres intégrée à un module. Un scanner classique cherche surtout des clés, jetons ou mots de passe sous des formats reconnaissables et peut manquer cette représentation indirecte.
Les chercheurs ont aussi examiné 6 480 pull requests issues des 300 dépôts publics les plus actifs sur quatre-vingt-dix jours. Selon eux, 73 % des modifications fusionnées n’avaient reçu ni revue humaine substantielle ni revue par un bot. Ce résultat souligne la dépendance à l’automatisation, mais ne mesure ni la présence d’images malveillantes ni le taux d’exploitation de Ghostcommit sur GitHub.
Les tests montrent surtout le rôle de l’outil autour du modèle
Le résultat central concerne le logiciel qui encadre le modèle. Selon l’ASSET Research Group, des configurations avec Cursor, Antigravity et Codex CLI ont recopié le fichier d’environnement factice avec plusieurs modèles. Claude Code a refusé dans les configurations essayées. Un même modèle Sonnet a donc réagi différemment selon l’agent fournissant outils, permissions et garde-fous. Avec Opus, Antigravity a écrit les données avant de reconnaître la manipulation et de les retirer.
Les reviewers diffèrent eux aussi. Les chercheurs indiquent que CodeRabbit excluait les PNG par défaut et que Bugbot n’avait rien signalé sur leur pull request expérimentale. Leur prototype défensif ajoute une analyse des images, une recherche de caractères invisibles et un contrôle du code produit. Sur 80 pull requests annoncées comme inédites, il aurait détecté 49 attaques sur 50, toutes les variantes par image, sans faux positif parmi 30 contributions légitimes.
Ces chiffres restent liés au protocole des auteurs. L’équipe précise que les exfiltrations de bout en bout sont des démonstrations contrôlées, pas une estimation statistique applicable à tous les projets. Le prototype défensif n’est pas une garantie de production et manque encore de validation indépendante détaillée. Ghostcommit confirme un risque d’injection indirecte de prompt, sans prouver que chaque agent cité reste exposé dans sa version actuelle.
Mesures défensives pour les équipes qui utilisent des agents IA
Tous les éléments d’une contribution externe doivent être traités comme non fiables, y compris images, documents et fichiers de conventions. Une revue humaine doit ouvrir les nouveaux médias et vérifier pourquoi une règle demande à l’agent de les consulter. Une revue multimodale peut aider si l’outil chargé de l’image doit seulement décrire et signaler son contenu, jamais exécuter les consignes découvertes.
Les permissions constituent le second rempart. Il faut isoler l’agent, bloquer les fichiers sensibles par défaut, limiter ses écritures aux chemins utiles et exiger une validation humaine avant un commit. Les secrets durables devraient rester hors de l’espace de travail, dans un gestionnaire dédié, avec des jetons courts ou des identités temporaires. Les accès aux fichiers d’identifiants et les connexions sortantes doivent être journalisés et restreints.
Une grande constante numérique, un bloc encodé ou une modification sans rapport avec la demande mérite une inspection. En cas de comportement suspect, l’équipe doit interrompre l’agent, préserver les traces, retirer le code concerné et renouveler les secrets potentiellement lus. Mettre à jour agents et reviewers reste utile, mais aucune version précise ne constitue aujourd’hui un correctif universel.
Sans CVE, exploitation réelle ou patch fournisseur confirmé, la réponse repose sur plusieurs couches : revue des médias, moindre privilège, séparation des rôles, contrôle des sorties et rotation rapide des identifiants. Ghostcommit rappelle que la sécurité dépend surtout de ce que l’outil autorise concrètement au modèle à lire, décider et publier.
