A partir de 2 de dezembro de 2026, o GitHub Actions vai bloquear por padrão o evento pull_request_target em repositórios públicos.
A exceção é uma política de eventos do Actions que permita explicitamente esse gatilho.
A informação é CONFIRMADA. Ela consta no changelog oficial do GitHub, publicado em 2 de novembro de 2026.
A aplicação estava prevista antes para 2 de novembro. Ela foi adiada para 2 de dezembro.
Até lá, a regra padrão roda em modo de avaliação. Os workflows continuam executando.
O GitHub mostra quais execuções seriam bloqueadas. Assim, mantenedores podem ajustar suas políticas antes do bloqueio definitivo.
Antes da aplicação permanente, o GitHub vai impor a regra em duas janelas de teste. São os chamados brownouts.
As janelas serão em 9 e 16 de novembro de 2026, das 16h às 18h (UTC).
Nessas janelas, as tentativas bloqueadas viram execuções com falha. Elas recebem uma anotação de erro e não executam o workflow.
Depois de cada janela, a regra volta ao modo de avaliação, com avisos.
O risco que motiva a mudança é conhecido. O pull_request_target roda no contexto do repositório-base e pode acessar seus segredos.
Se um workflow executar código não confiável vindo de um fork, esse código pode comprometer o pipeline. Ele também pode roubar segredos.
Essa classe de ataque é conhecida como Pwn Request.
Por isso, o GitHub recomenda revisar o relatório Insights antes do primeiro brownout, em 9 de novembro. O relatório mostra quais execuções seriam bloqueadas.
O que os mantenedores devem fazer
Há duas opções, segundo o GitHub. A primeira é manter a regra padrão, deixando o gatilho bloqueado.
A segunda é permitir explicitamente o pull_request_target em uma política de eventos aplicável.
Nesse caso, o ideal é direcionar apenas os arquivos de workflow que realmente dependem dele.
Não se trata de uma proibição absoluta. Repositórios com política explícita continuam podendo usar o gatilho.
A regra não afeta repositórios privados e internos.
Ela vale para repositórios públicos no GitHub Free, GitHub Team e GitHub Enterprise Cloud. Ela não vale para o GitHub Enterprise Server.
A aplicação automática em 2 de dezembro vale para os repositórios afetados que usavam a política padrão antes da disponibilidade geral das proteções de execução.
Na prática, o recado é simples para quem mantém automações de pull requests de forks. Exemplos são rotuladores, triagem e verificações autenticadas.
Audite agora, em modo de avaliação, e libere só o necessário.
Deixar para 2 de dezembro é arriscar falhas silenciosas em automações que hoje parecem funcionar.
Crédito da imagem: GitHub, via ícone oficial do GitHub.
Fontes: GitHub Changelog — pull_request_target blocked by default December 2; GitHub Docs — Securely using pull_request_target; GitHub Changelog — Workflow execution protections generally available
Transparência: esta matéria foi produzida com auxílio de inteligência artificial, a partir do cruzamento de publicações públicas no X e de fontes na internet. Consulte as fontes originais para confirmar os detalhes antes de compartilhar.
Muse
