GitHub Actions: pull_request_target bloqueado por padrão em 2 de dezembro, primeiros testes de interrupção neste 9 de novembro
A partir de 2 de dezembro de 2026, o GitHub bloqueará por padrão o gatilho pull_request_target em todos os repositórios públicos. Antes disso, dois testes de interrupção de duas horas, em 9 e 16 de novembro, das 17h às 19h (horário de Paris), farão os workflows afetados falharem.
Se você mantém um repositório público no GitHub que utiliza o gatilho pull_request_target, anote o horário: nesta segunda-feira, 9 de novembro, das 17h às 19h (horário de Paris), seus workflows podem falhar. Trata-se do primeiro de dois testes de interrupção anunciados pelo GitHub antes do bloqueio por padrão desse gatilho, em 2 de dezembro de 2026, em todos os repositórios públicos (changelog).
Por que esse gatilho está na mira
O pull_request_target serve principalmente para automatizar reações a pull requests originadas de forks: rotulagem, triagem, comentários e status. Sua particularidade: ele roda no contexto do repositório base, com acesso aos seus secrets e a um token com permissão de gravação. Desde que o workflow execute apenas o código do branch padrão, não há perigo. Mas, se ele fizer checkout e executar o código da pull request, um colaborador mal-intencionado pode comprometer a cadeia de integração ou roubar secrets. Esse é o motivo apresentado pelo GitHub, cuja documentação alerta: um workflow acionado dessa maneira nunca deve compilar nem executar código de uma pull request não confiável com acesso aos secrets.
O cronograma
- Até 2 de dezembro: a regra padrão roda em modo de avaliação, com os workflows sendo executados acompanhados de alertas.
- 9 e 16 de novembro, das 16h às 18h UTC (17h às 19h em Paris): bloqueio temporário. Os workflows afetados geram execuções com falha e uma anotação de erro.
- 2 de dezembro: bloqueio permanente por padrão, exceto com autorização explícita. O prazo original era 2 de novembro.
Estão envolvidos os repositórios públicos no GitHub Free, Team e Enterprise Cloud. Os repositórios privados e internos, assim como o GitHub Enterprise Server, não são afetados.
O que fazer antes de segunda-feira
O GitHub aconselha abrir os Insights para identificar as execuções que seriam bloqueadas. A partir daí, há três cenários: se o workflow não precisa de secrets nem de permissão de gravação, mude para o gatilho pull_request; se realmente precisar, autorize-o em uma política de eventos do Actions, restringindo a regra apenas a esse arquivo de workflow e garantindo que ele nunca execute o código da pull request; caso contrário, deixe o bloqueio cumprir seu papel.
Nossa leitura
O pull_request_target é uma armadilha conhecida entre mantenedores, pois a linha divisória entre “reagir a uma pull request” e “executar seu código” é fácil de cruzar por engano. Inverter a configuração padrão é a decisão certa, e as interrupções de teste evitam surpresas no dia definitivo. O risco cresce à medida que agentes de código abrem pull requests em larga escala em projetos públicos: quanto mais contribuições automatizadas, mais um workflow permissivo se torna um alvo. Para os mantenedores, o esforço é pequeno, mas deve ser feito agora: alguns minutos nos Insights evitam uma noite inteira de CI no vermelho.
Fontes
- GitHub Changelog — pull_request_target blocked by default December 2 (2 de novembro de 2026) Fonte primária
- GitHub Docs — Securely using pull_request_target Fonte primária
Uma fonte primária vem diretamente da empresa, do laboratório ou da organização envolvida. Uma fonte secundária relata a informação sem ser a sua autora: nós a sinalizamos como tal. Encontrou um erro? Consulte nossa política de correções.
