GitHub Actions will block pull_request_target by default on December 2

If a public repository uses pull_request_target, put December 2 on the maintenance calendar. GitHub plans to enforce a default policy that blocks this event in affected public repositories unless an applicable Actions event policy allows it. The announcement is new; the policy is already in evaluate mode, so affected workflows still run for now. GitHub’s November 2 announcement sets the enforcement date.

This is a targeted default, not a blanket change to every repository. GitHub says it does not apply to private or internal repositories and does not replace an applicable event policy you have already configured. The Actions security guidance says to use policy insights during evaluate mode to find workflows that would be blocked.

Review the workflow before changing the trigger

Start with the policy insights for the repository, organization, or enterprise that governs the workflow. Then open each affected workflow and inspect its on: trigger and steps. Search for pull_request_target, but don’t stop at the event name. Check whether the workflow checks out a fork’s pull-request code, installs its dependencies, builds it, or runs its tests.

The event runs trusted workflow code from the base repository with access to the base repository’s token and secrets. That can be useful for tasks such as labeling a pull request or posting an authenticated status. The danger is combining that elevated access with code supplied by an untrusted fork. A build or test can execute commands from that code. GitHub warns against checking out and running untrusted pull-request code in a privileged pull_request_target workflow.

For each affected workflow, make one of three decisions:

• It doesn’t need elevated access: consider moving it to pull_request, which GitHub recommends when the extra secret access isn’t needed. Check the event’s token and fork protections before relying on the replacement.
• It needs the event but doesn’t need to run fork code: keep the trigger only if the workflow’s purpose requires it, and review its token permissions, secrets, and steps.
• It truly needs the event and has a justified safe design: configure an applicable Actions event policy that explicitly allows it. An allow rule does not make unsafe checkout or execution safe.

Don’t add an allow rule simply to make a failing workflow green. The point of the policy is to make the privileged trigger an explicit choice. If the workflow’s purpose or code path is unclear, ask its owner to explain what it needs before changing the policy.

There’s no need to change a repository that isn’t affected by the default or a workflow that doesn’t use this event. For affected workflows, review the policy insights, decide whether the trigger is necessary, and make that decision before December 2. Then verify the workflow under the policy that will govern it.

Sources: GitHub’s enforcement announcement and GitHub’s security guidance for pull_request_target.