GitHub Actions vai bloquear pull_request_target: como se preparar

Resposta rápida

O GitHub tornou as workflow execution protections do Actions disponíveis de forma geral em 17 de setembro de 2026. Para repositórios públicos sem uma política de evento aplicável, o GitHub está adicionando uma regra padrão que bloqueia workflows iniciados por pull_request_target. A regra começa em modo Evaluate e será aplicada automaticamente em 2 de novembro de 2026 aos repositórios afetados que continuarem usando a política padrão.

Abra Settings, Actions e Policies, consulte Policy insights e identifique quais execuções seriam bloqueadas. Se o workflow não precisa de segredos ou token privilegiado, prefira pull_request. Se pull_request_target for indispensável, permita somente os arquivos necessários e garanta que nenhum código, dependência, script ou artefato vindo do pull request seja executado com segredos.

O que mudou com a disponibilidade geral

As proteções permitem criar listas de permissão sobre quem pode iniciar um workflow e quais eventos podem dispará-lo. Regras de atores controlam usuários, funções, GitHub Apps, Copilot e Dependabot. Regras de eventos controlam gatilhos como push, pull_request, pull_request_target e workflow_dispatch. As camadas do enterprise, da organização e do repositório são combinadas.

A versão geral acrescentou direcionamento por arquivo de workflow, Insights e uma API REST. Assim, deploy.yml pode aceitar somente uma equipe e determinados eventos, enquanto workflows de CI menos sensíveis seguem outra política. No GitHub Enterprise Cloud, o modo Evaluate funciona como simulação: mostra o que seria bloqueado antes de a regra ficar ativa.

Por que pull_request_target exige atenção

Um workflow iniciado por pull_request_target recebe o GITHUB_TOKEN do repositório base e pode acessar segredos do repositório ou da organização. Por padrão, o arquivo do workflow e um checkout sem ref vêm da branch padrão, que é confiável. O risco aparece quando o workflow busca código não confiável do fork e depois o executa com esse acesso privilegiado.

O padrão vulnerável é conhecido como pwn request. Ele pode surgir ao fazer checkout do head do pull request e executar make, npm install, testes, scripts de build ou arquivos de configuração enviados pelo autor externo. O mesmo cuidado vale para git fetch, gh pr checkout e artefatos produzidos por workflows de forks.

Como revisar o impacto antes de 2 de novembro

A regra padrão vale para repositórios públicos que não têm outra política de evento aplicável. Ela não se aplica a repositórios privados ou internos e não substitui políticas já configuradas. Enquanto estiver em Evaluate, as execuções continuam, mas o Insights registra quais seriam bloqueadas.

• Abra Settings no repositório ou na organização e acesse Actions, Policies.
• Entre em Policy insights e filtre execuções afetadas por pull_request_target.
• Anote o caminho de cada workflow, o ator, o evento e a razão da execução.
• Confirme se o workflow somente rotula, comenta ou faz triagem, ou se busca e executa código do pull request.
• Decida entre migrar para pull_request, manter o bloqueio ou criar uma permissão explícita e restrita.
• Repita a consulta depois da mudança e verifique no GitHub Status se Actions está operacional.

Como criar uma política de execução

No repositório ou na organização, a configuração fica em Settings, Actions e Policies. No enterprise, use Policies, Actions e Policies. O GitHub recomenda várias políticas pequenas e bem definidas em vez de uma única regra ampla. O enterprise pode impor requisitos inegociáveis, enquanto organizações e repositórios adicionam restrições.

• Crie a política e dê um nome que descreva o risco ou workflow protegido.
• Use Evaluate primeiro quando essa opção estiver disponível.
• Selecione os repositórios, organizações e caminhos de workflow que a regra deve alcançar.
• Defina os atores permitidos e lembre de incluir identidades necessárias, como dependabot[bot], quando aplicável.
• Permita somente os eventos necessários para cada workflow.
• Revise o Insights e só depois altere a aplicação para Active.

Como usar regras por arquivo sem abrir o repositório inteiro

A segmentação por caminho é uma das principais mudanças da disponibilidade geral. Em vez de permitir pull_request_target em todos os workflows, uma política pode atingir somente .github/workflows/triage.yml e manter .github/workflows/deploy.yml sujeito a regras mais rígidas.

Trate o caminho como uma redução de escopo, não como prova de segurança. Um arquivo permitido ainda precisa usar permissões mínimas, ações revisadas e entradas não confiáveis com cuidado. Evite curingas amplos quando o objetivo é liberar um workflow específico.

Quando migrar para pull_request

Use pull_request quando a automação precisa compilar ou testar o código proposto e não depende de segredos. Em pull requests vindos de forks, esse evento usa token somente leitura, não fornece outros segredos e aplica políticas de aprovação para reduzir abuso de processamento.

Se a automação precisa comentar ou rotular com acesso autenticado, considere separar a etapa que processa código não confiável da etapa privilegiada. Nunca transforme um artefato ou saída do workflow não confiável em comando executável no job que possui segredos.

Como endurecer um uso realmente necessário

Se pull_request_target for indispensável, não faça checkout, build ou execução do código do fork com segredos ou GITHUB_TOKEN privilegiado. npm install, scripts de teste e configurações trazidas pelo pull request também podem executar comandos, mesmo sem uma etapa de shell aparentemente perigosa.

• Defina permissions explicitamente e conceda ao GITHUB_TOKEN apenas o necessário.
• Exponha somente os segredos indispensáveis e prefira credenciais temporárias via OpenID Connect.
• Mantenha o acesso ao cache somente leitura; liberar escrita pode reintroduzir risco de envenenamento.
• Use runners efêmeros e isolados, sem acesso desnecessário à rede interna.
• Habilite CodeQL para GitHub Actions e revise ações de terceiros e referências de versão.
• Procure allow-unsafe-pr-checkout, refs de forks, git fetch, gh pr checkout e downloads de artefatos não confiáveis.

Automação pela API REST

A API REST permite listar, criar, ler, atualizar e excluir políticas no enterprise, na organização e no repositório. O campo workflow_path direciona a regra a arquivos específicos. Isso permite manter política como código e comparar a configuração de muitos repositórios sem depender apenas da interface.

Use token com a menor permissão administrativa possível, registre alterações e teste a política em Evaluate. Uma resposta 404 ou 403 pode indicar escopo, permissão ou disponibilidade do recurso, e não deve ser contornada com um token mais amplo sem investigação.

Aprovação de workflow suspeito continua sendo outra camada

Desde julho, o GitHub também retém determinados workflows potencialmente maliciosos em repositórios públicos para revisão autenticada por uma pessoa com permissão de escrita. Essa retenção automática e as políticas de execução resolvem problemas diferentes e podem atuar juntas.

Nenhuma delas transforma uma aprovação em auditoria. Antes de liberar a execução, confira gatilhos, comandos, secrets, permissões, ações externas e alterações do commit. Repositórios de agentes, skills e plugins merecem a mesma revisão porque o processo de instalação pode executar código com acesso a terminal, rede e tokens.

Limites e próxima ação útil

Este guia foi atualizado e verificado em 18 de setembro de 2026. A regra padrão está em Evaluate e o prazo de aplicação automática informado pelo GitHub é 2 de novembro de 2026. O comportamento pode mudar, e o status oficial mostra disponibilidade agregada, não a configuração específica do seu repositório.

Abra hoje o Policy insights, exporte a lista de workflows afetados e revise primeiro os que usam secrets, token com escrita, runners próprios ou checkout do código do fork. Migre para pull_request quando possível. Quando não for, restrinja o evento ao arquivo necessário e documente por que o workflow não executa conteúdo não confiável.

Fontes consultadas

Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.

• Workflow execution protections in GitHub Actions generally availableGitHub Changelog
• About Actions policiesGitHub Docs
• Controlling who can execute GitHub Actions workflowsGitHub Docs
• Securely using pull_request_targetGitHub Docs
• REST API endpoints for GitHub Actions policiesGitHub Docs
• GitHub Actions holds potentially malicious workflows for approvalGitHub Changelog
• OpenID ConnectGitHub Docs
• GitHub StatusGitHub