GitHub bloqueará pull_request_target por padrão em repositórios públicos
Uma mudança no GitHub Actions afeta fluxos privilegiados de pull requests. Veja como preparar os repositórios.
Além de ASPM
AppSec orientada por provas para equipes que desenvolvem com IA
A Plexicus usa AI Swarm Pentest para explorar caminhos autorizados da aplicação, validar o que é explorável e dar às equipes evidências para priorizar a remediação.
Explorar AI Swarm PentestEm 2 de dezembro de 2026, o GitHub pretende bloquear por padrão eventos pull_request_target em repositórios públicos, a menos que uma política aplicável de eventos do Actions os permita explicitamente. Antes disso haverá duas janelas temporárias de aplicação. A regra protege uma fronteira sensível e também pode interromper fluxos esperados.
Datas e abrangência
O GitHub publicou o cronograma atualizado em 2 de novembro. Antes da aplicação permanente, a regra está em modo de avaliação: fora das janelas, os fluxos afetados podem executar com avisos.
| Data | O que acontece |
|---|---|
| 9 de novembro de 2026, 16h–18h UTC | Primeira janela de aplicação temporária |
| 16 de novembro de 2026, 16h–18h UTC | Segunda janela de aplicação temporária |
| 2 de dezembro de 2026 | Início do bloqueio por padrão |
Durante cada janela, uma execução bloqueada falha com uma anotação de erro e o fluxo não é executado. A regra afeta repositórios públicos no GitHub Free, Team e Enterprise Cloud. Segundo o GitHub, repositórios privados e internos e o GitHub Enterprise Server não são afetados por essa regra.
Por que revisar esse evento
pull_request_target executa no contexto do repositório base. Segundo a referência de uso seguro do GitHub, fluxos privilegiados podem acessar permissões de escrita, segredos referenciados e o cache da branch principal. Fazer checkout e executar conteúdo não confiável de um pull request nesse contexto pode comprometer o pipeline ou expor segredos.
O nome do gatilho, sozinho, não prova uma vulnerabilidade explorável. Examine o código, scripts e artefatos efetivamente processados, as permissões e os segredos disponíveis e se contribuições de forks influenciam essas entradas. O GitHub também recomenda cautela com artefatos de execuções não confiáveis em fluxos workflow_run.
Antes da primeira janela
- Use o Insights para identificar as execuções que a regra bloquearia e atribua um responsável a cada fluxo.
- Decida se o trabalho precisa do evento privilegiado. Para executar código não confiável, considere
pull_requestcom as permissões mínimas. Teste forks e configurações do repositório; mudar o gatilho não substitui uma revisão de segurança. - Se o fluxo privilegiado for necessário, evite executar código não confiável, limite permissões e revise a fronteira dos artefatos. O GitHub explica como controlar a execução de fluxos.
- Mantenha o bloqueio por padrão quando possível. Se o evento for necessário, o GitHub oferece políticas explícitas e seleção de fluxos específicos. Revise cada exceção: permitir a execução não torna a entrada confiável.
- Faça um teste controlado antes de 9 de novembro e defina um responsável e um plano de reversão.
Conecte a decisão às evidências
A política define se um fluxo pode começar. A revisão também precisa registrar o que será executado e quais credenciais podem ser acessadas: versão do fluxo, origem do evento e resultado observado.
O AI Swarm Pentest da Plexicus descreve validação baseada em evidências para aplicações e APIs autorizadas; remediation apoia a transformação de achados validados em correções revisáveis. Use esses fluxos junto com uma revisão separada do GitHub Actions: uma análise de aplicação, sozinha, não comprova que a política do fluxo seja segura.
Revise os repositórios afetados antes da primeira janela. Conheça Plexicus remediation.
Imagem: captura de um parágrafo original do GitHub Docs, Secure use reference, sob CC BY 4.0. Isso não implica endosso.
