GitHub will block pull_request_target in every public repo on December 2. The first test run is Monday.
A two-hour test block hits public repositories on November 9 and again on November 16, ahead of permanent enforcement. Here is who is affected and what GitHub says to do.
GitHub is going to break some people’s CI on purpose, and it has told them the exact hours. On November 9, from 16:00 to 18:00 UTC, public repositories that rely on the pull_request_target trigger will see those workflow runs fail instead of start. That is 8 to 10 AM on the US West Coast, by my conversion.
It’s a rehearsal. Permanent enforcement begins on December 2, 2026, according to GitHub’s changelog entry from November 2.
What is GitHub actually changing?
Starting December 2, GitHub Actions blocks pull_request_target events by default in all public repositories, unless an Actions event policy explicitly allows them. Private and internal repositories aren’t touched. The change covers GitHub Free, Team and Enterprise Cloud, and not Enterprise Server.
The block comes from the “workflow execution protections” GitHub made generally available on September 17. That release added a default rule that disables the trigger for public repos with no applicable policy of their own. It has been running in what GitHub calls evaluate mode: workflows keep running, and a policy insights page shows which runs would have been stopped.
The date has also moved. The changelog says enforcement “was previously scheduled for November 2, 2026,” and the September announcement carries an editor’s note dated October 21 changing it to December 2.
Why this trigger, of all of them?
pull_request_target runs with the base repository’s token and secrets. That is useful for labeling or triaging pull requests from forks. It becomes dangerous when a workflow checks out the fork’s code and then runs it, because the attacker’s build script now executes with your secrets.
GitHub’s docs call this a “pwn request” and say it has been “the root cause of multiple supply-chain compromises.” The docs include an example of the insecure pattern: a checkout of the pull request’s head commit, followed by make test. The attacker only needs a fork whose Makefile contains something nasty.
Which dates matter?
| Date | What happens |
|---|---|
| Now, outside test windows | Evaluate mode. Runs continue, Insights shows what would be blocked. |
| November 9, 16:00 to 18:00 UTC | Test block. Blocked runs fail with an error annotation and don’t execute. |
| November 16, 16:00 to 18:00 UTC | Second test block, same behavior. |
| December 2 | Permanent enforcement for affected public repositories. |
After each test window, the rule goes back to evaluate mode. GitHub says the point is to let you find affected workflows and fix your policies before the block becomes permanent.
What should a maintainer do before Monday?
GitHub gives two options. Leave the default rule in place and accept that the trigger is blocked, or write an Actions event policy that explicitly allows pull_request_target. A policy can target specific workflow files, so one labeling bot can be allowed without opening the whole repository.
The docs add a third route for a lot of projects: if a workflow doesn’t need the elevated token, switch it to the plain pull_request event. And if you do keep pull_request_target, GitHub warns against checking out, building or running untrusted pull request code in it. The docs also describe an allow-unsafe-pr-checkout: true input for actions/checkout, which exists to opt out of its checkout protection, and which they say to use only when the checked-out code is never executed.
Start with Insights. It lists the runs the rule would have blocked, which is a better guide than grepping your workflow files.
My read
My read: this is a sensible change that will still annoy people. I’d guess plenty of small open-source projects added pull_request_target to get a labeler or comment bot working and never looked at it again. Those are the ones likely to find out on a Monday morning when a bot stops answering.
It also fits a pattern we’ve been covering. When LiteLLM’s 1.107.0 release was poisoned in October, the way in was stolen developer credentials and a changed release workflow, not this trigger. Different hole, same lesson: the build pipeline is part of what you ship, and AI tooling projects that publish packages are attractive targets for it.
What I can’t tell from GitHub’s notices is how many repositories will actually fail on Monday. It hasn’t published a count, so treat any number you see elsewhere as a guess.
Note on sources: everything above about dates, scope and options comes from GitHub’s two changelog entries and its docs page. The conversion to Pacific time and the LiteLLM comparison are mine, and the repository count is unverified.