GitHub Is Putting a Gate in Front of pull_request_target

GitHub’s September 17 announcement says the default disables pull_request_target in public repositories without an applicable event policy. It starts in evaluate mode. Enforcement begins November 2, 2026, for affected repositories using the default policy before general availability. Private and internal repositories are excluded from this default.

The trigger runs in the base repository’s context. Executing code from an untrusted pull request in that context can expose secrets or repository write access. Blocking the event can prevent that execution, but blindly allowing it to keep a bot running can preserve the original vulnerability.

Find the workflows, then follow what they execute

From the root of a checked-out repository, this read-only command locates candidate workflow files:

git grep -n -e pull_request_target -- .github/workflows

This is a text search, not a YAML parser or a security scanner. It can match comments. It only examines tracked files in the checked-out revision, so inspect the default branch and any other relevant workflow revisions. A missing match says nothing about another repository or a local untracked file.

For each match, record the workflow path, its job permissions, secrets it can receive, and everything it executes. Follow referenced scripts and reusable workflows too. A small YAML file can delegate the dangerous operation elsewhere.

I would separate these two cases immediately:

• A workflow labels or comments on a pull request using trusted code from the base repository.
• A workflow checks out the contributor’s revision and runs a build, dependency installation, test script, or other contributor-controlled code with base-repository authority.

The second needs a design review before an exception. “It only runs tests” is not reassuring when the proposed change can replace the tests, build scripts, or dependency hooks. An execution policy and a safe workflow solve different parts of the problem.

Check the policy that actually applies

The generally available controls include actor and event rules, workflow-file targeting, Insights, and REST management. Evaluate mode records decisions before enforcement. GitHub links its policy documentation and API reference in the announcement.

Use the applicable policy and its Insights results to establish whether this repository is affected. Do not infer that from the trigger name alone. For a workflow that would be blocked, write down which legitimate action stops: dependency updates, contributor labeling, a release task, or something else. That gives the exception review a specific requirement instead of a general desire to keep CI green.

My review record would contain the workflow path, who may invoke it, the authority it needs, whether contributor-controlled code can execute, the observed evaluate-mode decision, and the person responsible for the policy. The record should not contain tokens, secret values, or raw logs that expose them.

A narrow exception still needs a negative test

Where an exception is justified, scope it to the intended workflow and callers rather than allowing the event everywhere. Minimize the job’s permissions independently. An allowed workflow should not inherit broad authority merely because it passed the execution policy.

Before enforcement, use a disposable repository with dummy data to check both an intended permitted event and an intended denied event. Review the policy decision as well as whether a job ran. In evaluate mode, a would-block result is an observation, not proof that execution was prevented.

Do not test secret theft against a live repository to demonstrate the risk. The useful acceptance condition is that the unwanted run cannot start under the enforced policy, while the legitimate workflow still performs its narrowly defined job.

Keep an owner and a recovery plan for the policy change. If a required workflow stops, inspect the failed rule and its scope; disabling protection across the organization is a poor substitute for fixing one exception.

I would finish the inventory and evaluate-mode review before the rollout date. The result should be a short list of workflows that can stay blocked, workflows that need redesign, and justified exceptions—not an organization-wide allowance added during an outage.