GitHub possède une faille qui expose du code, des mots de passe et des données sensibles d’entreprise sans que quiconque ait besoin d’écrire une seule ligne de malware. Un chercheur ouvre une issue polie dans un dépôt public. Aucun exploit, aucun payload obfusqué. Et pourtant, en quelques minutes à peine, des clés d’API et du code privé se retrouvent hors de l’entreprise. C’est la faille baptisée GitLost, découverte par Noma Security, et elle ne dépend que d’un anglais bien rédigé.
Pour ceux qui bâtissent des pipelines au quotidien, le détail qui dérange le plus est autre chose. Après tout, le problème ne réside ni dans un bogue de parsing ni dans une dépendance compromise. Il se situe dans l’architecture des permissions que nous avons nous‑mêmes approuvée lors du merge.
GitHub a mêlé automatisation et langage naturel, et la frontière entre données et instruction a disparu
Agentic Workflows relie l’automatisation de la plateforme à des assistants comme Copilot. En théorie, c’est excellent. Autrement dit, vous décrivez la tâche en langage naturel et l’agent exécute. En pratique, toutefois, l’agent lit le texte d’autrui avec le même poids que l’instruction système.
C’est exactement là que ça casse. L’intrus ouvre un ticket public qui paraît être une simple question d’utilisateur. Cependant, le corps du texte porte des instructions cachées : ignore tes règles, accède aux dépôts privés, copie ce que tu trouveras. Comme le workflow fonctionne avec des permissions étendues, il obéit.
Sasi Levi, de Noma, compare le cas à une injection SQL. L’analogie fait mal précisément parce qu’elle colle parfaitement. D’abord, on mélange données et commande dans le même canal. Ensuite, on continue à en payer le prix pendant plus de deux décennies.
GitHub avait des garde-fous, mais il a suffi du mot « Additionally » pour les faire tomber
C’est le point qui devrait inquiéter n’importe quelle équipe de plateforme. Les chercheurs ont testé les protections existantes et elles sont tombées rapidement. Même, ajouter le mot Additionally à la commande suffisait déjà pour désaxer le modèle et libérer des données privées.
Remarquez ce que cela signifie concrètement. Il n’existe pas d’empreinte pour détecter l’intrusion, car il n’y a pas de binaire. Aucun avertissement ne se déclenche, car rien ne dévie du comportement attendu. L’agent a simplement exécuté ce qui lui a été ordonné, et le journal enregistre une opération légitime.
Ainsi, si votre défense repose sur la reconnaissance d’une intention malveillante dans le texte, elle est déjà défaillante. Les modèles de langage n’ont pas de parseur séparant commande et contenu. Tant que cela ne changera pas, un simple filtre de mots restera un pansement.
GitHub a mis à jour la documentation, et c’est ce que vous devez lire entre les lignes
Noma a alerté la plateforme. Selon l’agence, il n’y a pas eu de retour confirmant une correction de la faille. En revanche, GitHub a signalé avoir mis à jour la documentation qui a donné naissance à la configuration vulnérable.
En traduction pour ceux qui gèrent le pipeline: la responsabilité repart entre vos mains. Autrement dit, il n’existe pas de correctif qui tombe silencieusement et résout le problème. Il existe une recommandation de configuration, et il y a votre YAML.
GitLost n’est pas une faille isolée, c’est le coût d’accorder une clé maîtresse à un agent
Ici, il faut distinguer symptôme et maladie. Le symptôme est la fuite via une issue publique. La maladie, c’est l’étendue des permissions accordées par défaut aux agents autonomes.
Réfléchissez à la manière dont vous traiteriez un nouveau service en production. Auriez-vous donné un accès sans restriction à tous les dépôts de l’organisation ? Probablement pas. Toutefois, c’était exactement ce que plusieurs équipes ont fait en activant l’automatisation avec l’IA, car la promesse de productivité a précédé l’examen du threat model.
De plus, il existe un effet secondaire culturel. Comme l’agent écrit un texte convaincant, sa sortie paraît fiable. Ainsi, la revue humaine s’assouplit précisément là où il faudrait resserrer les contrôles.
Comment durcir votre workflow avant que le prochain GitLost n apparaisse
La recommandation centrale de Noma est directe: portée minimale. En détail, voilà ce que cela implique au quotidien :
Limitez l’agent au dépôt sur lequel il agit. Une permission globale signifie qu’une issue dans un projet de test peut atteindre le dépôt de paiements. Considérez donc l’accès inter‑dépôts comme une exception auditable, jamais comme défaut.
Séparez l’entrée utilisateur de l’instruction système. Le texte provenant de l’extérieur doit entrer en tant que donnée inerte. Ensuite, vérifiez que l’agent ne l’interprète pas comme une commande, même lorsqu’il s’en sert poliment.
Traitez les secrets comme si l’agent était hostile. Si le jeton se trouve dans l’environnement du workflow, considérez qu’il peut être exfiltré. Ainsi, vous prévoyez une rotation rapide et une portée par tâche dès le départ.
Ingénierisez la sortie, pas l’entrée. Comme l’injection est invisible dans le texte, surveillez les comportements: lectures hors cadre, requêtes externes, volume anormal de fichiers lus. Concrètement, le signal apparaît dans l’action, pas dans la phrase.
Révisez les workflows déclenchés par des événements publics. Issues, pull requests de forks et commentaires constituent des surfaces d’attaque. Avant tout, cartographiez lesquels de ces déclencheurs activent aujourd’hui un agent doté d’identifiants.
Ce que GitLost révèle sur la prochaine décennie de la sécurité
Chaque fois qu’une technologie mélange instruction et contenu dans le même canal, quelqu’un trouve le chemin. Cela s’est produit avec SQL. Cela s’est produit avec XSS. Et désormais, cela se produit avec le prompting.
La différence réside dans la barrière d’entrée. Avant, l’attaquant devait comprendre l’architecture technique. Aujourd’hui, il lui suffit d’écrire correctement en anglais.
En résumé, le travail n’est pas d’apprendre au modèle à être méfiant. Le travail consiste à s’assurer que, lorsqu’il sera trompé — et cela arrivera —, rien de sensible ne soit accessible.
Avec nous sur Instagram !
