Pwn Request: mesmo com as mudanças do GitHub em 2026, ainda há brechas em pipelines do GitHub Actions

O texto da Wiz parte de um fato: o pull_request_target roda com segredos do repositório e pode ser disparado por qualquer pessoa que abra um PR de fork. Em 2026, o GitHub respondeu com proteções no actions/checkout, tokens de cache somente leitura e políticas de evento. A partir de 2 de dezembro, o pull_request_target deixa de rodar em repositórios públicos sem uma política de evento que o permita. Isso é um padrão, não uma proibição, e não cobre repositórios privados, internos nem o workflow_run.

As brechas que sobram são concretas. Quem fixa o checkout em SHA anterior à release de backport de 20 de julho de 2026 roda código legado, sem nenhuma verificação. Tags como @v4 (que resolve para v4.4.x) e @v4.4.0 continuam protegidas, enquanto @v4.3.0 e SHAs dessa versão não. As versões mínimas corrigidas são v2.8.0, v3.7.0, v4.4.0, v5.1.0, v6.1.0 e v7.0.0 ou superior. Checkouts feitos por CLI ou por actions de terceiros também escapam, porque a proteção vive dentro da action. O script injection (interpolação de ${{ }} em shell) não envolve checkout e não é tocado pelas mudanças. Triggers como issue_comment e repository_dispatch seguem sem proteção de checkout. Há ainda envenenamento via artefatos (pull_request para workflow_run) e estado persistente em runners self-hosted não efêmeros. A flag allow-unsafe-pr-checkout reabre o vetor antigo.

Em 24 de junho de 2026, o CEVIU noticiou "GitHub endurece actions/checkout para bloquear pwn requests comuns": o checkout passou a bloquear por padrão refs arriscados de forks em pull_request_target e workflow_run. A análise atual mostra o que essa mudança não cobre: versões antigas fixadas por SHA, issue_comment, repository_dispatch e checkouts fora da action. Em 22 de maio de 2026, o CEVIU tratou o envenenamento de cache no GitHub Actions; agora os tokens de cache somente leitura fecham esse caminho, mas os artefatos continuam abertos.

Para quem opera pipelines, a leitura é que fixar SHA, conselho padrão de supply chain, passa a exigir revisão: um SHA velho pode valer menos que uma tag atualizada. Antes de 2 de dezembro, vale auditar workflows, comparar SHAs com as versões corrigidas, trocar interpolação por variáveis de ambiente e usar runners efêmeros onde eventos não confiáveis disparam jobs.