A segurança no GitHub Actions ganhou uma nova proteção com uma atualização importante no actions/checkout, uma das ferramentas mais usadas em workflows de automação. A mudança foi criada para impedir uma técnica conhecida como Pwn Request, que pode permitir que código malicioso enviado por colaboradores externos seja executado dentro de ambientes com permissões elevadas.
Com o crescimento dos ataques contra a cadeia de suprimentos de software, os pipelines de CI/CD passaram a ser um dos principais alvos de criminosos. Um simples Pull Request criado a partir de um fork pode se transformar em uma brecha crítica quando workflows são configurados de forma incorreta, especialmente envolvendo o gatilho pull_request_target.
A partir de junho de 2026, o GitHub começará a aplicar mudanças automáticas no comportamento do actions/checkout para bloquear cenários considerados inseguros. A atualização busca proteger projetos open-source e empresas que utilizam automações no GitHub contra uma das formas mais comuns de abuso em pipelines.
O que é um ataque de Pwn Request e como o pull_request_target é explorado
Um Pwn Request é um tipo de ataque que explora a combinação entre código não confiável e permissões privilegiadas em workflows do GitHub. O problema normalmente aparece quando um projeto permite que alterações enviadas por usuários externos sejam executadas em um ambiente que possui acesso a recursos protegidos.
O principal ponto de atenção está no uso do evento pull_request_target.
Esse gatilho foi criado pelo GitHub para situações em que o workflow precisa rodar com o contexto da branch principal do repositório. Diferentemente do pull_request tradicional, ele executa usando a configuração e permissões do repositório base, permitindo tarefas como adicionar comentários automáticos ou realizar ações administrativas.
O risco aparece quando o workflow faz checkout do código enviado pelo Pull Request.
Um fluxo vulnerável pode funcionar assim:
- Um atacante cria um fork de um projeto público.
- Ele adiciona um código malicioso em uma alteração aparentemente normal.
- Envia um Pull Request para o repositório original.
- O workflow com pull_request_target é iniciado.
- O actions/checkout baixa o código criado pelo atacante.
- O código executa dentro de um ambiente com permissões do projeto principal.
Nesse cenário, o invasor pode tentar acessar informações sensíveis, explorar tokens de autenticação, modificar artefatos ou comprometer etapas de publicação.
Casos analisados no mercado envolvendo projetos como Nx, PostHog e TanStack ajudaram a demonstrar como ataques contra ferramentas de desenvolvimento e pipelines automatizados podem afetar comunidades inteiras.
Esses incidentes reforçaram uma preocupação crescente: proteger o código-fonte não é suficiente quando a automação responsável por testar e publicar esse código também pode ser explorada.
O que muda no actions/checkout v7 para bloquear workflows inseguros
A nova proteção será introduzida no actions/checkout v7, versão que passa a impedir automaticamente determinados usos considerados perigosos dentro de workflows que utilizam pull_request_target.
O objetivo é evitar que projetos façam checkout de código externo dentro de ambientes confiáveis sem uma confirmação explícita do administrador.
A mudança também será aplicada às versões anteriores do actions/checkout, reduzindo o impacto em projetos que ainda utilizam versões antigas da ação.
O bloqueio será acionado em situações como:
- Uso em repositórios que recebem Pull Requests vindos de forks externos.
- Tentativas de checkout utilizando referências relacionadas ao Pull Request, como SHA, head ou merge.
- Execução de código externo dentro de um contexto com permissões do repositório principal.
Na prática, workflows que antes funcionavam poderão começar a apresentar erros caso dependam de um comportamento considerado inseguro.
Para casos específicos, o GitHub disponibiliza o parâmetro allow-unsafe-pr-checkout.
Esse recurso permite desativar a proteção e continuar utilizando o comportamento anterior. Porém, ele deve ser usado com muita cautela, pois remove justamente a barreira criada para impedir ataques de Pwn Request.
A recomendação é utilizar essa opção somente quando o mantenedor entende completamente o fluxo executado e garante que o código processado pelo workflow é confiável.
Como melhorar a segurança no GitHub Actions e proteger pipelines CI/CD
A atualização do actions/checkout representa uma camada adicional de proteção, mas não substitui boas práticas de segurança em automações.
A primeira recomendação é evitar o uso de pull_request_target quando não existir uma necessidade real de permissões elevadas.
Para a maioria dos testes, validações e builds, o evento pull_request tradicional oferece uma abordagem mais segura, pois reduz o acesso do workflow ao ambiente protegido do projeto.
Outro ponto fundamental é aplicar o princípio do menor privilégio ao GITHUB_TOKEN.
Esse token deve possuir apenas as permissões necessárias para executar determinada tarefa. Um workflow responsável apenas por rodar testes não deveria ter permissão para alterar código, criar releases ou publicar pacotes.
Também é importante revisar regularmente:
- Arquivos YAML dos workflows.
- Permissões definidas para cada ação.
- Segredos armazenados no repositório.
- Scripts executados automaticamente.
- Ações de terceiros utilizadas nos pipelines.
Mesmo com a proteção do actions/checkout atualizado, outras partes da automação continuam podendo apresentar riscos.
Scripts personalizados, dependências instaladas durante builds e ferramentas externas ainda precisam passar por análise de segurança.
A proteção do GitHub reduz uma categoria específica de vulnerabilidade, mas a segurança completa depende de uma revisão constante de todo o processo de desenvolvimento.
Por que essa mudança é importante para projetos open-source
Projetos de código aberto dependem da colaboração da comunidade, mas essa abertura também cria desafios de segurança.
Milhares de repositórios recebem diariamente contribuições de pessoas desconhecidas, tornando os workflows automatizados um alvo atrativo para ataques.
A mudança do GitHub representa uma tentativa de equilibrar produtividade e proteção, colocando uma barreira automática contra configurações que historicamente causaram problemas.
Para desenvolvedores, administradores de sistemas e equipes DevSecOps, a atualização é um alerta para revisar como os pipelines estão estruturados.
Antes da implementação automática em 2026, vale analisar todos os workflows existentes, principalmente aqueles que utilizam pull_request_target junto com o actions/checkout.
A evolução da segurança no GitHub Actions mostra que ferramentas de desenvolvimento estão adotando cada vez mais mecanismos preventivos. Bloquear comportamentos perigosos por padrão reduz riscos, mas a responsabilidade dos mantenedores continua sendo essencial.
Revisar configurações, limitar permissões e entender cada etapa da automação são práticas fundamentais para manter projetos protegidos.
Agora é o momento de verificar seus arquivos YAML, atualizar seus workflows e preparar seus projetos para a nova proteção.
