> ## Content Index
> Fetch the complete content index at: https://wealthlab.life/llms.txt
> Use this file to discover other available public pages before exploring further.

# GitHub Will Block pull_request_target by Default: Who Must Act Before December 2
- URL: https://wealthlab.life/github-pull-request-target-default-block-december-2026/
- Published: 2026-11-03T00:07:07.000Z
- Updated: 2026-11-03T00:07:07.000Z
- Description: GitHub's December 2 secure default changes how public repositories run pull_request_target workflows. Learn who is affected and how to preserve safe automation.
- Author: WealthLab
- Tags: Security, Cloud Infrastructure, AI Agents

**In brief:** GitHub will begin enforcing a secure default on **December 2, 2026** that disables `pull_request_target` in affected public repositories when no applicable event policy already governs it. This is not the removal of the event, and it is not a blanket change for every repository. It is a change from implicit permission to explicit policy for a trigger that can combine untrusted pull-request context with access to the base repository.

Maintainers should use the remaining time to find workflows triggered by `pull_request_target`, identify which jobs genuinely need base-repository context, and decide whether to replace the trigger or define a narrow repository or organization event policy. Simply restoring the old behavior without reviewing checkout, permissions, secrets, and third-party actions would preserve the risk that motivated the new default.

This is a source-based migration advisory. WealthLab reviewed GitHub’s September 17 general-availability announcement, GitHub’s event and secure-use documentation, GitHub Security Lab’s “pwn request” guidance, and independent vulnerability research. We did not run an exploit or change a live repository for this article.

## The December 2 change is narrower than “GitHub disabled the event”

GitHub introduced workflow event policies as a generally available Actions control on September 17, 2026\. A policy can allow, require approval for, or block selected workflow-triggering events. The new secure default applies to public repositories that do not already have an applicable event policy: `pull_request_target` is disabled by default.

GitHub says it will automatically enforce that default on December 2 for affected repositories that were using the default `pull_request_target` policy before general availability. The announcement explicitly says the default does not apply to private or internal repositories. Organizations and enterprises can set broader policies, while repository administrators can manage repository-level policy within the limits imposed above them.

That scope matters. A workflow file containing the trigger is not proof that it will stop on December 2; an applicable organization or enterprise rule may already decide its behavior. Conversely, a workflow that has run for years is not proof that it is exempt. The policy chain, repository visibility, and current rule all need to be read together.

## Why pull\_request\_target has a different trust boundary

The ordinary `pull_request` event is designed around the pull request’s merge context and receives reduced privileges for forks. `pull_request_target` runs in the context of the base branch. GitHub’s documentation notes that this can permit access to secrets and grant a read/write repository token, depending on repository and workflow settings.

That base context is useful for safe metadata tasks such as labeling, assigning, or commenting when a contribution comes from a fork. It becomes dangerous when the same job executes code controlled by the contributor. GitHub’s event documentation explicitly warns against building or running untrusted pull-request code under this event because doing so can lead to repository compromise or secret leakage.

The classic failure path is deceptively short:

1. A public workflow is triggered by `pull_request_target`.
2. The job checks out the contributor-controlled pull-request head, or otherwise executes content that the contributor can alter.
3. The job has a secret, a write-capable token, a trusted publishing identity, or access to a persistent self-hosted runner.
4. Malicious code runs inside the privileged base-repository context.

GitHub Security Lab calls this class a “pwn request.” Independent research from Wiz and StepSecurity has documented real vulnerable workflows across prominent open-source projects. Those findings do not mean every use of `pull_request_target` is exploitable; they corroborate that unsafe checkout-and-execute patterns recur in production repositories.

## Who is most likely to be affected

**Public repositories with no explicit workflow event policy** are the direct audience for the new default. Maintainers should not infer policy state from a workflow file alone; inspect Actions policy at the repository and, where applicable, organization and enterprise levels.

**Projects using the event only for metadata** may be able to preserve the workflow with an explicit allow rule after confirming that the job never checks out or executes contributor-controlled content. The policy decision should be attached to that narrow job, not treated as approval for unrelated privileged automation.

**Projects that build or test pull-request code** should normally move that execution to `pull_request` with least privilege. If a later privileged step must publish a result or perform a controlled write, use a separate workflow and validate the artifact and source identity before granting authority.

**Private and internal repositories** are outside this particular default, according to GitHub’s announcement, but the underlying trust issue remains. A compromised contributor account, malicious dependency change, or untrusted automation can still supply hostile content. Visibility is not a security boundary for code execution.

**Self-hosted runner users** have an additional persistence concern. A malicious job may reach local caches, Docker sockets, internal services, or state left for the next run. Changing the event policy does not make a long-lived runner ephemeral or isolate it from the network.

## A decision tree for each workflow

### 1\. Does the job need to execute pull-request code?

If yes, prefer `pull_request` and its reduced fork permissions. Keep the token read-only unless the job has a specific, reviewed need. Do not expose repository or environment secrets to code supplied by an untrusted fork.

### 2\. Does it only need base-repository metadata authority?

A labeler, assignment rule, or carefully constrained comment workflow may be a legitimate `pull_request_target` use. Do not check out the pull-request head. Avoid interpolating attacker-controlled title, body, branch, or file values directly into shell commands. Pin third-party actions to reviewed full commit SHAs.

### 3\. Does a privileged result depend on an earlier untrusted job?

Separate the stages. A low-privilege workflow can build or test. A privileged workflow can consume only a narrowly defined result after verifying the expected repository, workflow, commit, artifact, and conclusion. An artifact is input, not evidence of safety; do not execute scripts or load configuration from it without validation.

### 4\. Is pull\_request\_target still necessary after the review?

If no, delete the trigger rather than creating an allow policy for historical convenience. If yes, document the exact safe purpose and define the narrowest applicable policy. An explicit allow rule is a security exception and should have an owner and review date.

## Migration patterns that preserve useful automation

- **Build and test:** use `pull_request`, read-only permissions, no secrets, and an ephemeral runner.
- **Labels and assignments:** keep a metadata-only `pull_request_target` job that does not fetch or execute contributor code.
- **Comments:** pass fixed arguments to an API or maintained action; keep attacker-controlled text out of shell program construction.
- **Release or package publishing:** trigger from a trusted branch, signed tag, protected environment, or reviewed workflow chain—not directly from a fork pull request.
- **Two-stage workflows:** validate the producer identity and artifact contents before a privileged consumer acts. Minimize the consumer token and avoid interpreting contributor-supplied commands.
- **Reusable workflows:** inspect both caller and callee permissions. A reusable file can centralize controls, but it can also centralize an unsafe assumption.

GitHub’s secure-use guidance recommends least-privilege token permissions, pinning third-party actions to full commit SHAs, reviewing source, protecting credentials, and using environments for sensitive deployment gates. These controls complement the event policy; none substitutes for choosing the correct trigger.

## How to inventory exposure without executing a workflow

Start with static repository inspection. Search default-branch workflow files under `.github/workflows/` for `pull_request_target`. For every result, record:

- the job’s declared `permissions` and whether repository defaults grant more;
- every secret, environment, OIDC permission, package credential, and app token it can reach;
- whether it checks out a pull-request ref or uses contributor-controlled files;
- shell commands that interpolate pull-request titles, bodies, branch names, paths, or artifact data;
- third-party actions and whether they are pinned to full commit SHAs;
- runner type, persistence, network reach, and access to Docker or host resources;
- the effective event policy at repository, organization, and enterprise scope.

Review the workflow at the default branch because `pull_request_target` uses the base branch’s workflow definition. Also review called workflows and composite actions: the dangerous execution may be hidden behind a reusable component rather than visible in the trigger file.

A code search is an inventory, not a vulnerability verdict. Whether a workflow is exploitable depends on data flow, permissions, token behavior, runner context, and the exact revisions of actions it invokes.

## What not to do on December 1

Do not create a repository-wide allow rule merely to prevent failed automation. Do not switch to another privileged event without tracing what input it executes. Do not assume a pinned action makes an unsafe checkout safe, and do not assume a GitHub-hosted runner prevents token or secret exfiltration.

A workflow that turns red after enforcement is inconvenient. A rushed policy exception can restore a path from an untrusted contribution to repository write access. If the review cannot finish in time, leave the workflow blocked and restore only the low-risk function after redesign.

## Rollback and incident considerations

For a migration problem, rollback means restoring the previous trigger only after confirming its trust boundary—not blindly reverting the patch. Keep the old workflow disabled while testing the replacement on a non-sensitive repository or with permissions removed.

If review finds that an unsafe privileged workflow previously ran untrusted code, treat it as potential credential exposure. Preserve relevant Actions logs, identify affected runs and commits, revoke or rotate reachable credentials, inspect unexpected repository writes and releases, and replace persistent runners rather than trusting superficial cleanup. The required response depends on what authority the job actually held; the trigger name alone cannot establish impact.

## Evidence boundary and sources

**Sources checked November 3, 2026.** GitHub is authoritative for the September 17 announcement, December 2 enforcement date, policy scope, event behavior, and current security guidance. GitHub Security Lab explains the unsafe pattern. Wiz and StepSecurity provide independent evidence that variants of the pattern have appeared in major open-source workflows. Their case studies are historical examples, not proof that a particular repository remains vulnerable today.

- [GitHub Changelog: Workflow execution protections generally available](https://github.blog/changelog/2026-09-17-workflow-execution-protections-in-github-actions-generally-available/) — secure-default scope and December 2 enforcement.
- [GitHub Docs: events that trigger workflows](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull%5Frequest%5Ftarget) — base-context behavior and warning against running untrusted code.
- [GitHub Docs: secure use](https://docs.github.com/en/actions/how-tos/security-for-github-actions/security-guides/security-hardening-for-github-actions) — token, action pinning, injection, and credential guidance.
- [GitHub Security Lab: Preventing pwn requests](https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/) — attack pattern and safer workflow separation.
- [Wiz Research: GitHub Actions pwn request research](https://www.wiz.io/blog/github-actions-security-pwn-request-reckoning) — independent case studies and ecosystem analysis.
- [StepSecurity: Pwn request vulnerability research](https://www.stepsecurity.io/blog/github-actions-pwn-request-vulnerability) — independent examples of unsafe trigger and checkout combinations.

No exploit, repository policy change, runner test, or incident investigation was performed. This article contains no affiliate links.

## Related WealthLab guides

- [GitHub Agentic Workflows is GA](https://wealthlab.life/github-agentic-workflows-ga-self-hosted-runners/) — decide where agentic jobs should run and separate input, execution, authority, and output boundaries.
- [GitHub AI pull-request scanning limits](https://wealthlab.life/github-ai-scan-pull-requests-merge-gate-limits/) — distinguish automated review from a deterministic merge gate.
- [GitHub Copilot local sandboxing](https://wealthlab.life/github-copilot-local-sandboxing-operator-checklist/) — understand what process isolation can and cannot protect.
- [VPS firewall guidance for Docker applications](https://wealthlab.life/vps-firewall-docker-apps/) — reduce runner and service network exposure outside the workflow layer.