O GitHub anunciou em 2 de novembro de 2026 que, a partir de 2 de dezembro, o GitHub Actions vai bloquear por padrão eventos pull_request_target em repositórios públicos, a menos que uma política de eventos do Actions permita o gatilho de forma explícita. A data original era 2 de novembro e foi adiada em um mês. Antes disso há duas janelas de teste com bloqueio real, das 16:00 às 18:00 UTC (13h às 15h em Brasília): 9 de novembro, dia desta publicação, e 16 de novembro.
O que o bloqueio muda
pull_request_target roda no contexto do repositório de destino, com acesso aos segredos dele, mesmo quando o pull request vem de um fork. Por isso o gatilho é usado para tarefas que precisam de credencial em contribuições externas: rotular PRs, comentar resultados, publicar preview, rodar um bot de revisão. Pelo mesmo motivo, um workflow que executa o código do fork nesse contexto pode vazar segredos ou comprometer o pipeline. É esse risco que o GitHub cita para mudar o padrão.
Durante as janelas de teste, as execuções que seriam bloqueadas falham com uma anotação de erro e não rodam. Fora delas, a regra fica em modo de avaliação: os workflows rodam, mas com aviso. Em 2 de dezembro o bloqueio passa a valer o tempo todo.
Quem é afetado
Entram repositórios públicos nos planos GitHub Free, Team e Enterprise Cloud. Repositórios privados e internos ficam de fora, assim como o GitHub Enterprise Server. Um repositório que já tem uma política de eventos aplicável segue essa política, e não o padrão novo.
Na prática, o impacto maior cai sobre quem mantém projeto open source com contribuição externa e sobre empresas que publicam bibliotecas, SDKs, plugins ou temas em repositório público e automatizaram a triagem de PRs. Se o produto da empresa vive só em repositórios privados, esta mudança não chega a ele.
Esta é a segunda restrição do ano sobre o mesmo gatilho. Desde 20 de julho, o actions/checkout (v7 e as versões maiores anteriores ainda suportadas) recusa por padrão baixar o código do fork em pull_request_target, e só aceita com a opção allow-unsafe-pr-checkout. Aquela mudança limitava o que o workflow podia baixar; a de agora impede o workflow de começar.
O que fazer antes de 2 de dezembro
O primeiro passo é saber quais workflows dependem do gatilho. Uma busca por pull_request_target em .github/workflows dos repositórios públicos responde isso, e o GitHub indica a área de Insights do Actions para ver quais execuções a regra bloquearia. Uma falha de pull_request_target dentro das janelas de teste vem do bloqueio, não da infraestrutura.
Depois, para cada workflow encontrado, há duas saídas:
- se ele não precisa de segredos nem de permissão de escrita, trocar para
pull_request, que em PRs de fork roda sem os segredos do repositório de destino; - se precisa, criar uma política de eventos que permita o gatilho, restrita ao arquivo daquele workflow. O GitHub recomenda esse recorte por arquivo em vez de liberar o repositório inteiro.
O segundo caso pede uma revisão do próprio workflow: se o workflow liberado executa algo vindo do fork, como script de build, dependência instalada a partir do PR ou comando montado com texto do PR, ele continua tão exposto quanto antes, agora com permissão explícita. Workflows de preview entram nesse grupo quando juntam código externo e credencial de deploy. A mesma lógica vale para os recursos que o preview alcança, como discuti em Um preview seguro precisa isolar os recursos conectados.
A decisão cabe a quem administra a organização ou o repositório no GitHub. Se a política for criada no nível da organização, ela vale para todos os repositórios públicos de uma vez, o que exige combinar com os mantenedores de cada projeto.
O que ainda não está claro
O anúncio não diz se o padrão vai chegar a repositórios privados e internos, nem se haverá algo equivalente no GitHub Enterprise Server. A data de aplicação também já mudou uma vez, e parte do material que circula ainda cita 2 de novembro. O changelog do GitHub é a referência para planejar a mudança.
Se a sua empresa está avaliando algo parecido, me chama no LinkedIn ou no WhatsApp.
