pull_request_target Workflows Blocked by Default Dec. 2

Starting December 2, 2026, GitHub Actions will block the pull_request_target workflow trigger by default in public repositories that haven't explicitly configured it to run. The rule only applies to public repos on GitHub Free, GitHub Team, and GitHub Enterprise Cloud — private and internal repositories, and GitHub Enterprise Server, are untouched. GitHub is rolling the change in gradually: it's currently running in "evaluate" mode (logging, not blocking), with two timed "brownout" windows on November 9 and November 16, 2026 before the rule is enforced permanently on December 2. If your workflows rely on pull_request_target, you need to decide, before that date, whether to let the trigger stay blocked or explicitly allow it back in.

What's actually changing on December 2

GitHub is adding a default-on security rule to GitHub Actions: in public repositories, a workflow run triggered by the pull_request_target event is blocked unless the repository, organization, or enterprise has an applicable Actions event policy that explicitly allows it. According to GitHub's changelog post announcing the change, the rule is already active in "evaluate" mode — it records which runs would have been blocked, without actually stopping them, so teams can see the impact in advance through Policy insights.

Permanent enforcement — where blocked workflows actually fail instead of just being logged — begins December 2, 2026. That date itself moved: GitHub's changelog post notes that "enforcement was previously scheduled for November 2, 2026" before being pushed back a month, giving maintainers extra runway to adjust.

Before the permanent switch flips, GitHub is running two scheduled brownouts, each from 16:00 to 18:00 UTC:

Outside of those two two-hour windows, nothing breaks between now and December 2 — the rule stays in evaluate mode, only warning. The brownouts exist specifically so teams can watch what would happen under full enforcement without waiting for the real deadline.

Why GitHub is doing this: the "pwn request" problem

pull_request_target is a workflow trigger built to let maintainers run automation — labeling, triage, status checks — against pull requests opened from forks. Unlike the ordinary pull_request event, a workflow triggered by pull_request_target runs in the context of the base repository: it gets a GITHUB_TOKEN with write access and can read the repository's and organization's secrets, even though the triggering pull request came from an untrusted fork.

That combination is the problem. GitHub's own security documentation on securely using pull_request_target walks through the attack pattern directly: checking out a fork's code isn't what's dangerous by itself — executing it is. A workflow that checks out a pull request's head commit and then runs something like make test will run whatever the fork's Makefile contains, with full access to the base repo's secrets. The same risk shows up through build scripts, test commands, dependency installs, or any other step that executes fork-controlled content. An attacker doesn't need commit access to the repo — just the ability to open a pull request, which anyone can do against a public repo.

This pattern is well known enough in the industry to have a name — a "pwn request" — and it's been behind a recurring string of real secret-exfiltration incidents across open-source projects. GitHub's docs note the same risk extends beyond pull_request_target to other secret-bearing triggers like issue_comment and workflow_run, and that artifacts produced by other workflow runs should also be treated as untrusted input rather than executed blindly.

What makes pull_request_target specifically worth a default block, rather than just a documentation warning, is how easy it is to reach for by accident. A maintainer wiring up a bot that comments on first-time contributors' pull requests, or runs a status check that needs to post back to the PR, will often switch from pull_request to pull_request_target purely to get write permissions and secret access — without necessarily registering that the same switch also hands fork-controlled input a path to those secrets if a later step checks out and runs that code. A default-deny rule removes the need to get that judgment call right on every single workflow, in every repository, forever; it only has to be configured correctly in the smaller number of cases where the trigger is genuinely needed.

Who's actually affected

The default block applies specifically to:

• Public repositories on GitHub Free, GitHub Team, and GitHub Enterprise Cloud.

It does not apply to:

• Private or internal repositories (any plan).
• GitHub Enterprise Server (self-hosted).

In practice, that means the change is aimed squarely at open-source projects — the repos where anyone on the internet can open a fork-based pull request, and where pull_request_target automation (bots that label, triage, or comment on PRs from first-time contributors) is both most common and most exposed. It's a different slice of the pull request experience than the pull request overview page GitHub previewed earlier this month, but the two sit on the same surface maintainers deal with daily.

How to tell if your workflows would be blocked

Because the rule has been running in evaluate mode, GitHub already has data on which of your public repository's workflows use pull_request_target and would be affected. GitHub's guide on controlling workflow execution describes checking Policy insights — available at the repository, organization, or enterprise level under Actions event policies — to see which runs the rule would have stopped, before enforcement actually bites. Reviewing that before each brownout window (and certainly before December 2) is the most direct way to know whether this change touches you at all.

The brownouts themselves double as a live test. During each two-hour window, a workflow run that would otherwise have been blocked instead actually fails, with an error annotation attached to the run explaining why — rather than just a warning buried in the logs. If a run you expected to succeed fails during one of the November windows, that's the signal to go configure an event policy before December 2, not after.

How to keep using pull_request_target if you legitimately need it

If your repository has a real, reviewed need for pull_request_target — and it's been built so fork code is never executed, only inspected — you don't have to lose it. GitHub's documentation describes the mechanism as an Actions event policy, configured under a repository's, organization's, or enterprise's Actions settings:

• Actor rules restrict which users or bots can trigger the targeted workflows.
• Event rules specify which trigger events are permitted — this is where pull_request_target would be explicitly added back to the allow list.
• Workflow file targeting scopes the policy to specific workflow file paths, rather than every workflow in the repo, so you can allow the trigger only for the one bot workflow that needs it instead of reopening it repo-wide.
• Evaluate vs. Active enforcement status lets you test a policy in shadow mode via Policy insights before switching it to actually take effect.

Put together, the recommended path is: create a policy, scope it with workflow file targeting to just the workflow(s) that need pull_request_target, add that event to the allow list, test it in Evaluate mode, and confirm in Policy insights before setting it to Active. Everything else in the repo keeps the default protection.

GitHub's security docs are explicit that opting back in should come with the same discipline that should already apply to any pull_request_target workflow: use pull_request instead wherever possible (it runs with a read-only token and no secret access); never build, run, or execute fork-provided code, only inspect it as data; grant the GITHUB_TOKEN the least privilege it needs; isolate any self-hosted runners involved with ephemeral, non-reused environments; and treat opting out of related protections, like actions/checkout's fork-checkout refusal, as a deliberate decision rather than a default. The docs also flag caching as a separate trap: a pull_request_target run can only read caches saved from the default branch, so caches should still be written from trusted triggers like push, not from the fork-triggered run itself.

Where this fits in GitHub's wider Actions hardening push

The December 2 default isn't an isolated change — it's the latest piece of a run of GitHub Actions security hardening aimed at exactly this attack class:

• actions/checkout v7 (GA June 18, 2026) refuses, by default, to check out a fork pull request's head or merge ref inside a pull_request_target workflow, or inside a workflow_run workflow triggered by a pull_request* event. Inputs like ref: ${{ github.event.pull_request.head.sha }} now fail outright unless a workflow opts out explicitly with the allow-unsafe-pr-checkout input. The backport of that refusal to older major versions pinned via a floating tag (such as @v4) was enforced starting July 20, 2026.
• Workflow execution protections reached general availability on September 17, 2026, after a public preview. This is the underlying engine behind Actions event policies — actor rules, event rules, workflow file targeting, Policy insights, and a REST API for managing rules at the enterprise, organization, or repository level. The December 2 default pull_request_target block is built directly on top of this system.

Read together, the sequence is: give actions/checkout safer defaults first, give admins a general-purpose policy engine for controlling who and what can trigger workflows second, then use that engine to switch on a sane default — blocking the single riskiest trigger — for the repositories most exposed to it. It's worth remembering that pull_request_target is only risky because of what a CI pipeline does with it; teams rethinking how deploys and pipeline triggers work at a more fundamental level may want to look at how GitOps structures git-driven deployment as a point of comparison.

What maintainers and org admins should do before December 2

1. Check Policy insights now for every public repository or organization you administer, to see which workflows currently use pull_request_target and would be blocked.
2. Decide, workflow by workflow, whether each one actually needs pull_request_target — many labeling/triage bots can be rewritten around pull_request plus a separate, more limited step that needs elevated access.
3. For anything you decide to keep, configure an Actions event policy scoped with workflow file targeting, add pull_request_target to its allowed events, test it in Evaluate mode, and confirm via Policy insights before setting it Active.
4. Audit what those workflows actually do with fork input — make sure none of them build, run, or execute fork-provided code, and that any actions/checkout step hasn't quietly used allow-unsafe-pr-checkout without a documented reason.
5. Treat the November 9 and November 16 brownouts as free dry runs — watch what breaks during those two-hour windows rather than finding out for the first time on December 2.

What's next

For most public repositories, the honest answer is to do nothing and let the default block take effect — if a workflow isn't knowingly using pull_request_target against fork PRs today, there's nothing to configure. For the smaller set of projects running real fork-triage automation under that trigger, the window between now and December 2, with two brownout rehearsals along the way, is the time to scope an explicit Actions event policy rather than discovering the block in production. Expect GitHub to keep extending the same event-policy framework — the same one driving this default — to other secret-bearing triggers as its Actions hardening work continues.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage