Connexion
GitLost - Un seul mot suffit pour faire cracher ses dépôts privés à l'IA de GitHub
Et c'est reparti pour un tour ! Qu'est-ce que vous pensez d'un dépôt privé sur Github qui serait capable d'exfiltrer tout seul son propre code dans une section commentaire visiblement publiquement par tout le monde. Ce serait ouf non ?
Hé bien c'est le tour de passe-passe que Sasi Levi, de chez Noma Security, vient de réussir grâce à l'agent IA de GitHub. Et vous allez voir, c'est tout con, donc c'est hyper flippant.
Cette attaque s'appelle GitLost et la cible, c'est le GitHub Agentic Workflows, un système qui colle un agent IA (tournant sur Claude ou Copilot) à vos GitHub Actions pour qu'il bosse tout seul sur vos tickets. C'est un setup où l'agent a un accès en lecture à vos repos privés et se réveille dès qu'une issue lui est assignée. C'est super pratique, sauf que... c'est un vrai piège qui peut se refermer très vite sur vous.
Ça commence en fait par une simple issue dans un dépôt public. Rien de sorcier, pas de commit vérolé, pas de serveur MCP malveillant. Juste du texte, avec des instructions planquées en anglais au milieu du ticket. L'agent lit alors cette issue, tombe sur les instructions cachées à l'intérieur et les considère comme des ordres légitimes.
Et c'est là que ça part en couille, puisqu'après il part gentiment chercher le contenu d'un README qu'on lui demande dans un dépôt privé auquel il a accès (dans la démo, sasinomalabs/testlocal). Jusqu'ici, c'est l'exfiltration classique du prompt injection, sauf que d'habitude, il faut ruser pour faire sortir la donnée avec une image markdown piégée, une requête réseau vers un serveur qu'on contrôle, un canal caché...etc.
Mais dans le cadre de cette attaque GitLost, eh bien il n'y a pas besoin de tout ça. En fait, l'agent recopie bêtement le contenu privé dans un commentaire public sur l'issue de départ et c'est terminé. C'est donc lisible par n'importe qui passant sur le repo public.
Lors des tests, le modèle refusait quand même parfois d'obéir aux instructions cachées. Mais le chercheur a trouvé une parade qui est d'ajouter le mot "Additionally" dans le prompt. Ce simple connecteur suffit à lui faire reconsidérer son refus et exécuter la commande. Attention, "Additionally" n'est pas une formule magique qui débloque toutes les IA de la Terre, Mais parfois ça suffit à faire sauter les garde-fous. C'est dire à quel point la sécurité de ces modèles est solide...
Si ça vous rappelle quelque chose, c'est normal. On a déjà eu CamoLeak , qui transformait Copilot en espion via un commentaire GitHub, avec une exfiltration bien plus léchée (image markdown, score CVSS de 9,6). Et en fait GitLost, c'est vraiment la version feignasse. En gros, c'est la même famille d'attaque, sauf que cette fois l'attaquant n'a pas à se fatiguer.
On avait aussi vu une bibliothèque Java piéger les IA codeuses pour qu'elles effacent vos tests, donc je pense que vous connaissez la chanson... Méfiez-vous des agents qui écrivent du code sans surveillance parce qu'ils sont devenus une véritable cible pour les cybercriminels.
Voilà, donc non, GitHub n'est pas "troué" et la config vulnérable est très précise puisqu'il faut un agent avec accès en lecture cross-repo ET déclenché par des entrées publiques. Et il y a très peu d'orgas qui tournent exactement comme ça. Noma a bien sûr signalé la faille à GitHub de façon responsable, aucune CVE n'a été attribuée à ce jour, et y'a eu aucune confirmation publique d'un correctif de leur côté pour le moment.
Ne traitez donc jamais le texte d'un utilisateur comme une instruction de confiance, isolez les entrées, collez au strict minimum de permissions. C'est le même délire quand on contrôle les entrées dans un formulaire finalement...
