GitHub’s first brownout for pull_request_target triggered today — November 9, 16:00 to 18:00 UTC. If your public repositories use this workflow trigger, those jobs failed for two hours without a warning. A second brownout fires November 16. On December 2, the block becomes permanent. You have 23 days.
What pull_request_target Does — and Why It Is a Problem
pull_request_target was designed to let workflows comment on pull requests, apply labels, and assign reviewers — operations that need write access to the base repository. The catch: it runs with the base repo’s full GITHUB_TOKEN and secrets, even when triggered by a fork PR from a complete stranger.
That is the attack surface. If your workflow checks out the fork’s code inside a pull_request_target context, you are running attacker-controlled code with your own CI credentials. Security researchers call this a pwn-request attack. The Megalodon campaign exploited exactly this pattern to compromise over 5,500 repositories. GitHub has been chipping away at the problem — actions/checkout v7 blocked the most dangerous checkout patterns in June — but the trigger itself remained live by default on millions of public repos. December 2 ends that, as announced in GitHub’s changelog.
The Timeline
- November 9 (today), 16:00–18:00 UTC: Brownout 1 — blocked workflows fail with an error annotation
- November 16, 16:00–18:00 UTC: Brownout 2 — same window, second rehearsal
- December 2, 2026: Permanent enforcement — public repos without an explicit event policy block all
pull_request_targetruns
Scope: public repositories on GitHub Free, Team, and Enterprise Cloud. Private and internal repositories are not affected.
Audit Your Workflows Now
Start with a grep:
grep -rn "pull_request_target" .github/workflows/If that returns nothing, you are fine. If it returns matches, check each one. GitHub’s Insights tab also shows a “Policy evaluation” view — in evaluate mode it lists which runs would have been blocked, so you can confirm impact before December 2.
The most common offenders: welcome bots that greet first-time contributors, PR labelers (older versions of actions/labeler), auto-assign workflows, and Dependabot comment jobs. Many of these were wired up years ago using third-party Action templates and never reviewed since.
Three Fixes
1. Switch to pull_request
If your workflow only builds code, runs tests, or performs checks, it does not need pull_request_target. Switch to pull_request. That trigger runs in the fork’s context with a read-only token, which is exactly what you want for untrusted code.
on:
pull_request:
types: [opened, synchronize]Limitation: you cannot write back to the base repo from this trigger. If you need to post comments or labels on fork PRs, see option 2.
2. Split the Workflow
For workflows that must both run code and post results, use two workflows: a pull_request job that runs the untrusted code and uploads artifacts, and a workflow_run job that runs from the base branch with secrets and reads those artifacts. The workflow_run job must treat the artifacts as untrusted data — read and display, never execute.
3. Create an Event Policy Exception
If you genuinely cannot refactor before December 2, GitHub lets you explicitly allow pull_request_target via an Actions event policy. Go to Repository Settings → Actions → Policies, create a policy, and use workflow file targeting to scope the exception to the specific .yml file that needs it rather than enabling it repo-wide. This is a stopgap, not a solution.
The Bigger Picture
This is not an isolated move. GitHub has been tightening CI/CD defaults all year: Workflow Execution Protections went GA in September, Actions Lockfiles shipped shortly after, and Checkout v7 blocked dangerous fork checkouts in June. GitHub’s changelog states plainly: “Most workflows that use pull_request_target do not need it.” December 2 enforces that.
The brownout today is the signal. Run the grep, check Insights, and start the fix — the runway to December 2 is short.
