agentic-workflow-injection

Fixture GitHub Actions riproducibili, vulnerabili e corrette, per l'iniezione di workflow agentici (CVE-2026-44246), con copertura del rilevatore misurata e indicazioni di mitigazione.

Non è template injection. Nulla viene valutato come shell; il payload è prosa, e l'interprete è il modello. Ecco perché il consiglio abituale — metti tra virgolette le tue variabili, non usare eval — non si applica, e perché la correzione sotto riguarda ciò che l'agente può raggiungere piuttosto che l'escaping dell'input.

La parte che vale la pena conoscere: il commit di correzione non è la correzione

nnU-Net ha rafforzato questo workflow in due commit, e un rilevatore che tratta "prima" e "dopo" come binari sbaglia quello intermedio.

Il commit che tutti chiamerebbero la correzione — il suo messaggio è "hardened issue and PR agents" — ha rimosso gh issue edit e instradato le etichette attraverso .github/scripts/safe-label.sh, ma ha lasciato Bash(gh issue comment:*) con l'agente. L'agente poteva ancora essere indirizzato a commentare, e il pattern dell'allowlist gh issue comment:* non è limitato all'issue che ha attivato il workflow, quindi l'obiettivo era a scelta del modello. Solo il terzo commit l'ha chiuso: l'agente ora scrive /tmp/issue-comment.md e uno step successivo, non-agentico, lo pubblica con ISSUE: ${{ github.event.issue.number }} preso dall'evento.

Ne seguono due cose, ed è per questo che questo repository non è solo due file:

"Corretto" è un'affermazione su una revisione, non su una versione. v2.4.1 è citato come la release corretta, ma il suo .github/workflows/ contiene solo codespell.yml — i workflow dell'agente non sono affatto in quel tag. Non puoi verificare la correzione dal tag; devi fissare il commit.

Il blocco dei permessi non cambia mai. issues: write è presente e corretto in tutte e tre le revisioni, inclusa l'ultima, perché uno step successivo ne ha bisogno. Un rilevatore che si basa solo su permissions non può separare la revisione 1 dalla revisione 3. Ciò che le separa è cosa l'agente può chiamare.

Copertura misurata

Tre rilevatori, eseguiti su entrambe le fixture e su tutte e tre le revisioni reali. Output grezzo completo e versioni degli strumenti in results.md.

Nessun rilevatore è semplicemente "sbagliato" qui — rispondono a domande diverse:

• zizmor è un auditor di Actions generico. Riporta l'igiene di pinned-action e persistenza delle credenziali in modo identico su tutte e tre le revisioni. Fuori scope per questa classe per design, e incluso perché "il linter ben noto era pulito sul file vulnerabile" è facilmente scambiato per un certificato di buona salute.
• sisakulint ha regole AI create appositamente ed è l'unico strumento qui che nomina il meccanismo stesso della CVE: ai-action-prompt-injection scatta sulla revisione vulnerabile, dove il corpo dell'issue è interpolato in prompt:, e si ferma una volta che l'interpolazione è sparita. Corretto. I suoi risultati sulla revisione successiva sono da leggere prima di agire su di essi — ai-action-excessive-tools segnala Write, che questo workflow usa di proposito per scrivere il file che uno step successivo pubblica; e ai-action-execution-order vuole l'agente per ultimo, che è esattamente ciò che questo design evita, dato che gli step privilegiati vengono dopo che il turno del modello è terminato.
• agentbound è l'unico strumento che separa la revisione 2 dalla revisione 3, leggendo l'allowlist degli strumenti dell'agente anziché i permissions del job. Il suo risultato ci-agent-missing-author-association è riportato come critical sulla revisione successiva e il suo stesso README lo descrive come eccessivamente severo anziché falso: auto-triage è pensato per essere raggiungibile da chiunque.

Ogni strumento qui ha un risultato che riporta su una revisione il cui autore aveva già ragionato su quella esatta condizione. Questo è lo stato normale di un'euristica, e il motivo per cui una tabella di copertura è più utile di una colonna pass/fail.

Usarlo

benchmark.sh segnala un rilevatore mancante come mancante anziché saltarlo silenziosamente, perché una tabella di copertura che omette tranquillamente uno strumento non prova nulla al riguardo.

Le fixture sono la forma ridotta, scritte per questo repository e con licenza MIT come il resto. Sono fedeli al meccanismo anziché copie: fixtures/vulnerable.yml porta le quattro condizioni e nulla più, e fixtures/fixed.yml è lo stesso file con le sei modifiche che contano, ciascuna annotata. Se stai aggiungendo una regola, quei due file sono gli input più piccoli che deve gestire correttamente.

Due stranezze dell'interfaccia, gestite nello script ma che vale la pena conoscere:

• sisakulint non analizza un file fuori da un repository git. Ricevutone uno, stampa not found ed esce con 3. Non osservato, sembra identico a una scansione pulita.
• Il path JSON di agentbound è un basename, quindi una scansione di directory su file con lo stesso nome è ambigua.

Correggerlo

Il rilevamento è la metà facile. docs/mitigations.md copre l'altra metà: come limitare l'autorità di un agente, con i livelli classificati secondo una domanda — questo controllo dipende dal fatto che il modello scelga di conformarsi?

Quella classificazione è il punto centrale. Un'istruzione in un prompt è input, non una guard clause; un pattern di strumento che nomina il suo obiettivo, o un token che l'agente non possiede mai, è un limite. La guida scende da "il modello non può fare la cosa sbagliata" a "al modello è stato chiesto di non farlo", con una checklist e l'evoluzione di nnU-Net come esempio pratico.

fixtures/fixed.yml etichetta ciascuna delle sue sei modifiche con il livello che implementa e con se è portante — due di esse non lo sono, e sono etichettate così affinché un lettore non sovrastimi il file.

Provenienza

Recuperate a runtime tramite SHA del commit, mai incluse nel repository:

Nessuna copia della configurazione di nnU-Net è ridistribuita qui; riesegui il fetch e confronta tu stesso i byte con i blob sopra.

Scope

Questo è un artefatto di detection-engineering. Non contiene alcun exploit, e nulla qui è stato testato contro un workflow live — le revisioni vulnerabili sono file statici, già pubblici nella storia di nnU-Net e referenziati da un advisory pubblicato. Le fixture sono marcate do not deploy perché esistono per essere rilevate, non copiate.

Se mantieni un rilevatore per questa classe e vuoi una riga nella tabella, lo script di benchmark è l'interfaccia: aggiungi una sezione che esegue il tuo strumento su targets e stampa i suoi risultati, e le fixture e le revisioni fissate fanno il resto.

MIT.