Starting December 2, 2026, GitHub Actions will block the pull_request_target event by default in all public repositories, unless an applicable Actions event policy explicitly allows that trigger. This is CONFIRMED: it appears in GitHub's official changelog, published on November 2, 2026.
Enforcement had previously been scheduled for November 2 and was moved to December 2. Until then, the default rule runs in evaluate mode: workflows keep running, but GitHub shows which runs would be blocked, so maintainers can adjust their policies before the permanent block.
Before permanent enforcement, GitHub will temporarily enforce the rule during two brownout windows, on November 9 and November 16, 2026, from 16:00 to 18:00 UTC. During those windows, blocked attempts become failed runs with an error annotation and do not execute; after each window, the rule returns to evaluate mode, with warnings.
The risk behind the change is well known: pull_request_target runs in the context of the base repository and can access its secrets. If a workflow executes untrusted code from a fork, that code could compromise the pipeline or steal secrets — the attack class known as Pwn Request. GitHub therefore recommends checking the Insights report, which shows which runs would be blocked, before the first brownout on November 9.
What maintainers should do
There are two options, according to GitHub: keep the default rule, leaving the trigger blocked, or explicitly allow pull_request_target in an applicable event policy, preferably targeting only the workflow files that truly depend on it. This is not an absolute ban: repositories with an explicit policy can keep using the trigger.
The rule does not affect private and internal repositories, and it applies to public repositories on GitHub Free, GitHub Team and GitHub Enterprise Cloud — not GitHub Enterprise Server. Automatic enforcement on December 2 applies to affected repositories that were using the default pull_request_target policy before the general availability of workflow execution protections.
In practice, the message for maintainers of fork pull-request automation — such as labelers, triage and authenticated checks — is simple: audit now, while the rule is in evaluate mode, and allow only what is necessary. Waiting until December 2 risks silent failures in automations that seem to work today.
Image credit: GitHub, via the official GitHub icon.
Sources: GitHub Changelog — pull_request_target blocked by default December 2; GitHub Docs — Securely using pull_request_target; GitHub Changelog — Workflow execution protections generally available
Transparency: this article was produced with the assistance of artificial intelligence, based on cross-checking public posts on X and sources on the internet. Consult the original sources to confirm the details before sharing.
Muse
