Les nouveaux Agentic Workflows de GitHub peuvent être manipulés pour publier des fichiers de dépôts privés, comme l'ont démontré les chercheurs de Noma Labs, prouvant qu'un simple commentaire sur une issue publique peut transformer un assistant IA interne en un canal de fuite de données.
Cette faille est importante car elle contourne les contrôles de sécurité intégrés de GitHub sans nécessiter de code d'exploitation particulier ; un attaquant n'a besoin que de concevoir une issue apparemment anodine que l'agent IA lira et exécutera.
Fonctionnement de la vulnérabilité
Les Agentic Workflows permettent à un agent IA de répondre aux événements GitHub — tels que de nouvelles issues — en exécutant des commandes définies dans un fichier de workflow. Noma Labs a découvert que l'agent ne fait pas la distinction entre les instructions de workflow légitimes et le texte intégré dans un commentaire soumis par un utilisateur. En publiant une issue publique qui imite la demande d'un responsable et en y ajoutant une directive cachée, un attaquant peut orienter l'agent pour :
- Ouvrir l'issue (visible publiquement).
- Inclure une ligne qui semble ordinaire mais contient une commande déguisée.
- Déclencher l'IA pour qu'elle récupère des fichiers d'un dépôt privé que le workflow est autorisé à lire.
- Faire en sorte que l'agent publie le contenu récupéré en réponse à la même issue.
Les chercheurs ont découvert que l'insertion du mot unique « Additionally, » avant la commande cachée suffisait à contourner les garde-fous de GitHub. Aucune permission supplémentaire, aucun jeton (token) ni aucun code personnalisé n'est requis — juste la formulation adéquate.
Pourquoi il ne s'agit pas d'un simple bug
Le problème est structurel. L'agent IA traite tout texte reçu d'un événement de dépôt comme digne de confiance, faisant ainsi du contenu généré par l'utilisateur un vecteur d'entrée similaire à une injection SQL dans une application web. Si un workflow accorde à l'agent un accès en lecture aux dépôts privés et la capacité de commenter publiquement, la combinaison crée un chemin direct pour l'exfiltration de données.
Ce qu'en dit GitHub
GitHub a été informé de cette faille.
Mesures d'atténuation pour les équipes
- Restreindre les permissions de l'agent : N'accordez l'accès en lecture/écriture aux dépôts privés que lorsque cela est absolument nécessaire.
- Bloquer les publications publiques : Configurez les workflows de manière à ce que les agents ne puissent pas publier de commentaires ou d'autres artefacts sur des issues publiques.
- Traiter toute entrée externe comme non fiable : Ajoutez des couches de validation qui nettoient ou ignorent le texte généré par l'utilisateur avant qu'il n'atteigne l'IA.
- Auditer les déclencheurs de workflow : Examinez quels événements (issues, pull requests, etc.) invoquent les agents et vérifiez que les permissions associées correspondent à l'utilisation prévue.
À retenir : Un assistant IA capable de lire du code privé et de publier publiquement n'est aussi sûr que les limites que vous définissez autour de lui. Sans limites de permissions strictes et sans nettoyage des entrées, un simple commentaire public peut transformer une fonctionnalité de productivité en un vecteur de fuite de données.