GitHub is blocking pull_request_target by default on December 2: will your workflows break?

By Cassie Crossley · Published November 5, 2026 · Sources checked November 5, 2026 (PT)

If a public repository uses pull_request_target and no Actions event policy allows it, those runs fail during the November 9 and November 16 brownouts, and they stop for good on December 2, 2026. Below: what changes, how to find the workflows, when to allow the trigger, and why GitHub is closing this door.

What changes and when

Starting December 2, 2026, GitHub Actions blocks pull_request_target events by default in all public repositories unless an applicable Actions event policy explicitly allows them. Enforcement was previously scheduled for November 2, 2026 (GitHub Changelog, Nov 2, 2026).

GitHub introduced the default rule through workflow execution protections. It first runs in evaluate mode, so you can see which runs it would block before enforcement begins. Private and internal repositories are not affected. The change applies to public repositories on GitHub Free, GitHub Team, and GitHub Enterprise Cloud, not GitHub Enterprise Server.

Will my workflows break?

Use this checklist. You are affected if all three are true:

• The repository is public (on Free, Team, or Enterprise Cloud).
• A workflow uses on: pull_request_target (or includes that event).
• No applicable Actions event policy explicitly allows pull_request_target.

The default policy does not replace an event policy you already configured (GitHub Docs: securely using pull_request_target). If you already allow the event in a policy that applies to the repo, those workflows keep running.

How to find affected workflows

1. Use Insights. While the rule is in evaluate mode, GitHub's policy Insights show which workflow runs the default rule would block (Changelog; also described when workflow execution protections became generally available).
2. Search your repos. Look for pull_request_target under .github/workflows/. On GitHub code search you can try pull_request_target path:.github/workflows scoped to your org or user.
3. Watch the brownouts. On Nov 9 and Nov 16, failed runs with an error annotation mark workflows the default rule is blocking. After each window those runs go back to warnings until Dec 2.

Allow or rewrite?

GitHub's guidance, boiled down to a decision list:

• No secrets needed. Switch to pull_request. It covers the same pull-request events and, for forks, runs with a read-only token and without other secrets (securely using pull_request_target).
• Needs secrets, but also runs pull request code. Split the work: handle untrusted code in an unprivileged pull_request job, and keep secret access in a separate privileged job that treats results as data. GitHub Security Lab's Preventing pwn requests walks through that pattern.
• Truly needed and safe (for example labeling or commenting, and the workflow never executes pull request code). Explicitly allow pull_request_target in an applicable Actions event policy, and use workflow file targeting so only those files are allowed (Changelog; control workflow execution).
• You do not need it. Keep the default block.

GitHub's warning: only allow pull_request_target when it is necessary. Such workflows should not check out, build, or run untrusted pull request code with access to repository secrets or a privileged GITHUB_TOKEN. GitHub also documents an actions/checkout input, allow-unsafe-pr-checkout: true, as an explicit opt-out after you confirm safe use. Treat that as documentation only; do not treat it as a recommendation.

Why GitHub is doing this: the "pwn request"

pull_request_target runs in the context of the base repository and can access its secrets. If the workflow executes untrusted code from a fork, that code could compromise the pipeline or steal secrets (Changelog).

By default the workflow file, and any actions/checkout call that does not set a ref, come from the base repository's default branch. The flaw is overriding that to check out the pull request head and then running it. Execution is not limited to an obvious build step: npm install, build and test commands, configuration files, and dependencies can all run attacker-controlled code (GitHub Docs).

That pattern is called a "pwn request." When workflow execution protections became generally available, GitHub wrote that vulnerabilities in pull_request_target workflows, such as Pwn Requests, are "one of the most commonly exploited vulnerabilities in action workflows" (Changelog, Sep 17, 2026).

Why this matters for releases: a stolen secret or a write-scoped GITHUB_TOKEN can push tags or publish release assets. That is the same class of access that shows up after GhostAction and stolen GitHub tokens, in the LiteLLM clean-tag, poisoned-release case, and when compromised Actions come back with tags still on malware.

After you fix triggers, check what you release

Closing the trigger is one layer. Also pin third-party Actions to full commit SHAs, protect release tags, and verify what you ship. Look up the tools you install in the ReleaseLock directory, and add the free ReleaseLock Gate so CI fails when a workflow step is not pinned to a full commit SHA.

Quick answers

Sources

• GitHub Changelog, Nov 2, 2026, pull_request_target blocked by default December 2
• GitHub Docs, Control workflow execution
• GitHub Docs, Securely using pull_request_target
• GitHub Docs, Workflow execution protections
• GitHub Changelog, Sep 17, 2026, Workflow execution protections in GitHub Actions generally available
• GitHub Security Lab, Preventing pwn requests