GitLost : faille critique dans les agents IA de GitHub

GitLost : faille critique dans les agents IA de GitHub

Temps de lecture : 4 min

Points clés à retenir

  • Injection de prompt : un attaquant non authentifié peut tromper un agent IA de GitHub pour qu’il extraie des données de dépôts privés et les publie publiquement.
  • Cause racine : les agents IA confondent les instructions cachées dans des tickets GitHub avec des commandes légitimes, faute de validation des entrées.
  • Solutions : appliquer le moindre privilège, créer des listes blanches de dépôts, valider toutes les entrées utilisateur et prévoir un arrêt d’urgence pour les agents.

Soyons clairs : l’attaque GitLost n’est pas une vulnérabilité ordinaire

Selon une étude de Noma Security, l’attaque « GitLost » cible la version beta des Agentic Workflows de GitHub. Un attaquant non authentifié soumet un ticket GitHub spécialement conçu à un dépôt public. Si l’agent IA dispose d’un accès en lecture à des dépôts privés au sein de la même entreprise, il extrait des informations sensibles et les publie dans un commentaire public. Ce qui fait vraiment la différence ici, c’est que l’attaque ne nécessite ni identifiants volés, ni logiciels malveillants, ni aucune faille logicielle classique. Elle repose uniquement sur une injection indirecte de prompt.

Comment fonctionne exactement l’injection de prompt dans les agents IA ?

Les Agentic Workflows de GitHub combinent GitHub Actions avec des modèles d’IA comme Claude ou GitHub Copilot. Les développeurs définissent des workflows en Markdown, et les agents IA lisent les tickets, lancent des outils et exécutent des tâches de manière autonome. En pratique, un attaquant intègre des instructions cachées dans le corps d’une issue GitHub. L’agent IA interprète ces instructions comme des commandes légitimes, et non comme du contenu non fiable. Il accède alors à un dépôt privé et publie son contenu dans l’issue publique. Les chercheurs de Noma ont démontré l’attaque en créant un ticket demandant des mises à jour de documentation, ce qui a suffi à déclencher le vol de données.

Une faille architecturale plutôt qu’un simple bug

Ce qui rend cette vulnérabilité particulièrement préoccupante, c’est qu’elle révèle un problème structurel. Comme l’explique Sasi Levi, chercheur chez Noma, tout agent IA ayant accès à la fois à du contenu externe non fiable et à des ressources internes sensibles devient un pont involontaire entre les deux si les limites de confiance ne sont pas respectées. Vibhum Dubey, chercheur indépendant en cybersécurité, ajoute que les agents IA fonctionnent selon un modèle d’autorisations de compte de service, et non selon un modèle d’autorisations utilisateur. En d’autres termes, l’agent ne « sait » pas qu’un dépôt est privé ; il le perçoit simplement comme accessible.

Trois mesures concrètes pour sécuriser vos agents IA

Pour éviter ce type d’incident, je recommande trois actions immédiates :

  • Listes blanches explicites : ne donnez pas un accès général via un compte de service. Limitez les dépôts accessibles par chaque agent.
  • Validation des entrées : traitez les tickets GitHub, les requêtes pull, les commentaires et même les messages de commit comme des données non fiables avant qu’elles n’atteignent le LLM.
  • Arrêt d’urgence : prévoyez un mécanisme pour désactiver un agent malveillant rapidement, de la même manière que l’on révoque une clé API compromise.

Ce qui fait vraiment la différence : repenser les autorisations

Je le dis souvent : la sécurité des agents IA ne se résume pas à un simple problème de surveillance. GitLost montre que les limites de confiance existent dans le modèle de données de GitHub, mais pas dans le contexte d’exécution de l’agent. Tant que les entreprises continueront d’accorder des autorisations larges à des comptes de service sans les coupler à une validation rigoureuse des entrées, ces failles d’autorisations invisibles s’accumuleront. En pratique, le principe du moindre privilège doit être appliqué de manière stricte. N’attendez pas qu’un incident se produise pour agir.