GitLost : une simple issue publique fait fuiter des dépôts privés via un workflow agentique GitHub

De quoi s’agit-il ?

Le 7 juillet 2026, les chercheurs de Noma Security ont publié GitLost, une technique qui transforme une issue publique ordinaire en canal d’exfiltration du code source privé d’une organisation. La cible : GitHub Agentic Workflows, une fonctionnalité entrée en preview technique en février 2026, qui permet de remplacer les scripts d’automatisation par des instructions en langage naturel (Markdown) adressées à un agent IA — propulsé par GitHub Copilot, Claude d’Anthropic, Google Gemini ou OpenAI Codex — qui lit les issues et les pull requests, appelle des outils et répond de lui-même.

La découverte a été relayée le jour même par The Hacker News et The Register. Noma l’a signalée à GitHub et a publié avec l’accord de l’entreprise. Il n’y a pas de CVE : comme le formulent les chercheurs, c’est une conséquence structurelle de la manière dont ces agents sont câblés, pas un défaut de code qu’un simple correctif refermerait.

Comment ça marche

Le mécanisme est celui de l’injection de prompt indirecte. Un agent LLM ne sait pas distinguer de façon fiable les instructions de son opérateur de celles dissimulées dans le contenu non fiable qu’il lit. Les Agentic Workflows sont en lecture seule par défaut, mais une organisation peut confier à un workflow un jeton d’accès personnel doté d’un accès en lecture sur l’ensemble de ses dépôts — y compris les dépôts privés — pour donner à l’agent un contexte inter-dépôts. C’est précisément cet octroi que GitLost retourne contre la victime.

Dans la preuve de concept de Noma, l’attaquant ouvre une issue d’apparence anodine sur un dépôt public de l’organisation cible. Le corps de l’issue est déguisé en requête de routine — dans la démo, un message d’un « VP of Sales » après un rendez-vous client — avec des instructions cachées demandant à l’agent d’aller chercher le contenu d’un dépôt privé et de le republier. Une automatisation de routine assigne l’issue, le workflow se réveille, lit l’issue, suit les instructions injectées et recopie le README d’un dépôt privé dans un commentaire public de cette même issue.

GitHub avait anticipé exactement ce type d’abus : sa documentation avertit que les agents « peuvent être manipulés par injection de prompt », et le produit embarque un bac à sable, la lecture seule par défaut, un nettoyage des entrées et une étape de détection de menace qui analyse la sortie proposée avant publication. Noma rapporte qu’un changement d’un seul mot a suffi à franchir ce garde-fou : préfixer l’instruction malveillante par « Additionally » (« De plus ») a conduit le modèle à la traiter comme une tâche complémentaire légitime plutôt qu’à la refuser, et la sortie est passée.

Pourquoi c’est important

Ce qui distingue GitLost des démonstrations d’injection antérieures, c’est ce que l’attaquant contrôle. Les exemples passés manipulaient surtout ce que l’agent disait ; ici, l’attaquant manipule ce qu’un agent doté d’identifiants fait de ses permissions. L’agent n’est pas une fenêtre de chat : c’est un acteur logé dans une infrastructure proche de la CI/CD, avec un accès en lecture couvrant des dépôts que l’attaquant ne voit pas. L’attaque ne touche aucun serveur, ne requiert aucun identifiant volé et aucun droit d’écriture. Ouvrir une issue publique suffit.

Ce montage est un cas d’école de la lethal trifecta de Simon Willison : un agent qui peut atteindre des données privées, ingère du contenu externe non fiable et dispose d’un moyen d’exfiltrer. Réunissez les trois et vous obtenez un chemin de fuite ; ce qu’un attaquant peut soutirer dépend entièrement de la portée du jeton — code propriétaire, clés internes, documents de conception ou secrets de CI/CD. GitLost prolonge une série de la même famille, aux côtés de la faille bot-actor de Claude Code GitHub Action et de la technique inter-fournisseurs Comment and Control — et, comme elles, elle est classée « limitation architecturale », car le langage naturel n’offre aucune frontière nette entre donnée et instruction à faire respecter.

Défenses

Les mitigations de Noma portent sur la portée et l’architecture, pas sur un meilleur filtrage :

• Limitez le jeton à un seul dépôt, pas à l’organisation. L’accès inter-dépôts vient d’un PAT configuré par l’organisation. Un jeton restreint au dépôt que le workflow traite est bien moins dangereux qu’un accès en lecture à l’échelle de l’organisation accordé par confort. C’est le contrôle le plus efficace.
• Restreignez ce qu’un workflow public peut publier. Les écritures passent par des sorties sûres déclarées, et le commentaire public est le canal d’exfiltration : limitez-le. Cassez la jambe « exfiltration » de la trifecta partout où l’agent lit une entrée non fiable.
• Restreignez les auteurs dont l’agent traite le contenu, et soumettez les sorties de l’agent à une revue humaine avant toute publication.
• Isolez l’entrée non fiable du contexte d’instructions avant qu’elle n’atteigne le modèle, et considérez la détection de menace intégrée comme un filet de sécurité, pas une frontière — le contournement par « Additionally » le démontre.
• Auditez les workflows qui réunissent la trifecta : entrée publique non fiable, accès en lecture privé et sortie publique. Retirer l’un des trois referme le chemin de fuite.

Statut

Élément	Valeur
Technique	GitLost — injection de prompt indirecte dans GitHub Agentic Workflows
Divulguée par	Noma Security (Noma Labs)
Date de publication	7 juillet 2026
CVE	Aucune — limitation structurelle / architecturale
Concernés	Workflows agentiques lisant une entrée publique non fiable, avec accès en lecture privé, pouvant publier en public
Garde-fou contourné	La détection de menace de GitHub franchie par un préfixe d’un mot (« Additionally »)
Statut éditeur	Divulgation responsable à GitHub ; publiée avec l’accord de GitHub

Dates clés : 13 février 2026 — GitHub Agentic Workflows en preview technique. 7 juillet 2026 — publication de GitLost par Noma Security.