GitHub pull_request_target Block: December 2026 Checklist

GitHub announced on November 2, 2026 that Actions will block pull_request_target events by default in public repositories beginning December 2, unless an applicable event policy explicitly permits them. Two temporary enforcement windows are scheduled for November 9 and November 16 from 16:00 to 18:00 UTC. The rule currently runs in evaluate mode, giving maintainers a chance to identify affected workflows before the permanent change.

The trigger is powerful because it runs in the base repository context

A pull_request_target workflow can access the base repository’s secrets and permissions. That can be useful for labelling or commenting on contributions from forks, but it becomes dangerous when the workflow checks out or executes untrusted fork code. An attacker may be able to steal a token or alter the pipeline.

The new default does not prove that every workflow using the trigger is exploitable. It changes the safe starting position: public repositories must intentionally allow the event through an Actions policy when they still need it. Private and internal repositories are not affected by this announced default.

The brownouts are live tests, not the final enforcement date

During the two November windows, attempts blocked by the default rule will fail with an error annotation. After each window, the rule returns to evaluate mode and workflows can run with warnings until December 2. Maintainers should not treat a successful run outside a brownout as evidence that the migration is complete.

GitHub directs organization owners to Insights to see which runs the rule would block. Record the repository, workflow file, job and reason for every candidate. A workflow that has not run recently may not appear in observed traffic, so also search the repository for the event name.

Prefer removing unnecessary privilege before adding an exception

If a workflow only needs to test code from a pull request, consider whether the ordinary pull_request event and reduced permissions fit the job. If pull_request_target remains necessary, avoid executing code from the fork, minimize token permissions, pin external actions and target an exception to the specific reviewed workflow rather than allowing the event broadly.

An explicit allow rule is a policy decision, not a security review by itself. Test the workflow with an untrusted fork, confirm which secrets and tokens are present, and document the reason the privileged context is required. Recheck the design when a new checkout, script or action is added.

Cloud-hosted public repositories are the announced scope

GitHub says the change applies to public repositories on GitHub Free, Team and Enterprise Cloud. It does not apply to GitHub Enterprise Server under this announcement. Canadian maintainers using public repositories should convert the UTC brownout times locally and make a maintainer available to inspect failures.

The practical success measure is not the number of exceptions created. It is the number of affected workflows either redesigned to avoid privileged execution or given a narrow, documented exception after adversarial testing. Review warnings now, then verify again during a brownout and after December 2.

Sources and editorial method

We use the linked original statements and reports to distinguish documented facts from our analysis. Company announcements describe their authors’ plans and claims; they are not independent verification of future outcomes. This article is dated and will be revised if material evidence changes. Read our editorial standards and corrections process.

GitHub Changelog: pull_request_target blocked by default December 2 ↗ — Official November 2 announcement; affected repositories, security rationale, brownout schedule and preparation steps.