Services Work Pricing Blog About Book a free call →
Blog

GitHub blocks pull_request_target by default: what to do

GitHub Actions will block pull_request_target in public repos from December 2, 2026. What changes, who is affected and how to prepare this week.

5 min readDevOpsInfrastructure

GitHub announced on November 2, 2026 that Actions will block pull_request_target events by default in public repositories (on GitHub Free, Team and Enterprise Cloud) from December 2, 2026, unless an Actions event policy explicitly allows them. If your SaaS company keeps any public repository (an SDK, a docs site, an open-source tool) with a workflow that uses this trigger, check it before November 9, when the first brownout (a temporary enforcement window) runs. Private and internal repositories are not affected. The details below come from GitHub's changelog entry and GitHub's documentation, as of November 2026.

What did GitHub announce, and when?

The changelog entry, dated November 2, 2026, says three things:

  • Enforcement starts December 2, 2026. The page notes that enforcement was previously scheduled for November 2, 2026.
  • Two brownouts come first, on November 9 and November 16, 2026, each from 16:00 to 18:00 UTC. During a brownout, blocked runs fail with an error annotation and the workflow does not execute. Afterwards the rule returns to evaluate mode, where workflows run with warnings.
  • The rule starts in evaluate mode, so you can see which runs it would block before enforcement.

It applies to public repositories on GitHub Free, GitHub Team and GitHub Enterprise Cloud. GitHub Enterprise Server is not included.

What actually changes compared with before?

Before this rule, pull_request_target was a normal trigger in public repositories. After December 2, a default rule blocks it, and a run is allowed only if an applicable Actions policy lets it through.

The reason is how the trigger works. GitHub's documentation on workflow events says the event runs in the context of the default branch of the base repository. That design lets a workflow label or comment on pull requests from forks, and it prevents unsafe code from the pull request head from running by default. But the same page warns that running untrusted code on this trigger "may lead to security vulnerabilities", including cache poisoning and unintended access to write privileges or secrets, and advises avoiding the event if you need to build or run code from the pull request.

The risky combination, described in detail by GitHub Security Lab, is a pull_request_target workflow that checks out the pull request's head commit and then builds or installs it. Install scripts such as npm's preinstall and postinstall then run the contributor's code with the base repository's privileges.

Who should care, and who can ignore it?

Care if you have a public repository and any workflow file contains pull_request_target. GitHub's documentation names labeling and commenting on pull requests from forks as what the trigger is for; other automation on fork pull requests may use it too.

Probably ignore if all your repositories are private or internal, or you run GitHub Enterprise Server. The changelog says private and internal repositories are not affected. We would still run a quick search across your organization to confirm which repositories are actually public, since forgotten ones are common.

What does it cost, and what are the limits?

The changelog and the policy documentation state no price for the rule. The documentation notes that choosing "Evaluate" mode yourself for a policy you create is available on GitHub Enterprise Cloud only. The changelog says the default rule itself starts in evaluate mode and tells you to use Insights. The real cost is engineering time: finding the workflows, deciding whether each needs the trigger, and rewriting those that do.

How can a team prepare this week?

  1. Find every use. Search your organization's workflow files for pull_request_target. List repository, workflow and what it does.
  2. Check the insights. GitHub says to use Insights before November 9 to see which workflow runs the rule would block. Policies are under Settings, then Actions, then Policies in the repository or organization, with a separate policy insights page under it, per the policy documentation.
  3. Decide per workflow. GitHub gives two choices: keep the default block, or allow the trigger explicitly in an applicable Actions event policy, with workflow file targeting to allow only specific workflows. The page describes no separate opt-out.
  4. Prefer a safer design where you can. If the workflow does not need secrets or write access, pull_request is the usual replacement. If it needs both, GitHub Security Lab describes a two-workflow pattern: an unprivileged pull_request workflow builds and saves results as artifacts, and a separate workflow_run workflow with write access reads them and acts, for example by posting a comment. Treat those artifacts as untrusted data and never execute them in the privileged workflow.
  5. Plan for the brownouts. On November 9 and 16, 16:00 to 18:00 UTC, blocked workflows will fail. Warn contributors and maintainers so nobody mistakes it for an outage.

What would we check first?

Our approach is to start with inventory, not rewriting. For each workflow that uses the trigger, we ask four questions: does it check out the pull request head, does it run any code from it (build, test, install, scripts), which secrets and token permissions does it get, and could a pull_request workflow do the same job? A labeler that never checks out code is usually lower risk to allow explicitly. A workflow that builds the contributor's code with secrets available is the one to redesign first, whatever the deadline.

We would also confirm that the Actions policy setup matches what you think it is, because the rule only helps if the policy that applies to each repository is the one you chose. If your team has no senior engineer with time for CI/CD hardening, this is the kind of task our services cover.

General information based on GitHub's public announcement and documentation as of November 2026; not legal or security advice. Check the current GitHub documentation and consult a security professional for your own setup.