O GitHub está reforçando a segurança da cadeia de suprimentos de software com uma atualização do actions/checkout para bloquear ataques do tipo 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 do actions/checkout, a action oficial do GitHub para fazer o checkout de um repositório no ambiente de execução do fluxo de trabalho, passou a recusar por padrão padrões comuns de pwn request.
A mudança também será levada para todas as versões principais atualmente suportadas em 16 de julho de 2026.
O actions/checkout v7 recusa buscar código de pull request de fork em fluxos pull_request_target e workflow_run. Neste último caso, a recusa vale apenas quando workflow_run.event for um evento pull_request, informou o GitHub.
A recusa ocorre quando o pull request vem de um fork e algum dos critérios abaixo é atendido, a menos que os autores do fluxo de trabalho optem explicitamente por permitir o comportamento, definindo a flag allow-unsafe-pr-checkout como true no actions/checkout:
repository resolve para o repositório do pull request do fork; ref corresponde a refs/pull/número/head ou refs/pull/número/merge; ou ref resolve para o commit SHA de head ou merge de um pull request de fork.
A medida tem como objetivo impedir a forma mais comum de pwn request no ecossistema Actions. Com isso, o actions/checkout vai falhar em eventos pull_request_target vindos de forks quando houver entradas inseguras.
O gatilho pull_request_target executa o fluxo de trabalho automaticamente, sem exigir aprovação manual, quando um pull request é aberto ou reaberto, ou quando a branch de origem é atualizada. O ponto crítico é que esse evento roda no contexto da branch padrão do repositório base, o que pode expor segredos e um GITHUB_TOKEN privilegiado, com permissões de leitura e gravação.
"Executar código não confiável no gatilho pull_request_target pode levar a vulnerabilidades de segurança", alerta o GitHub em sua documentação. "Essas vulnerabilidades incluem envenenamento de cache e concessão indevida de acesso a permissões de gravação ou segredos."
O risco aparece quando pull_request_target é combinado com actions/checkout para baixar e executar código enviado por um fork não confiável. Se um agente malicioso abrir um pull request com scripts maliciosos e o fluxo fizer o checkout e executar esse código, o invasor pode roubar o GITHUB_TOKEN e outros segredos, caracterizando um ataque de pwn request.
"Fluxos de trabalho acionados por pull_request_target executam com o GITHUB_TOKEN do repositório base, segredos e acesso ao cache da branch padrão", afirmou o GitHub. "Fazer o checkout da head de um pull request não revisado de um fork dentro de um desses fluxos normalmente permite que código controlado pelo invasor seja executado com todos os privilégios do fluxo."
Nos últimos meses, uma série de ataques à cadeia de software explorou esse comportamento. O caso mais grave foi o comprometimento de vários pacotes associados ao sistema de build Nx, em uma campanha codinome s1ngularity, além da invasão do PostHog, do TanStack e do popular pacote do Emacs kubernetes-el/kubernetes-el.
"O pull_request_target foi criado para automação confiável em torno de pull requests, como adicionar rótulos, comentar ou aplicar metadados do projeto", disse a Socket. "Mas a etapa de checkout controla qual código realmente entra no ambiente de execução. Se ela buscar código de um pull request de fork, o fluxo pode acabar executando código controlado pelo invasor com os privilégios do repositório base."
Ainda assim, a subsidiária da Microsoft destacou que pwn requests acionados por outros tipos de evento além do pull_request_target, como issue_comment, ou por outros meios, como git ou a GitHub CLI, estão fora do escopo dessa mudança.
"Esta alteração bloqueia apenas checkouts da head e dos commits de merge de pull requests de forks", acrescentou. "Ela não bloqueia checkouts de outros repositórios não confiáveis. Por exemplo, definir repository para 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 analisado."
Para reduzir o risco representado pelo pull_request_target, os desenvolvedores são orientados a avaliar esse gatilho e usá-lo apenas quando for realmente necessário, trocar para pull_request quando o fluxo não exigir permissões elevadas ou acesso a segredos, restringir as permissões concedidas aos fluxos de trabalho e garantir que entradas controladas pelo usuário não resultem na execução de código não confiável.
"A proteção desta atualização cobre apenas checkouts feitos por meio do actions/checkout", disse a Socket. "Isso faz dela uma barreira de proteção, não uma solução completa para a segurança do Actions. Fluxos que rodam com segredos, permissões de gravação, permissões de implantação ou acesso de publicação via OIDC ainda precisam de análise cuidadosa."
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...