GitHub postpones the cut-off for pull_request_target to December and schedules two brownouts

Serguey Asael Shinder03 November 2026, 08:151 min read

GitHub has set a new date for blocking the pull_request_target event by default in public repositories. From 2 December 2026, GitHub Actions will block those events unless an Actions event policy explicitly allows them. Enforcement had previously been scheduled for 2 November. Private and internal repositories are not affected, and the change covers GitHub Free, Team and Enterprise Cloud but not Enterprise Server.

The rule is part of workflow execution protections and currently runs in evaluate mode, which shows which runs it would block. Before enforcement becomes permanent, GitHub will switch it on during two brownouts, on 9 and 16 November, each from 16:00 to 18:00 UTC. In those windows, blocked pull_request_target runs in affected public repositories will fail with an error annotation and the workflows will not execute; afterwards the rule returns to evaluate mode and runs proceed with warnings.

GitHub explains the reason: pull_request_target runs in the context of the base repository and can read its secrets, so a workflow that executes untrusted code from a fork can hand that code the pipeline. Maintainers can keep the default block, or explicitly allow the trigger in an event policy and narrow it to specific workflow files.

What it means

Any public repository whose workflows use pull_request_target should check the Insights view before 9 November. The brownouts are the cheap moment to find out: a failed run on a Monday afternoon is better than a broken release pipeline in December, and the fix is either a policy entry or a workflow that no longer needs the trigger.