agentic-workflow-injection

Fixtures GitHub Actions reproductibles, vulnérables et corrigées, pour l'injection de workflows agentiques (CVE-2026-44246), avec couverture de détection mesurée et recommandations d'atténuation.

Ce n'est pas de l'injection de template. Rien n'est évalué comme du shell ; la charge utile est de la prose, et l'interpréteur est le modèle. C'est pourquoi le conseil habituel — citez vos variables, ne faites pas d'eval — ne s'applique pas, et pourquoi le correctif ci-dessous concerne ce que l'agent peut atteindre plutôt que l'échappement de l'entrée.

La partie à connaître : le commit de correction n'est pas le correctif

nnU-Net a durci ce workflow en deux commits, et un détecteur qui traite « avant » et « après » comme un binaire se trompe sur celui du milieu.

Le commit que tout le monde appellerait le correctif — son message est « hardened issue and PR agents » — a supprimé gh issue edit et routé les étiquettes via .github/scripts/safe-label.sh, mais a laissé Bash(gh issue comment:*) avec l'agent. L'agent pouvait toujours être orienté vers un commentaire, et le motif d'allowlist gh issue comment:* n'est pas limité à l'issue déclencheuse, donc la cible était au choix du modèle. Seul le troisième commit l'a fermé : l'agent écrit désormais /tmp/issue-comment.md et une étape ultérieure, non-agent, le publie avec ISSUE: ${{ github.event.issue.number }} pris depuis l'événement.

Deux choses en découlent, et c'est pourquoi ce dépôt n'est pas juste deux fichiers :

« Corrigé » est une affirmation sur une révision, pas sur une version. v2.4.1 est cité comme la version corrigée, mais son .github/workflows/ ne contient que codespell.yml — les workflows d'agent ne sont pas du tout dans ce tag. Vous ne pouvez pas vérifier le correctif depuis le tag ; vous devez épingler le commit.

Le bloc de permissions ne change jamais. issues: write est présent et correct dans les trois révisions, y compris la dernière, car une étape ultérieure en a besoin. Un détecteur qui se base uniquement sur permissions ne peut pas séparer la révision 1 de la révision 3. Ce qui les sépare, c'est ce que l'agent peut appeler.

Couverture mesurée

Trois détecteurs, exécutés sur les deux fixtures et les trois révisions réelles. Sortie brute complète et versions des outils dans results.md.

Aucun détecteur n'est simplement « faux » ici — ils répondent à des questions différentes :

• zizmor est un auditeur Actions généraliste. Il rapporte l'hygiène d'épinglage d'actions et de persistance des identifiants de manière identique sur les trois révisions. Hors périmètre pour cette classe par conception, et inclus parce que « le linter bien connu était propre sur le fichier vulnérable » est facilement confondu avec un bilan de santé propre.
• sisakulint dispose de règles IA conçues spécifiquement et est le seul outil ici qui nomme le mécanisme même du CVE : ai-action-prompt-injection se déclenche sur la révision vulnérable, où le corps de l'issue est interpolé dans prompt:, et s'arrête une fois l'interpolation disparue. Correct. Ses constats sur la révision ultérieure méritent d'être lus avant d'agir dessus — ai-action-excessive-tools signale Write, que ce workflow utilise volontairement pour écrire le fichier qu'une étape ultérieure publie ; et ai-action-execution-order veut l'agent en dernier, ce qui est exactement ce que cette conception évite, puisque les étapes privilégiées viennent après la fin du tour du modèle.
• agentbound est le seul outil qui sépare la révision 2 de la révision 3, en lisant l'allowlist d'outils de l'agent plutôt que les permissions du job. Son constat ci-agent-missing-author-association est rapporté à critical sur la révision ultérieure et son propre README décrit cela comme trop sévère plutôt que faux : auto-triage est censé être atteignable par n'importe qui.

Chaque outil ici a un constat qu'il rapporte sur une révision dont l'auteur avait déjà raisonné sur cette condition exacte. C'est l'état normal d'une heuristique, et la raison pour laquelle une table de couverture est plus utile qu'une colonne réussite/échec.

Utilisation

benchmark.sh signale un détecteur manquant comme manquant plutôt que de le sauter silencieusement, car une table de couverture qui omet discrètement un outil ne prouve rien à son sujet.

Les fixtures sont la forme réduite, écrites pour ce dépôt et sous licence MIT comme le reste. Elles sont fidèles au mécanisme plutôt que des copies : fixtures/vulnerable.yml porte les quatre conditions et rien d'autre, et fixtures/fixed.yml est le même fichier avec les six changements qui comptent, chacun annoté. Si vous ajoutez une règle, ces deux fichiers sont les plus petites entrées qu'elle doit traiter correctement.

Deux particularités d'interface, gérées dans le script mais bonnes à connaître :

• sisakulint n'analyse pas un fichier en dehors d'un dépôt git. Face à un tel fichier, il affiche not found et sort avec le code 3. Sans surveillance, cela ressemble exactement à un scan propre.
• Le path JSON d'agentbound est un basename, donc un scan de répertoire sur des fichiers portant le même nom est ambigu.

Correction

La détection est la moitié facile. docs/mitigations.md couvre l'autre moitié : comment borner l'autorité d'un agent, avec les couches classées selon une question — ce contrôle dépend-il du fait que le modèle choisisse de se conformer ?

Ce classement est tout l'intérêt. Une instruction dans un prompt est une entrée, pas une clause de garde ; un motif d'outil qui nomme sa cible, ou un token que l'agent ne détient jamais, est une borne. Le guide descend de « le modèle ne peut pas faire la mauvaise chose » à « on a demandé au modèle de ne pas le faire », avec une checklist et l'évolution de nnU-Net comme exemple concret.

fixtures/fixed.yml étiquette chacun de ses six changements avec la couche qu'il implémente et avec le fait qu'il soit porteur ou non — deux d'entre eux ne le sont pas, et sont étiquetés ainsi pour qu'un lecteur ne surestime pas le fichier.

Provenance

Récupéré à l'exécution par SHA de commit, jamais vendu :

Aucune copie de la configuration de nnU-Net n'est redistribuée ici ; relancez la récupération et comparez vous-même les octets avec les blobs ci-dessus.

Périmètre

Ceci est un artefact d'ingénierie de détection. Il ne contient aucun exploit, et rien ici n'a été testé contre un workflow en production — les révisions vulnérables sont des fichiers statiques, déjà publics dans l'historique de nnU-Net et référencés par un avis publié. Les fixtures sont marquées do not deploy parce qu'elles existent pour être détectées, pas copiées.

Si vous maintenez un détecteur pour cette classe et voulez une ligne dans la table, le script de benchmark est l'interface : ajoutez une section qui exécute votre outil sur targets et affiche ses constats, et les fixtures et révisions épinglées font le reste.

MIT.