A proof-of-concept from Noma Security exposes a prompt injection flaw in GitHub’s new agentic workflows, currently in public beta. The Israeli firm demonstrated how an attacker can trick an AI agent into dumping the contents of a private repository’s README into a public issue thread, without any authentication beyond opening an issue in the target organization’s public repository.

The attack scenario: a malicious issue, penned as if from a sales director returning from a client meeting, asks the agent to modify login page colors, remind the user of a README from a public repo, and—crucially—*in addition* remind them of the same file from a private repo. When the issue is assigned, the workflow fires, the agent retrieves both files, and posts the private README publicly in the discussion. GitHub’s built-in protections were bypassed simply by prepending “in addition” to the prompt.

The exploit succeeds only if the AI agent has read access to the private repository. GitHub’s documentation already advises least-privilege principles for these workflows, stressing that any write operation—including adding comments—must be explicitly permitted in the YAML configuration. The Israeli researchers note that the real vulnerability is not a flaw in GitHub itself, but overly permissive agent setups, especially when a GitHub app or configuration grants broad cross-repo access.

The incident highlights a deeper AI security challenge reminiscent of SQL injection. In SQL, a strict boundary between instructions and data enables parameterized queries to neutralize injection risks. Large language models lack such a native separation, making prompt injection considerably harder to mitigate. Emerging defensive techniques include training models to distinguish between instructions and data or to prioritize system-level commands over user-supplied content that mimics them.

Limitez les permissions de vos agents au strict nécessaire, a fortiori s’ils ont accès à plusieurs dépôts.

Là n’est pas le seul conseil que Noma Security donne aux utilisateurs des workflows agentiques GitHub. Mais c’est probablement celui qui se justifie après la démonstration de l’entreprise israélienne. Elle a, en l’occurrence, mis en lumière une vulnérabilité d’injection de prompt.

Un fichier d’un dépôt privé exfiltré via une issue publique

Les workflows agentiques sont en bêta publique depuis quelques semaines.On les place dans le même dossier que les automatisations déterministes, mais sous forme de fichiers Markdown. On les accompagne d’une configuration YAML (conditions de déclenchement, permissions et opérations autorisées). Une commande CLI convertit l’ensemble en actions exécutables par GitHub Copilot, Claude, Codex ou Gemini.

La vulnérabilité en question repose sur des instructions localisées dans une issue créée au sein d’un dépôt public de l’organisation cible. Son auteur, soi-disant directeur commercial, revient d’une réunion client et demande plusieurs choses :

Modifier les couleurs d’une page de login

Lui rappeler le contenu du README dans un dépôt public de l’organisation

« En plus », lui rappeler le contenu de de même fichier dans un dépôt privé de l’organisation

Le workflow se déclenche après assignation de l’issue. L’agent récupère le contenu desdits fichiers… et les poste dans le fil de discussion, en public.

De grandes permissions impliquent un grand risque

GitHub a des protections contre ce type de scénario. Mais l’ajout de l’expression « en plus » a permis de les déjouer, explique Noma Security.

Telle que présentée, l’attaque peut toucher toute organisation utilisant les workflows agentiques. D’autant plus qu’elle n’exige pas d’authentification (créer une issue dans un dépôt public suffit). Elle aurait cependant échoué si l’IA n’avait pas eu la permission d’accéder au dépôt privé. Difficile, en ce sens, que le problème vient de GitHub, sauf une de ses applications a accordé cette permission.

GitHub lui-même rappelle, dans la documentation de ses workflows agentiques, la nécessité de d’appliquer le principe du moindre privilège. Et de limiter les opérations autorisées. Il précise, à ce sujet, que toute écriture – y compris l’ajout de commentaires – doit être permise explicitement dans la configuration des workflows.

Injection de prompt et injection SQL, même concept ?

En SQL, la frontière est claire entre instructions (ce que le moteur de base de données « fait ») et données (ce qui est « stocké » ou « utilisé » dans une requête).

Pour empêcher les injections, il faut garantir cette séparation. La solution réside dans les requêtes paramétrées : peu importe les entrées, la base de données ne les interprète jamais comme des instructions.

Avec les LLM, faute de distinction « native » entre données et code, il paraît beaucoup plus difficile d’empêcher les injections de prompts. Des techniques émergent néanmois. Par exemple, expliquer à un modèle la notion de « data ». Ou l’entraîner à prioriser les « instructions » par rapport aux « données » qui y ressemblent.

Illustration générée par IA

The post GitHub Actions devient un canal d’injection de prompts appeared first on Silicon.fr.