GitHub will block pull_request_target by default—check public repositories now

GitHub is changing the default trust boundary for a powerful Actions trigger. From 2 December 2026, public repositories will have pull_request_target blocked unless an applicable Actions event policy explicitly permits it.

The GitHub announcement says the rule is already running in evaluate mode. Teams therefore have a short period to see which runs would be affected before GitHub starts enforcing the default. Two brownouts will temporarily enforce it on 9 and 16 November, from 16:00 to 18:00 UTC.

This is more than a compatibility change. pull_request_target runs in the context of the base repository and can reach its secrets. If that workflow fetches and executes code controlled by an untrusted fork, a pull request can become a route to credentials, repository writes or a compromised release pipeline.

Why this event is different

The ordinary pull_request event is designed around code proposed by a contributor. GitHub deliberately limits the token and secret access available to workflows triggered from forks. That makes many contribution checks safer, although the job still needs to treat the proposed code as untrusted.

pull_request_target exists for workflows that need the base repository’s trusted context—for example, applying labels, posting a comment or managing project metadata. Its workflow definition comes from the base branch, but that does not make everything it handles trusted. The danger appears when the job crosses the boundary and runs content from the contributor’s branch while still holding the base repository’s authority.

A risky pattern can look deceptively normal:

1. a public repository receives a pull request from a fork;
2. a pull_request_target workflow starts with a write-capable token or repository secret;
3. the job checks out the pull request head rather than the base branch;
4. a build script, package hook, test helper or changed action runs from that head;
5. attacker-controlled code reads the credential or uses the token.

The checkout line is not the only place to look. Installing dependencies from a contributor-controlled lockfile, importing a changed script, running a local action or evaluating pull-request fields in a shell can create the same trust reversal.

What GitHub is changing

GitHub’s default protection applies to public repositories on GitHub Free, GitHub Team and GitHub Enterprise Cloud. Private and internal repositories are not affected, and the announcement says the change does not apply to GitHub Enterprise Server.

The new rule uses GitHub’s workflow execution protections. The policy documentation explains that administrators can restrict both the actors who may trigger workflows and the events allowed to run them. Policies can be layered at repository, organisation and enterprise level and targeted to specific workflow paths.

The default rule is currently in evaluate mode. Policy insights show runs it would block without stopping them. During the brownouts on 9 and 16 November, affected attempts will fail with an error annotation. After each window, the rule returns to evaluation until permanent enforcement begins on 2 December.

If a workflow has a valid need for pull_request_target, administrators can explicitly allow it through an applicable Actions event policy. GitHub recommends targeting specific workflow files rather than creating a broad exception.

What to do before the first brownout

Start with inventory, then review authority. A search for the trigger is useful, but the security decision depends on what each workflow does after it starts.

1. Open Actions policy insights. At repository or organisation level, review the runs that the default protection says it would block. Export an owner, repository and workflow path for each result.
2. Search all public repositories. Find every workflow containing pull_request_target, including disabled and rarely used workflows that may not appear in recent insights.
3. Trace contributor-controlled input. Follow checkout references, downloaded artifacts, dependency files, local actions, scripts and pull-request metadata. Mark every place that could execute or interpolate data from the fork.
4. List the available authority. Record token permissions, secrets, cloud credentials, package publishing access, environment approvals and reachable self-hosted runners. Do not assume a secret is harmless because it is scoped to one system.
5. Remove execution where possible. Metadata-only jobs should use API calls against the pull request rather than checking out its code. Build and test untrusted code under pull_request with a read-only token and no secrets.
6. Split workflows when trust changes. If a later privileged job must act on results, pass narrowly defined data through an explicit review or trusted handoff. Do not treat an artifact produced by untrusted code as automatically safe to execute.
7. Allow only the workflow that remains necessary. Use workflow file targeting, document the business reason and nominate an owner. A blanket allow rule recreates the risk the new default is intended to reduce.

Run the reviewed workflows during the 9 November brownout if possible. A planned failed run is better evidence than discovering the dependency during a release or an urgent external contribution.

Safer designs for common jobs

Labels and comments. Keep the job on trusted base-branch code. Use the pull request number and GitHub API, grant only the permissions needed for the metadata change and do not check out the contributor’s branch.

Builds and tests. Trigger with pull_request. Use read-only permissions, avoid repository and cloud secrets, isolate the runner and assume build scripts can be hostile. For public contributions, do not expose a persistent self-hosted runner unless it is designed to be disposable and isolated.

Preview deployments. Treat a preview as deployment of untrusted code. Use an ephemeral environment, short-lived credentials, a separate account or project, no production data and a cleanup path. If approval is required, show reviewers the exact commit and destination.

Publishing and releases. Separate validation from publication. A trusted workflow can consume a specific reviewed commit or signed artifact after branch protection and required checks have succeeded. The contributor-triggered job should not hold the publishing credential.

What leaders should ask for

The useful evidence is a short exception register, not a statement that the organisation “fixed GitHub Actions.” For every allowed pull_request_target workflow, ask for:

• the workflow path and accountable owner;
• the action it must perform in the base-repository context;
• the fork-controlled inputs it reads;
• the token permissions and secrets it can access;
• the reason ordinary pull_request cannot do the job;
• the test showing that contributor code is not executed with privileged authority;
• an expiry or review date for the exception.

The immediate operational deadline is the 9 November brownout. The security objective is broader: untrusted contribution code and trusted automation credentials should never share an execution boundary without deliberate isolation and review.

If you need to review CI/CD trust boundaries before the enforcement date, our security consulting work can turn the workflow inventory into a prioritised remediation plan.