GitHub's December pull_request_target Rule Needs a Workflow Audit Now

A workflow can be written in a trusted repository and still execute code supplied by an untrusted contributor. That mismatch is why GitHub is tightening its default for pull_request_target in public repositories. The enforcement date is close enough that maintainers should inventory affected workflows now, not wait for a failed pull request to reveal them.

GitHub’s November 2 changelog says that starting December 2, Actions will block pull_request_target by default in public repositories unless an applicable event policy explicitly allows it. The policy is currently in evaluate mode: affected workflow runs continue, while policy insights show which ones would be blocked. GitHub scheduled two brownouts—November 9 and November 16, 16:00–18:00 UTC—during which affected runs will fail with an annotation before evaluation mode resumes. Private and internal repositories are excluded. ^[1]

The rule applies to public repositories on GitHub Free, GitHub Team, and GitHub Enterprise Cloud. GitHub says it does not apply to GitHub Enterprise Server. This is a default event policy, not a blanket removal of a workflow feature: repositories with an applicable event policy can allow the trigger, and GitHub documents how to inspect and manage those rules. ^{[1] [3]}

Why this event needs careful handling

pull_request_target runs a workflow from the base repository’s default branch and gives the job the base repository’s trust context. That can include a write-capable GITHUB_TOKEN and repository or organization secrets. Those permissions make the event useful for trusted automation such as labeling a pull request, adding a status, or triaging metadata without running contributor code. ^[2]

The danger begins when a workflow checks out a fork’s head and executes the resulting files. A test command may run a contributor-controlled Makefile, build script, package lifecycle hook, or dependency. That code can then use the credentials available to the job. GitHub calls this family of failures “pwn requests”; its security guidance describes why an untrusted change should be treated as data when it is handled in a privileged workflow. ^{[2] [4]}

That is a more precise way to think about the new default. The event itself is not proof of a vulnerability, and a block does not replace secure workflow design. The event has a higher-trust execution context, so teams should first ask whether they need that context at all. If ordinary pull_request behavior is sufficient, use it: fork pull requests run with a read-only token and without repository secrets by default. If a privileged workflow must inspect a fork’s code, separate inspection from execution and do not run untrusted scripts in the privileged job. ^[2]

A practical audit before the brownouts

Start with GitHub’s policy insights while the default is in evaluate mode. Find public repositories with pull_request_target runs and identify the workflows that would be blocked. Then review the workflow file and any reusable actions it invokes. Search for checkout steps that specify a pull request head, commands that build or test checked-out code, and downloads of artifacts produced by fork-triggered workflows. ^{[1] [2]}

For every affected workflow, record the job’s actual purpose and the minimum permissions it needs. If it only labels or comments, it may be possible to keep the operation on trusted metadata without running the pull request’s code. If it needs tests or builds, use a lower-privilege event where possible, or split the workflow so a restricted job handles untrusted code and a separate trusted step performs the narrowly scoped privileged action.

If a workflow truly requires pull_request_target, an administrator can add an applicable Actions event policy that allows the event. GitHub recommends targeting only the necessary workflows. That is safer than broadening event permissions at the repository or organization level without a clear reason. Keep GITHUB_TOKEN permissions least-privilege, restrict secrets, and avoid checking out or executing fork code in the privileged job. ^{[2] [3]}

The November brownouts are operational tests of the new default. They will temporarily fail affected runs for two hours, so teams should tell maintainers who depend on those workflows and monitor the resulting annotations. A failure during a brownout is a signal to investigate, not a reason to add a blanket allow policy. The permanent enforcement begins December 2. ^[1]

The safer default is only the first control

GitHub’s change makes a risky event harder to use accidentally in public repositories. It does not guarantee that an explicitly allowed workflow is safe, nor does it protect every trigger that can combine secrets with untrusted input. issue_comment and workflow_run workflows can also become dangerous if they fetch and execute fork code. The right review unit is the full chain: trigger, token permissions, secret access, checkout source, downloaded artifacts, and every command that executes. ^[2]

For maintainers, the next action is simple: use policy insights today, inspect each affected job, and make any exception narrow and documented. That preserves legitimate triage workflows while keeping external code away from privileged credentials. Our explainer on GitHub’s cloud Agent Merge discusses a separate kind of pull request automation, where code repair can help but review and repository rules remain the acceptance boundary.

Teams using GitHub’s agent-generated Actions workflows should also review our security guide to GitHub Agentic Workflows; those workflows raise a related question about what automated changes can execute and where approval belongs.