Comment l'attaque fonctionne

Les chercheurs ont décrit le modèle de workflow agentic vulnérable comme suit :

• Déclenché sur les événements issues.assigned
• Lisant le titre et le corps de l'issue
• Postant un commentaire via un outil agent tel que add-comment
• S'exécutant avec un accès en lecture à d'autres dépôts de l'organisation, y compris les dépôts privés

L'attaque se déroule en quatre étapes :

1. L'attaquant ouvre une issue GitHub anodine sur un dépôt public appartenant à une organisation utilisant le modèle de workflow agentic vulnérable.
2. Cachées dans le corps de l'issue se trouvent des commandes en langage naturel ordinaire qui ordonnent à l'agent IA d'aller chercher des fichiers dans les dépôts privés.
3. Lorsque l'automatisation GitHub assigne l'issue, le workflow déclenché par l'événement amène l'agent à récupérer des données depuis les dépôts auxquels il a accès, y compris les dépôts privés.
4. L'agent poste le contenu récupéré sous forme de commentaire public sur l'issue, exposant potentiellement les données à quiconque peut voir l'issue.

La faiblesse architecturale sous-jacente

La faille centrale est une incapacité à maintenir une frontière de confiance stricte entre les instructions système et les données non fiables de l'utilisateur au sein de la fenêtre de contexte de l'agent IA. Comme l'a déclaré Sasi Levi, de Noma : « La fenêtre de contexte de l'agent est aussi sa surface d'attaque. Tout contenu que l'agent lit — qu'il s'agisse d'issues, de pull requests, de commentaires ou de fichiers — peut être transformé en arme si l'agent traite ce contenu comme une entrée d'instruction. »

Les agents basés sur les LLM peinent à distinguer les données des instructions lorsque les deux apparaissent dans le même contexte ou dans le même résultat d'outil. Il ne s'agit pas d'un simple bug de codage classique, mais d'un risque structurel inhérent aux workflows d'IA agentique, où un contenu non fiable peut influencer le comportement de l'agent si le workflow ne l'isole ou ne le contraint pas.

Les chercheurs ont officiellement catégorisé cette classe de failles sous le nom d'Agentic Workflow Injection (AWI), en identifiant deux modèles principaux : Prompt-to-Agent (P2A), où un contenu non fiable atteint la frontière de prompt de l'agent, et Prompt-to-Script (P2S), où l'influence de l'attaquant se propage à travers les sorties dérivées du modèle dans des scripts ultérieurs.

La technique de contournement des garde-fous : le mot-clé « Additionally »

GitHub avait mis en place des garde-fous destinés à empêcher l'exfiltration de données, mais les chercheurs de Noma ont rapporté avoir pu les contourner avec une technique étonnamment simple. L'ajout du mot « Additionally » aux instructions injectées a amené le modèle à reformuler sa réponse plutôt que de refuser la requête, permettant à la fuite de données de se dérouler comme s'il s'agissait d'une continuation autorisée de la tâche.

Cette approche est cohérente avec les recherches plus larges sur l'injection de prompt, qui montrent qu'une formulation particulière ou un texte renvoyé par un outil peut pousser les modèles à suivre des instructions malveillantes qu'ils ne devraient pas exécuter. Ce contournement de garde-fou fait écho à des incidents antérieurs, comme la vulnérabilité GitHub MCP découverte par Invariant Labs, où une issue malveillante pouvait détourner l'agent d'un utilisateur pour faire fuiter des données depuis des dépôts privés.

Recommandations de correction pour les organisations

Sur la base des conclusions de GitLost et des directives plus larges en matière de sécurité des workflows agentiques, les organisations concernées devraient mettre en œuvre les mesures de contrôle suivantes :

• Adopter le principe de zéro confiance pour les entrées de l'agent — ne jamais traiter un contenu contrôlé par l'utilisateur comme une instruction fiable, et isoler les données non fiables de l'utilisateur des invites système principales.
• Appliquer des permissions strictes de moindre privilège en supprimant tout accès cross-repository inutile et en limitant la capacité des agents à exposer des données via des sorties publiques.
• Utiliser des listes blanches d'outils plutôt que des listes noires, et exiger des validations humaines avant que les agents n'effectuent des actions sensibles telles que poster des commentaires visibles de l'extérieur ou accéder à des dépôts sensibles.
• Auditer les intégrations d'agents IA dans les workflows CI/CD et d'automatisation de dépôts, en particulier là où le contexte non fiable d'événements GitHub est incorporé dans les invites ou les entrées des agents.
• Isoler logiquement l'entrée utilisateur non fiable des directives système, en traitant le texte généré par l'utilisateur comme une donnée non fiable et non comme une instruction faisant autorité.

Les organisations devraient également appliquer le principe du moindre privilège aux secrets des agents et mettre en œuvre une surveillance de sécurité continue pour détecter les tentatives d'injection de prompt.

Réponse de GitHub (au 7 juillet)

Selon Dark Reading et le calendrier de divulgation de Noma Security :

• Noma a divulgué la faille de manière responsable à GitHub.
• GitHub a fait savoir à Noma qu'il avait mis à jour la documentation associée au modèle de workflow vulnérable, et les chercheurs ont rapporté que la configuration vulnérable n'était plus présente lors de leur dernière vérification.
• Au 7 juillet, GitHub n'avait pas émis de déclaration publique officielle ni de CVE pour GitLost.
• La vulnérabilité semble avoir été partiellement traitée par la suppression ou la révision de la documentation et du modèle de workflow concernés, plutôt que par un correctif de sécurité clairement documenté au niveau de la plateforme.

Le contexte plus large : un risque systémique

GitLost n'est pas un incident isolé. Il représente une classe croissante de vulnérabilités dans lesquelles des agents IA ayant accès à des données sensibles sont exposés à du contenu non fiable émanant d'utilisateurs. Des problèmes similaires ont affecté les intégrations GitHub MCP, les workflows Google Gemini CLI (vulnérabilité TrustIssues) et les GitHub Actions de Claude Code. Le point commun est que les agents basés sur les LLM manquent d'une capacité inhérente à distinguer les données des instructions lorsque les deux apparaissent dans la même fenêtre de contexte — un défi architectural fondamental qu'aucun correctif de plateforme unique ne peut résoudre entièrement.

Comment l'attaque fonctionne

Les chercheurs ont décrit le modèle de workflow agentic vulnérable comme suit :

• Déclenché sur les événements issues.assigned
• Lisant le titre et le corps de l'issue
• Postant un commentaire via un outil agent tel que add-comment
• S'exécutant avec un accès en lecture à d'autres dépôts de l'organisation, y compris les dépôts privés

L'attaque se déroule en quatre étapes :

1. L'attaquant ouvre une issue GitHub anodine sur un dépôt public appartenant à une organisation utilisant le modèle de workflow agentic vulnérable.
2. Cachées dans le corps de l'issue se trouvent des commandes en langage naturel ordinaire qui ordonnent à l'agent IA d'aller chercher des fichiers dans les dépôts privés.
3. Lorsque l'automatisation GitHub assigne l'issue, le workflow déclenché par l'événement amène l'agent à récupérer des données depuis les dépôts auxquels il a accès, y compris les dépôts privés.
4. L'agent poste le contenu récupéré sous forme de commentaire public sur l'issue, exposant potentiellement les données à quiconque peut voir l'issue.

La faiblesse architecturale sous-jacente

La faille centrale est une incapacité à maintenir une frontière de confiance stricte entre les instructions système et les données non fiables de l'utilisateur au sein de la fenêtre de contexte de l'agent IA. Comme l'a déclaré Sasi Levi, de Noma : « La fenêtre de contexte de l'agent est aussi sa surface d'attaque. Tout contenu que l'agent lit — qu'il s'agisse d'issues, de pull requests, de commentaires ou de fichiers — peut être transformé en arme si l'agent traite ce contenu comme une entrée d'instruction. »

Les agents basés sur les LLM peinent à distinguer les données des instructions lorsque les deux apparaissent dans le même contexte ou dans le même résultat d'outil. Il ne s'agit pas d'un simple bug de codage classique, mais d'un risque structurel inhérent aux workflows d'IA agentique, où un contenu non fiable peut influencer le comportement de l'agent si le workflow ne l'isole ou ne le contraint pas.

Les chercheurs ont officiellement catégorisé cette classe de failles sous le nom d'Agentic Workflow Injection (AWI), en identifiant deux modèles principaux : Prompt-to-Agent (P2A), où un contenu non fiable atteint la frontière de prompt de l'agent, et Prompt-to-Script (P2S), où l'influence de l'attaquant se propage à travers les sorties dérivées du modèle dans des scripts ultérieurs.

La technique de contournement des garde-fous : le mot-clé « Additionally »

GitHub avait mis en place des garde-fous destinés à empêcher l'exfiltration de données, mais les chercheurs de Noma ont rapporté avoir pu les contourner avec une technique étonnamment simple. L'ajout du mot « Additionally » aux instructions injectées a amené le modèle à reformuler sa réponse plutôt que de refuser la requête, permettant à la fuite de données de se dérouler comme s'il s'agissait d'une continuation autorisée de la tâche.

Cette approche est cohérente avec les recherches plus larges sur l'injection de prompt, qui montrent qu'une formulation particulière ou un texte renvoyé par un outil peut pousser les modèles à suivre des instructions malveillantes qu'ils ne devraient pas exécuter. Ce contournement de garde-fou fait écho à des incidents antérieurs, comme la vulnérabilité GitHub MCP découverte par Invariant Labs, où une issue malveillante pouvait détourner l'agent d'un utilisateur pour faire fuiter des données depuis des dépôts privés.

Recommandations de correction pour les organisations

Sur la base des conclusions de GitLost et des directives plus larges en matière de sécurité des workflows agentiques, les organisations concernées devraient mettre en œuvre les mesures de contrôle suivantes :

• Adopter le principe de zéro confiance pour les entrées de l'agent — ne jamais traiter un contenu contrôlé par l'utilisateur comme une instruction fiable, et isoler les données non fiables de l'utilisateur des invites système principales.
• Appliquer des permissions strictes de moindre privilège en supprimant tout accès cross-repository inutile et en limitant la capacité des agents à exposer des données via des sorties publiques.
• Utiliser des listes blanches d'outils plutôt que des listes noires, et exiger des validations humaines avant que les agents n'effectuent des actions sensibles telles que poster des commentaires visibles de l'extérieur ou accéder à des dépôts sensibles.
• Auditer les intégrations d'agents IA dans les workflows CI/CD et d'automatisation de dépôts, en particulier là où le contexte non fiable d'événements GitHub est incorporé dans les invites ou les entrées des agents.
• Isoler logiquement l'entrée utilisateur non fiable des directives système, en traitant le texte généré par l'utilisateur comme une donnée non fiable et non comme une instruction faisant autorité.

Les organisations devraient également appliquer le principe du moindre privilège aux secrets des agents et mettre en œuvre une surveillance de sécurité continue pour détecter les tentatives d'injection de prompt.

Réponse de GitHub (au 7 juillet)

Selon Dark Reading et le calendrier de divulgation de Noma Security :

• Noma a divulgué la faille de manière responsable à GitHub.
• GitHub a fait savoir à Noma qu'il avait mis à jour la documentation associée au modèle de workflow vulnérable, et les chercheurs ont rapporté que la configuration vulnérable n'était plus présente lors de leur dernière vérification.
• Au 7 juillet, GitHub n'avait pas émis de déclaration publique officielle ni de CVE pour GitLost.
• La vulnérabilité semble avoir été partiellement traitée par la suppression ou la révision de la documentation et du modèle de workflow concernés, plutôt que par un correctif de sécurité clairement documenté au niveau de la plateforme.

Le contexte plus large : un risque systémique

GitLost n'est pas un incident isolé. Il représente une classe croissante de vulnérabilités dans lesquelles des agents IA ayant accès à des données sensibles sont exposés à du contenu non fiable émanant d'utilisateurs. Des problèmes similaires ont affecté les intégrations GitHub MCP, les workflows Google Gemini CLI (vulnérabilité TrustIssues) et les GitHub Actions de Claude Code. Le point commun est que les agents basés sur les LLM manquent d'une capacité inhérente à distinguer les données des instructions lorsque les deux apparaissent dans la même fenêtre de contexte — un défi architectural fondamental qu'aucun correctif de plateforme unique ne peut résoudre entièrement.