O GitHub está se movendo para fortalecer a segurança da cadeia de suprimentos de software ao atualizar a "actions/checkout". O objetivo é bloquear ataques pwn request que exploram o uso arriscado do gatilho "pull_request_target workflow" para executar código malicioso com todos os privilégios do fluxo de trabalho.
A partir de 18 de junho de 2026, a versão mais recente da "actions/checkout" — a action oficial do GitHub para fazer checkout de um repositório no runner do workflow — se recusará, por padrão, a processar padrões comuns de pwn request. A mudança deve ser portada para todas as versões principais atualmente suportadas em 16 de julho de 2026.
"A actions/checkout v7 se recusa a buscar o código de pull request de fork em fluxos de trabalho pull_request_target e workflow_run (este último apenas quando workflow_run.event é um evento pull_request*)", informou a empresa.
A recusa ocorre quando o pull request vem de um fork e qualquer um dos critérios a seguir é atendido, a menos que os autores do workflow optem explicitamente por desativar a proteção definindo o sinalizador "allow-unsafe-pr-checkout" como "true" na "actions/checkout":
- repository: resolve para o repositório do pull request do fork;
- ref: corresponde a refs/pull/number/head ou refs/pull/number/merge;
- ref: resolve para o SHA do commit de head ou merge do pull request do fork.
A mudança tem como objetivo prevenir a forma mais comum de pwn requests no ecossistema das Actions. Como resultado, a "actions/checkout" falhará em "eventos pull_request_target" vindos de forks com entradas inseguras.
Entendendo o gatilho pull_request_target
O "pull_request_target" é um gatilho de workflow executado automaticamente, sem exigir aprovação manual, quando um pull request é aberto ou reaberto, ou quando o branch de head do pull request é atualizado. É importante notar que o evento é executado no contexto do branch padrão do repositório de base, expondo potencialmente segredos e um GITHUB_TOKEN (token de acesso do GitHub) privilegiado, com permissões de leitura e escrita.
"Executar código não confiável no gatilho pull_request_target pode levar a vulnerabilidades de segurança", observa o GitHub em sua documentação. "Essas vulnerabilidades incluem envenenamento de cache (cache poisoning) e concessão de acesso não intencional a privilégios de escrita ou segredos."
O perigo surge quando um "pull_request_target" é combinado com a "actions/checkout" para baixar e executar código enviado por um fork não confiável. Caso um agente malicioso envie um pull request contendo scripts maliciosos e o workflow faça checkout e execute o código, o atacante pode roubar o GITHUB_TOKEN e outros segredos, levando ao que é chamado de ataque pwn request.
"Workflows acionados por pull_request_target são executados com o GITHUB_TOKEN, os segredos e o acesso ao cache do branch padrão do repositório de base", afirmou o GitHub. "Fazer checkout do head de um pull request não revisado de um fork dentro de um desses workflows normalmente permite que código controlado pelo atacante seja executado com todos os privilégios do workflow."
Nos últimos meses, diversos ataques à cadeia de software exploraram esse comportamento. O mais grave deles foi o comprometimento de múltiplos pacotes associados ao sistema de build Nx como parte de uma campanha batizada de s1ngularity, além das violações da PostHog, da TanStack e do popular pacote do Emacs, "kubernetes-el/kubernetes-el".
"O pull_request_target foi projetado para automação confiável em torno de pull requests, como rotulagem, comentários ou aplicação de metadados de projeto", disse a Socket. "Mas a etapa de checkout controla qual código de fato chega ao workspace do runner. Se ela puxar código de um pull request de fork, o workflow pode acabar executando código controlado pelo atacante com os privilégios do repositório de base."
Dito isso, a subsidiária da Microsoft enfatizou que pwn requests acionados por outros tipos de evento além do pull_request_target (por exemplo, issue_comment) ou por outros meios, como o git ou a CLI (interface de linha de comando) do GitHub, estão fora do escopo dessa mudança.
"Esta mudança bloqueia apenas checkouts do head e dos commits de merge de pull requests de fork", acrescentou. "Ela não bloqueia checkouts de outros repositórios não confiáveis. Por exemplo, definir repository: como um repositório de terceiros não relacionado não é bloqueado. Fazer checkout e executar qualquer código não confiável em um evento privilegiado continua sendo um risco de pwn request que deve ser revisado."
Recomendações para desenvolvedores
Para combater o risco representado pelo "pull_request_target", os desenvolvedores são orientados a avaliá-lo e usá-lo apenas quando necessário, mudar para "pull_request" se o workflow não exigir permissões elevadas ou acesso a segredos, restringir as permissões concedidas aos workflows e garantir que a entrada controlada pelo usuário não resulte na execução de código não confiável.
"A proteção nesta atualização cobre apenas checkouts realizados por meio da actions/checkout", disse a Socket. "Isso a torna uma barreira de segurança, não uma solução completa para a segurança das Actions. Workflows executados com segredos, permissões de escrita, permissões de implantação ou acesso de publicação OIDC (OpenID Connect) ainda precisam de revisão cuidadosa."
