GitHub Will Block pull_request_target by Default in Public Repositories From December 2, With Brownouts on November 9 and 16

On November 2, 2026, GitHub published a changelog entry saying GitHub Actions will block the pull_request_target event by default in all public repositories, unless an applicable Actions event policy explicitly allows it. The date is the important detail. The entry says enforcement was previously scheduled for November 2, 2026, and the new date for permanent enforcement is December 2, 2026. The entry is labeled as a retirement, and it sets a short window for owners of public repositories to find the workflows that will stop running.

The reason is security. The pull_request_target event runs in the context of the base repository and can reach its secrets. If a workflow that uses it executes untrusted code from a fork, that code could compromise the pipeline or steal secrets. GitHub says the default rule reduces this risk and still lets owners allow, on purpose, the workflows that depend on the trigger. The rule was introduced through workflow execution protections and initially runs in evaluate mode, so owners can see which workflow runs it would block before enforcement begins.

Scope matters, and the entry states it narrowly. The change applies to public repositories on GitHub Free, GitHub Team and GitHub Enterprise Cloud. It does not apply to GitHub Enterprise Server. Private and internal repositories are not affected. An organization with a mix of repository types should therefore list its public repositories first, since only those carry the risk of a blocked run.

Before permanent enforcement, GitHub will enforce the default protection during two scheduled brownouts. They run on November 9, 2026 and November 16, 2026, each from 16:00 to 18:00 UTC. In those windows, pull_request_target workflow attempts that the default rule blocks in affected public repositories create failed runs with an error annotation, and the workflows do not execute. After each window the rule returns to evaluate mode, and workflows run again with warnings. A brownout is therefore a real outage for those workflows, not a rehearsal on paper.

The entry gives two choices. Before the first brownout, use Insights to see which workflow runs the rule would block. Then either keep the default rule so the trigger stays blocked, or explicitly allow pull_request_target in an applicable Actions event policy if your workflows depend on it, using workflow file targeting to allow specific workflows. Allowing the event for a whole repository is a wider decision than allowing one file, and the entry points to documentation on how to control workflow execution.

That documentation adds details that the entry does not repeat. Workflow execution protections can restrict who may trigger workflows, restrict which events may run, and require a lockfile. Event rules cover events such as push, pull_request, pull_request_target and workflow_dispatch. Actor rules mean that an identity tied to a GitHub feature, for example dependabot[bot], must be added as an allowed actor when it needs to run workflows. The documentation says policies can be set at repository, organization and enterprise levels and recommends several clearly defined policies instead of one large one. It also shows a conflict to check. The page says that if you select the Evaluate enforcement status for a policy, you can monitor in policy insights when users would hit a restriction, and it marks Evaluate as GitHub Enterprise Cloud only. The changelog says the default rule starts in evaluate mode for public repositories on Free, Team and Enterprise Cloud. The pages do not explain whether Free and Team owners get the same Insights view, so verify that in your own settings before relying on it.

A practical plan is short. Find every workflow in public repositories that uses pull_request_target. For each one, decide whether it truly needs base-repository secrets or write permissions, or whether pull_request is enough. If it must stay, review what code it checks out from the fork, since that is the dangerous pattern the rule targets. Then add an explicit allow for that file only, record the owner and the reason, and test it during the November 9 window. Treat December 2 as the date after which a missing allow rule means a workflow that simply does not run.