GitHub Sets December 2 Default Block for Public pull_request_target Workflows

A pull request from a fork can reach a workflow with more access than its author should have.

GitHub moved default enforcement for public pull_request_target workflows to December 2, 2026. Its November 2 notice replaces the earlier November 2 enforcement date and schedules two temporary enforcement windows before the permanent change.

The default protection targets a specific trigger

The pull_request_target event runs in the base repository’s context and can access its secrets. GitHub warns that executing untrusted code from a fork in that context can compromise a pipeline. The new default blocks these events unless an applicable Actions event policy explicitly permits them.

This applies to public repositories on GitHub Free, Team, and Enterprise Cloud. Private and internal repositories are excluded, as is GitHub Enterprise Server. It is not a blanket shutdown of all pull-request workflows.

November brownouts create an earlier test

Date	Enforcement window
November 9, 2026	16:00 to 18:00 UTC
November 16, 2026	16:00 to 18:00 UTC
December 2, 2026	Permanent default enforcement begins

During each brownout, the default rule blocks attempts, creating failed runs with an error annotation, and workflows will not execute. After the window, the rule returns to evaluation mode, allowing runs with warnings until enforcement begins.

Review an exception at the workflow level

GitHub recommends using Insights to identify the runs that the rule would block. A maintainer can retain the default protection or explicitly allow a dependent workflow through an applicable policy. Its workflow execution documentation explains the policy controls and how to target workflow files.

For repositories receiving changes from coding agents, the practical task is to inspect the workflow’s permissions and what code it executes. An automated contributor does not make a fork’s contents trusted. A narrow exception should follow a review of the specific workflow, not the need to make a red status disappear.

Before November 9, record which workflows rely on the trigger and who owns the policy decision. That gives the first brownout a defined purpose: confirm the expected block or the reviewed exception. Read more about coding-agent infrastructure in our Pando source-control report.