GitHub will block pull_request_target by default on December 2

The headline: from December 2, pull_request_target is blocked by default in public repositories

GitHub announced in its November 2, 2026 Changelog that starting December 2, 2026, GitHub Actions will block pull_request_target events by default in all public repositories, unless an applicable Actions event policy explicitly allows them. Enforcement was originally scheduled for November 2 and has been pushed back by a month, which gives maintainers one final window to fix their workflows. Until then, the default rule runs in evaluate mode: it shows you which runs it would block, but it does not actually stop anything.

The date matters because pull_request_target is not an obscure trigger. It is the standard way many open source projects handle contributions from forks: labeling a pull request, posting a comment, running a preview deployment that needs secrets, or writing test results back to the PR. Once the default rule takes effect, those workflows will simply fail, with no further warning, unless you have done one of two things in advance: accept the default block, or explicitly allow the trigger in policy.

First, the scope, so nobody panics unnecessarily. The change applies only to public repositories on GitHub Free, GitHub Team, and GitHub Enterprise Cloud. Private repositories, internal repositories, and GitHub Enterprise Server are not affected. If every repository you maintain is private, you can stop here. If you maintain even one public repository, even a small utility, it is worth ten minutes of checking.

Why this trigger, specifically: it runs with the repository's secrets

To understand the rule, you need to understand what makes pull_request_target different. A normal pull_request event runs in the context of the fork's code and cannot access the target repository's secrets. A pull_request_target event runs in the context of the base repository and can access its secrets. That design exists for a good reason: some jobs genuinely need to act as the repository, for example commenting from a bot account, calling an external service that requires authentication, or deploying a preview environment.

But that same capability is the risk. If a workflow executes untrusted code from a fork, that code could compromise the pipeline or steal secrets. The attack paths have been discussed for years: a line changed in a script the workflow runs, a configuration file the workflow parses, a tool bundled in the PR that the workflow invokes. GitHub's move does not remove the trigger. It flips the default from "allowed unless stopped" to "blocked unless allowed," and hands the burden of proof back to the maintainer: if you genuinely need it, say so explicitly.

One misconception is worth clearing up early: the default block is not a ban. Think of it as a door that is now locked by default, with the key still in your hand. Repositories that already have an applicable event policy allowing the trigger will not be rewritten by the default rule. Only repositories with no such policy will hit the door on December 2.

Two brownout windows: November 9 and November 16. Do not wait until December to discover a problem

Before permanent enforcement on December 2, GitHub will temporarily enforce the default protection during two scheduled brownouts: November 9, 2026, from 16:00 to 18:00 UTC, and November 16, 2026, at the same hours. During each window, a blocked pull_request_target attempt will create a failed run with an error annotation, and the workflow will not execute. After each window, the rule returns to evaluate mode, and workflows run again with warnings.

Those windows are a free rehearsal, and the right way to use them is deliberate. Before November 9, check Insights to list the runs the rule would block. During the November 9 window, watch what actually fails and confirm the list was complete. Use the November 16 window to verify your fixes. If your project happens to receive no external pull requests during a window, do not read that as a clean bill of health: no trigger is not the same as no risk, and the warnings in evaluate mode are the more reliable evidence.

For readers in China, those windows fall at 00:00 to 02:00 Beijing time on November 10 and November 17, when most people are asleep. That is exactly why you should not plan to "watch the window." Do the checking in advance, and let the brownout failures serve as verification, not as your first discovery of the problem.

Check in three steps: look at Insights, then sort into three buckets

GitHub's official guidance is straightforward: before the first brownout on November 9, use Insights to see which workflow runs the rule would block, then choose one of two options, keep the default block or explicitly allow the trigger in an applicable Actions event policy. Before acting, though, sort the affected workflows into three buckets, because each bucket has a different correct fix.

The first bucket is workflows that should never have used pull_request_target at all: they run tests, run linting, or build artifacts, and they do not need repository secrets. The usual cause is copy-paste, a trigger copied from someone else's workflow template and carried forward for years. The fix is to switch back to pull_request and drop the secret permissions that are no longer needed. The workflow ends up both safer and closer to least privilege.

The second bucket is workflows that genuinely need the repository's identity but can be split: run the untrusted code under pull_request first, then let a separate workflow that only handles trusted artifacts do the commenting or deployment. Splitting "execute external code" from "use secrets" into two workflows is the cleanest fix here: the first cannot reach secrets, the second never executes external code, and the attack chain is broken. It takes a little more work, but it is the only structure that preserves both the feature and the security.

The third bucket is workflows that genuinely need the trigger and cannot be split: they must post an authenticated comment on a fork's PR, or deploy a preview environment that depends on secrets. For these, the correct action is to explicitly allow the trigger in policy, and to narrow the allowance as far as possible. GitHub supports workflow file targeting, so you can allow one specific workflow file rather than the trigger in general. While you are there, audit the permissions: does this workflow really need every secret and every token permission it currently holds? Anything that can be tightened should be tightened in the same pass.

The most dangerous response: a blanket allow to make the failures stop

The biggest risk in this change is not the rule itself but the reflex it may trigger: a workflow starts failing after December 2, and a maintainer, under pressure to restore it, allows pull_request_target wholesale, possibly at the organization level. That removes the default protection by hand, and afterward nothing reminds you that a door used to be there.

The safer order is the reverse. Accept the default block first and let the failures surface. Judge each workflow against the three buckets. Allow only the third bucket, narrowly, and write down why: what this workflow needs the trigger for, which secrets it touches, and what its trigger conditions are. Three months later, when you or your successor looks at that policy, that note is the only thing that can answer whether the allowance is still justified.

One more detail is easy to miss: the default rule does not replace an existing applicable event policy. If your organization or enterprise already has an event policy configured, the default rule will not rewrite it. Check both layers when auditing: whether the repository has affected workflows, and whether an existing organization-level policy already allows the trigger. Checking only one layer can easily produce a false "not affected" conclusion.

The real exposure is small projects, not large ones

Large projects usually have someone watching CI, and they will most likely have dealt with this in November. The projects most likely to be caught out are small ones and personal public repositories: workflows set up years ago, triggers copied from templates, nobody regularly reading Insights, few outside contributors. After December 2, the first pull request from a fork fails, and the maintainer discovers the problem only when a contributor is already confused and possibly gone.

For those projects, my advice is simple: do not wait for an external pull request. Open Insights now and check the evaluate-mode results, even if the repository has not seen an outside PR in six months. Confirming that the list is empty is worth doing, because "confirmed empty" and "assumed empty" are two very different states. If the list is not empty, work through the three buckets; the whole exercise usually takes under half an hour, which is far cheaper than fixing it in front of a contributor in December.

There is also a broader pattern worth noticing. This change belongs to the same direction as GitHub's other recent security tightenings: defaults are moving from "convenience first" to "security first," with the choice handed explicitly back to maintainers. Once you see that pattern, you can predict what comes next: more default tightenings, and more value in the habit of checking evaluate-mode warnings regularly, rather than firefighting each time.

What pull_request and pull_request_target actually differ on

Many people never had reason to distinguish these two triggers, so here is the difference in plain terms. A pull_request event runs in the context of the merge commit, that is, the code as proposed from the fork. It can see the PR's code, but it cannot access the base repository's secrets or write permissions, which is precisely why it is the safe choice for executing untrusted code. A pull_request_target event runs in the context of the base repository's default branch: its workflow file comes from the base repository, not the fork, and it runs with the repository's secrets and configured permissions, which is precisely why it must be treated as a privileged flow.

That distinction yields a practical test: any step that checks out PR code and executes its contents, runs its scripts, parses its configuration, or invokes its bundled tools, does not belong in a pull_request_target workflow, unless it has first passed strict isolation and review. Conversely, steps that only need PR metadata, such as the title, number, author, or labels, without executing PR code, for example posting a formatted comment, applying a label, or triggering a downstream deployment, are legitimate uses of pull_request_target. Put that test in your team's workflow review checklist, and the chance of picking the wrong trigger for a new workflow drops sharply.

One nuance deserves its own mention: because the workflow file for pull_request_target comes from the base repository, an outside contributor cannot change the privileged flow by editing the workflow file in their PR. That is the safer side of the design. But the moment the workflow executes PR code, that protection is gone. So an audit should never look only at the workflow file; it must look at what the workflow checks out and executes. Judging a workflow safe merely because "its file lives in the base repository" is an incomplete review.

For organization admins: do not allow it away at the organization level

If you administer an organization or enterprise account, the most tempting action is a single organization-wide allowance that restores everything at once. It would eliminate every failure immediately, but it would also dismantle the default protection wholesale, and no repository maintainer would receive any further reminder. The risk would be hidden, not resolved.

A better approach is layered: keep the default block at the organization level, and grant narrow, reviewed allowances only to workflows that genuinely need the trigger and have had their permissions tightened. Make the Insights check a routine, for example once a month, or whenever a new public repository is created. The organization-level policy should read "secure by default, exceptions transparent," not "allowed by default, exceptions invisible." This change hands you a free, comprehensive audit of the privileged workflows accumulated over the past few years. Use it, and your organization will be measurably safer after December 2 than it was before.

A checklist you can run today

To close, here is the whole job as a checklist. First, before November 9, open Insights and export the list of workflows the default rule would block. Second, sort that list into the three buckets: switch what can go back to pull_request, split what can be split, and narrowly allow only what cannot be replaced. Third, tighten the permissions of every allowed workflow: the smallest set of secrets, the smallest token permissions, and environment approvals where they make sense. Fourth, recheck the failure records after each brownout window, on November 9 and November 16, to confirm nothing was missed. Fifth, write the reasons for each allowance into the policy notes or repository documentation, so future audits have something to work from.

December 2 will not be postponed a second time; it is itself the postponement of November 2. Half an hour of checking now is the highest-return action in this whole change.