GitHub is moving public repositories to a safer default for GitHub Actions: starting December 2, 2026, pull_request_target events will be blocked unless an applicable Actions event policy explicitly allows them.
The change matters because pull_request_target runs in the base repository context. That gives the workflow access to the base repository's token and secrets, which is useful for trusted automation but dangerous when the job checks out or executes code supplied by an untrusted fork.
What changes on December 2
The default event policy applies to public repositories that do not already have an applicable Actions event policy. It does not affect private or internal repositories, and it does not replace an event policy you have already configured.
Before enforcement, the default rule runs in evaluate mode. Workflows continue to run, while policy insights show which runs would be blocked after enforcement. Use that window to find the workflows that need a decision.
Two brownouts come first
GitHub will temporarily enforce the default protection during two scheduled brownouts before permanent enforcement:
November 9, 2026, 16:00 to 18:00 UTC.
November 16, 2026, 16:00 to 18:00 UTC.
During a brownout, an affected workflow creates a failed run with an error annotation and does not execute. After the window, the default rule returns to evaluate mode until December 2.
First decide whether you need the event
For many workflows, the safest fix is to use pull_request instead. It is designed for fork pull requests with a read-only GITHUB_TOKEN, no access to other secrets by default, and fork approval protections. It runs the workflow from the pull request merge branch rather than the trusted base branch.
Keep pull_request_target only when the workflow genuinely needs trusted base-repository context, such as labeling or posting an authenticated status that requires credentials not available to a normal pull_request workflow. Even then, treat the job as privileged automation, not as a general-purpose test runner.
Use policy insights before the first brownout
Open Insights for workflow execution protections at the organization or repository level.
Filter for public repositories and pull_request_target runs that the default rule would block.
For each workflow, replace the event when secrets and privileged access are not required.
For the small set that must keep the event, create an applicable Actions event policy and target only the required workflow files.
Do not allow pull_request_target globally just to make a red dashboard disappear. A narrow allowlist documents which workflow owns the exception and limits the blast radius if someone later changes that workflow.
Hardening workflows that keep pull_request_target
Never check out, build, or execute code from the untrusted pull request while secrets or a privileged token are available.
Set the minimum GITHUB_TOKEN permissions and expose only the secrets the workflow needs.
Keep self-hosted runners isolated and ephemeral. Do not reuse a privileged runner workspace across untrusted jobs.
Treat checkout, package installation, build scripts, and configuration files as possible code execution, not as harmless file reads.
GitHub also restricts cache writes for pull_request_target workflows by default to reduce cache poisoning. A workflow can opt into write-capable cache behavior, but doing so brings back the risk that the protection is meant to contain.
Do not confuse checkout safety with event safety
The actions/checkout allow-unsafe-pr-checkout input can permit checking out a fork ref in a pull_request_target workflow. That flag does not make the code safe. Use it only after proving the checked-out files are never executed, and remember that git fetch, gh pr checkout, downloaded artifacts, and unrelated third-party code can also introduce untrusted content.
The practical migration plan
Run the audit before November 9, watch both brownouts, and make the final policy decision before December 2. Most workflows should move to pull_request. The exceptions should be few, explicitly targeted, least privileged, and reviewed like production security controls.
The default block is a useful forcing function: it turns a subtle trust-boundary decision into a visible policy choice. If a workflow needs privileged access, make that need obvious in the policy and in the workflow design.
Sources: GitHub Changelog: pull_request_target blocked by default; Securely using pull_request_target; About Actions policies.