agentic-workflow-injection

Fixtures reproduzíveis de GitHub Actions vulneráveis e corrigidas para injeção de fluxo de trabalho agêntico (CVE-2026-44246), com cobertura de detecção medida e orientação de mitigação.

Não é injeção de template. Nada é avaliado como shell; o payload é prosa, e o interpretador é o modelo. É por isso que o conselho habitual — coloque suas variáveis entre aspas, não use eval — não se aplica, e por isso a correção abaixo é sobre o que o agente pode alcançar em vez de sobre escapar a entrada.

A parte que vale a pena saber: o commit de correção não é a correção

O nnU-Net endureceu este fluxo de trabalho em dois commits, e um detector que trata "antes" e "depois" como binário erra o do meio.

O commit que todos chamariam de correção — sua mensagem é "hardened issue and PR agents" — removeu gh issue edit e encaminhou rótulos através de .github/scripts/safe-label.sh, mas deixou Bash(gh issue comment:*) com o agente. O agente ainda podia ser direcionado a comentar, e o padrão da allowlist gh issue comment:* não é restrito à issue que disparou o evento, então o alvo era escolha do modelo. Apenas o terceiro commit fechou isso: o agente agora escreve /tmp/issue-comment.md e um passo posterior, não-agente, o publica com ISSUE: ${{ github.event.issue.number }} obtido do evento.

Duas coisas decorrem disso, e são a razão pela qual este repositório não é apenas dois arquivos:

"Corrigido" é uma afirmação sobre uma revisão, não uma versão. v2.4.1 é citada como a release corrigida, mas seu .github/workflows/ contém apenas codespell.yml — os fluxos de trabalho do agente não estão nessa tag. Você não pode verificar a correção a partir da tag; você tem que fixar o commit.

O bloco de permissões nunca muda. issues: write está presente e correto em todas as três revisões, incluindo a última, porque um passo posterior precisa dele. Um detector que se baseia apenas em permissions não consegue separar a revisão 1 da revisão 3. O que as separa é o que o agente pode chamar.

Cobertura medida

Três detectores, executados sobre ambas as fixtures e todas as três revisões reais. Saída bruta completa e versões das ferramentas em results.md.

Nenhum detector está simplesmente "errado" aqui — eles respondem a perguntas diferentes:

• zizmor é um auditor de Actions de propósito geral. Ele reporta higiene de ações fixadas e persistência de credenciais de forma idêntica nas três revisões. Fora do escopo desta classe por design, e incluído porque "o linter bem conhecido estava limpo no arquivo vulnerável" é facilmente confundido com um atestado de saúde.
• sisakulint tem regras de IA construídas especificamente e é a única ferramenta aqui que nomeia o próprio mecanismo do CVE: ai-action-prompt-injection dispara na revisão vulnerável, onde o corpo da issue é interpolado em prompt:, e para assim que a interpolação desaparece. Correto. Suas descobertas na revisão posterior valem a pena ler antes de agir sobre elas — ai-action-excessive-tools sinaliza Write, que este fluxo de trabalho usa de propósito para escrever o arquivo que um passo posterior publica; e ai-action-execution-order quer o agente por último, que é exatamente o que este design evita, já que os passos privilegiados vêm depois que o turno do modelo termina.
• agentbound é a única ferramenta que separa a revisão 2 da revisão 3, ao ler a allowlist de ferramentas do agente em vez das permissions do job. Sua descoberta ci-agent-missing-author-association é reportada como critical na revisão posterior e seu próprio README descreve isso como excessivamente severo em vez de falso: auto-triage deve ser alcançável por qualquer pessoa.

Toda ferramenta aqui tem uma descoberta que reporta em uma revisão cujo autor já havia raciocinado sobre exatamente aquela condição. Esse é o estado normal de uma heurística, e a razão pela qual uma tabela de cobertura é mais útil do que uma coluna de passa/falha.

Usando

benchmark.sh reporta um detector ausente como ausente em vez de pulá-lo silenciosamente, porque uma tabela de cobertura que omite discretamente uma ferramenta não prova nada sobre ela.

As fixtures são a forma reduzida, escritas para este repositório e licenciadas sob MIT como o resto dele. Elas são fiéis ao mecanismo em vez de cópias: fixtures/vulnerable.yml carrega as quatro condições e nada mais, e fixtures/fixed.yml é o mesmo arquivo com as seis mudanças que importam, cada uma anotada. Se você está adicionando uma regra, esses dois arquivos são as menores entradas que ela precisa acertar.

Duas peculiaridades de interface, tratadas no script mas que vale a pena conhecer:

• sisakulint não analisa um arquivo fora de um repositório git. Recebendo um, ele imprime not found e sai com 3. Sem vigilância, isso parece idêntico a uma varredura limpa.
• O JSON path do agentbound é um basename, então uma varredura de diretório sobre arquivos com o mesmo nome é ambígua.

Corrigindo

Detecção é a metade fácil. docs/mitigations.md cobre a outra metade: como limitar a autoridade de um agente, com as camadas classificadas por uma pergunta — este controle depende de o modelo escolher obedecer?

Essa classificação é o ponto central. Uma instrução em um prompt é entrada, não uma cláusula de guarda; um padrão de ferramenta que nomeia seu alvo, ou um token que o agente nunca possui, é um limite. O guia desce de "o modelo não pode fazer a coisa errada" até "foi pedido ao modelo que não a fizesse", com uma checklist e a evolução do nnU-Net como o exemplo prático.

fixtures/fixed.yml marca cada uma de suas seis mudanças com a camada que ela implementa e com se ela é estrutural — duas delas não são, e estão rotuladas assim para que um leitor não superestime o arquivo.

Proveniência

Buscado em tempo de execução por SHA do commit, nunca vendorizado:

Nenhuma cópia da configuração do nnU-Net é redistribuída aqui; execute novamente o fetch e compare os bytes você mesmo contra os blobs acima.

Escopo

Este é um artefato de engenharia de detecção. Ele não contém exploit, e nada aqui foi testado contra um fluxo de trabalho ativo — as revisões vulneráveis são arquivos estáticos, já públicos no histórico do nnU-Net e referenciados por um advisory publicado. As fixtures estão marcadas do not deploy porque existem para serem detectadas, não copiadas.

Se você mantém um detector para esta classe e quer uma linha na tabela, o script de benchmark é a interface: adicione uma seção que executa sua ferramenta sobre targets e imprime suas descobertas, e as fixtures e revisões fixadas fazem o resto.

MIT.