GitHub bloqueia pull_request_target em 2/12: como ajustar seus workflows
Quem mantém um repositório público no GitHub com workflows disparados pelo evento pull_request_target tem até 2 de dezembro de 2026 para decidir se libera esse gatilho. A partir dessa data, o GitHub Actions passa a bloquear o evento por padrão em todos os repositórios públicos que não tiverem uma política de eventos autorizando seu uso, segundo aviso publicado no changelog oficial em 2 de novembro de 2026.
$ ls ./neste-artigo
Antes disso há dois ensaios. Em 9 e 16 de novembro, das 13h às 15h no horário de Brasília (16h às 18h UTC), o bloqueio será ligado de verdade: as execuções afetadas falham com uma anotação de erro e o workflow não roda. Fora dessas janelas, a regra volta ao modo de avaliação, em que tudo funciona, mas com aviso. Para quem tem um pipeline de testes de contribuições externas, a primeira janela já é o momento de descobrir o que quebra.
Linha do tempo do bloqueio, de setembro a dezembro
| Data | Marco | Situação |
|---|---|---|
| 17/9/2026 | Proteções de execução de workflows saem da prévia e ficam disponíveis para todos, já com a regra padrão contra pull_request_target em modo de avaliação | Concluído |
| 21/10/2026 | GitHub atualiza o anúncio e passa a aplicação automática para 2/12 | Concluído |
| 2/11/2026 | Changelog confirma a data, os repositórios afetados e os testes de bloqueio | Concluído |
| 9/11/2026 | Primeiro teste de bloqueio, das 13h às 15h (Brasília) | Previsto |
| 16/11/2026 | Segundo teste de bloqueio, das 13h às 15h (Brasília) | Previsto |
| 2/12/2026 | Bloqueio padrão passa a valer de forma permanente | Previsto |
A data de 2 de dezembro já é resultado de um adiamento: o próprio changelog de novembro registra que a aplicação estava marcada antes para 2 de novembro. O anúncio de setembro sobre as proteções de execução ganhou uma nota do editor em 21 de outubro com a nova data.
Segredos expostos a código de fork: o risco do evento
O pull_request_target roda no contexto do repositório de destino, não no do fork que abriu o pull request. Isso dá ao workflow acesso aos segredos do repositório de destino, algo que um PR comum vindo de fork não recebe. O evento foi pensado para tarefas que não executam o código da contribuição, como rotular um PR ou postar um comentário.
O problema aparece quando o workflow faz checkout do código enviado pelo fork e o executa, por exemplo rodando testes ou um script de build. Nesse caso, qualquer pessoa pode abrir um PR com um script malicioso que lê os segredos ou altera o pipeline. É esse cenário que o GitHub cita para justificar o bloqueio: código não confiável, vindo de fork, com acesso a credenciais.
Repositórios públicos no Free, Team e Enterprise Cloud
A regra vale para repositórios públicos nos planos GitHub Free, GitHub Team e GitHub Enterprise Cloud. Ficam de fora os repositórios privados e internos e o GitHub Enterprise Server, a versão instalada nos servidores da própria empresa. Também escapa quem já tem uma política de eventos do Actions aplicável ao repositório, porque é ela, e não a regra padrão, que define se o evento roda.
Policy insights: a lista do que falharia
O GitHub recomenda olhar os dados de Insights antes do primeiro teste. Pela documentação de controle de execução de workflows, o caminho é este:
- No repositório ou na organização, abra a aba Settings.
- Na barra lateral, em Actions, clique em Policies.
- Logo abaixo aparece a página Policy insights, que mostra as execuções bloqueadas e as que seriam bloqueadas no modo de avaliação.
- Anote quais workflows aparecem e se algum deles faz checkout do código do PR.
Em contas corporativas, o mesmo fica em Policies, depois Actions e Policies, no nível da empresa. Podem configurar administradores do repositório, donos da organização e donos da conta corporativa.
Liberar só o workflow que precisa do evento
Quem depende do pull_request_target pode permiti-lo numa política de eventos do Actions e usar o direcionamento por arquivo de workflow para liberar apenas os caminhos necessários, por exemplo o arquivo que rotula PRs, sem abrir o evento para o repositório inteiro. As políticas também podem ser gerenciadas pela API REST do Actions, útil para quem administra dezenas de repositórios. Antes de liberar, pergunte se o workflow precisa mesmo de segredos: se ele só roda testes do código enviado, o evento pull_request, que não entrega segredos a forks, costuma resolver.
Confirmado e pendente no anúncio do GitHub
| Já confirmado | Ainda sem resposta |
|---|---|
| Bloqueio padrão em 2/12 nos repositórios públicos sem política aplicável | Se haverá novos testes depois de 16/11 |
| Testes em 9/11 e 16/11, das 13h às 15h (Brasília) | Quantos repositórios e workflows serão afetados |
| Privados, internos e GitHub Enterprise Server fora da regra | Se a data pode mudar de novo, como já mudou uma vez |
| Execuções bloqueadas falham com anotação de erro | Se o Enterprise Server receberá regra parecida no futuro |
A automação do seu repositório pode depender de outros pontos do pipeline afetados pela mudança. Para revisar o fluxo inteiro, do commit ao deploy, há o guia O que é CI/CD e como automatizar testes e entregas de software.
Teste de 9 de novembro, das 13h às 15h: o marco a acompanhar
A próxima data é a segunda-feira, 9 de novembro, quando o bloqueio fica ativo por duas horas. Se um workflow seu falhar nessa janela com anotação de erro ligada à política, ele vai parar de vez em 2 de dezembro, a menos que você o libere numa política de eventos ou troque o gatilho. O segundo teste, em 16 de novembro, no mesmo horário, serve para confirmar o ajuste. Para quem quer reforçar outras partes da cadeia de suprimentos de software no GitHub, o texto GitHub Package Firewall: como proteger pacotes npm mostra outra proteção recente da plataforma.
