GitHub pull_request_target December 2026 Explained: The November 2 Date Moved — What to Audit Before December 2

Illustrative image: a data-centre server room. GitHub Actions is a hosted CI service, not a device, so there is no product photo for it — this image stands in for the infrastructure its workflows run on. Image: Wikimedia Commons / BalticServers, CC BY-SA 3.0.

TL;DR: GitHub pull_request_target December 2026 explained: nothing breaks today. The November 2 date printed in many guides is out of date — GitHub moved enforcement to December 2, 2026. From that date, public repositories with no Actions event policy will have pull_request_target workflows blocked by default. Check your policy insights now, and either replace the trigger or allow it explicitly before December 2.

📌 KEY HIGHLIGHTS

• GitHub's workflow execution protections went generally available on September 17, 2026, with a default rule that disables pull_request_target in public repositories.
• Enforcement is December 2, 2026 — not November 2. GitHub updated the date in an editor's note on October 21, 2026, but many guides still carry the old date.
• The default rule does not apply to private or internal repositories, and it does not override an event policy you already configured.
• Until December 2 the rule runs in evaluate mode: runs still execute, and policy insights show which ones would be blocked.
• pull_request_target is risky because it runs with the base repository's secrets — checking out and executing fork code under it is the "pwn request" attack.

What happened?

If you maintain an open-source project, today may have felt like a deadline. Search for this change and you will find guide after guide saying GitHub starts blocking pull_request_target on November 2, 2026. That date was real when those guides were written — and then GitHub moved it.

The underlying feature is GitHub's workflow execution protections, which reached general availability on September 17, 2026 after a public preview that opened on June 18. They add a policy layer above your workflow files: actor rules control who can trigger a workflow, and event rules control which events are allowed to start one, evaluated before a run begins. General availability added per-workflow-file targeting, Insights for auditing what rules would block, and a REST API for managing policies as code across many repositories.

Shipped with the feature is a default rule aimed at one specific trigger. For public repositories that do not already have an applicable event policy, GitHub adds a rule that disables pull_request_target. It starts in evaluate mode, a shadow mode in which runs continue but GitHub records which ones enforcement would stop. The original announcement said automatic enforcement would begin on November 2, 2026. On October 21, 2026, GitHub edited the changelog post: the date is now December 2, 2026. The current documentation says the same. So today, November 2, nothing changes for repositories on the default — you have one more month, and the guides that say otherwise are simply stale.

GitHub pull_request_target December 2026 explained: how the block actually works

The scope of the default rule is narrower than "GitHub turns off pull_request_target," and the narrowness matters. It applies only to public repositories. It applies only when no applicable event policy already exists — a policy set at the organisation level counts, so a repository that looks unprotected from the outside may already be covered. And automatic enforcement on December 2 reaches only repositories that were using the default pull_request_target policy before general availability. If you already configured a policy, your policy decides, not the default.

When enforcement lands, a disallowed run fails with an error instead of starting. GitHub's documentation shows the shape of that error for a blocked event: the run is refused because the event is not allowed to trigger workflows, naming the workflow file. For teams, the practical difference between evaluate mode and enforcement is therefore binary — today the same run executes and gets logged as would-be-blocked; from December 2 it does not run at all.

There is also a separate, earlier change that is easy to confuse with this one. Since July 20, 2026, actions/checkout version 7 refuses to check out fork pull request code inside pull_request_target and workflow_run workflows unless you explicitly opt in. That change already shipped. The December 2 change is different: it stops the workflow from triggering in the first place.

Illustrative image: server racks, the kind of infrastructure that runs CI jobs. Image: Wikimedia Commons / Jemimus (via DigitalIceAge), CC BY.

Why pull_request_target is the trigger GitHub picked

pull_request_target exists for a legitimate reason: it lets automation respond to pull requests from forks while holding secrets and a write-capable token — labelling, triage, and authenticated status checks are the classic uses. The workflow file itself comes from the base repository's default branch, not from the fork, so by default no fork code executes.

The danger arrives when a workflow author overrides that safety. Pointing actions/checkout at the pull request head, fetching the fork's branch, or downloading an artifact from a fork's run and then building, testing, or running the result means untrusted code executes with the base repository's secrets. GitHub's security lab calls this a pwn request, and it has caused real supply-chain compromises: a stranger only needs to open a pull request whose build script, test command, or dependency contains malicious commands. Cache poisoning across the fork-to-base trust boundary and token extraction from runner memory have both featured in real incidents.

The exposure is not theoretical at scale. A third-party scan of the 1,000 most-starred public repositories on September 26, 2026 found 269 of them running at least one pull_request_target workflow, across 540 workflow files. Treat that as an upper bound, not a casualty count: organisation-level policies are not visible from outside, so some of those repositories already allow the trigger and will keep running.

What to do before December 2

The audit takes minutes for a single repository and scales with the REST API for an organisation. Work through it in this order:

• Check whether the default even applies. Open Settings, then Actions, then Policies, at the repository or organisation level. If an applicable event policy already exists, the default rule steps aside and your policy decides.
• Read the insights. While the rule is in evaluate mode, policy insights list the runs that would be blocked after enforcement. That list is your work queue — start there, not with a blind search.
• Find every workflow that uses the trigger. Search your default branch for pull_request_target in .github/workflows, including reusable and generated workflow files. The search command is: git grep -n -E '^\s*pull_request_target:' -- '**/.github/workflows/*.yml' '**/.github/workflows/*.yaml'
• For each workflow, decide which of three moves fits. If it does not need secrets or write access, switch it to the pull_request event, which runs with a read-only token. If it needs both untrusted code and privileged actions, split it: an untrusted pull_request workflow plus a privileged workflow_run workflow, treating everything passed between them — including artifacts — as untrusted. If it genuinely needs pull_request_target, create an event policy that explicitly allows it, scoped to that specific workflow file.
• Do not fix a block by allowing everything. A repository-wide exception for pull_request_target reopens the exact hole the default closes. And do not set the allow-unsafe-pr-checkout flag in actions/checkout unless you have confirmed the checked-out code is only ever inspected as data and never executed — the flag's name is deliberately hard to miss in code review.
• Check your bots as actors, not just events. Actor rules decide who may trigger workflows, including GitHub Apps, Copilot, and Dependabot. A workflow that depends on a bot trigger can fail after December 2 for actor reasons even if its event is allowed, so include bot-triggered workflows in the same audit.

Date	What happened
June 18, 2026	Workflow execution protections enter public preview; actions/checkout v7 starts refusing fork checkouts in pull_request_target and workflow_run workflows (July 20 change)
September 17, 2026	Workflow execution protections reach general availability; default pull_request_target rule begins in evaluate mode
October 21, 2026	GitHub edits the changelog: automatic enforcement moves from November 2 to December 2, 2026
December 2, 2026	Default rule enforced for affected public repositories still on the default pull_request_target policy

Why it matters for India readers

No India-specific GitHub announcement is attached to this change, and this post does not invent one. The relevance is read-across: India has a large open-source maintainer community, a growing startup ecosystem publishing public repositories, and many student and hackathon projects on public repos with Actions workflows copied from templates. Template workflows are exactly where pull_request_target hides unnoticed — a label bot or preview deploy added years ago, still running on the default. For those maintainers, the December 2 date is a free audit window: the evaluate-mode insights will tell you what breaks before anything actually breaks. Teams that run self-hosted runners should pay extra attention, since a pwn request on shared, persistent runner infrastructure can reach further than one ephemeral cloud runner.

Should you care?

✅ Verdict: If you maintain any public repository, yes — spend the ten minutes. Check your Policies page and your insights list before December 2, and you will know exactly what breaks, if anything. If you have no public repositories and no pull_request_target workflows, this change does not touch you — but the pwn request pattern is still worth knowing, because the same trust-boundary mistake appears in private CI too. The one thing not to do is panic today: November 2 was the old date, and GitHub's own changelog says December 2.

FAQs

When will GitHub block pull_request_target?
On December 2, 2026, GitHub will automatically enforce the default rule for affected public repositories that were using the default pull_request_target policy before general availability. Until then the rule runs in evaluate mode, so runs continue and policy insights show which ones would be blocked.

Does the GitHub pull_request_target block apply to private repositories?
No. The default rule does not apply to private or internal repositories, and it does not replace an event policy you have already configured. Private repositories carry the same pwn request vulnerability in their own workflows, though, so auditing them is still worthwhile even though the default will not block them.

What is a pwn request in GitHub Actions?
A pwn request is an attack in which a pull request from a fork causes untrusted code to execute with the base repository's secrets and token. It typically happens when a pull_request_target workflow checks out the fork's code and then builds, tests, or runs it — for example, a Makefile or build script from the pull request executing with elevated privileges.

How do I keep using pull_request_target after December 2?
Create or update an applicable Actions event policy that explicitly allows pull_request_target, ideally scoped to only the specific workflow files that need it using workflow file targeting. Only allow it when necessary, and make sure those workflows never check out, build, or run code from an untrusted pull request with access to repository secrets.

What actually happened on November 2, 2026?
Nothing changed. November 2 was the enforcement date in GitHub's original September 17 announcement, and many guides written before October 21 still print it. On October 21, 2026, GitHub updated the changelog to December 2, 2026, and the current documentation confirms the December date. If a guide you read says November 2, it is stale — the live date is December 2.

TAKEAWAY: The deadline moved, the risk did not. GitHub gives public repositories until December 2 to audit pull_request_target — use the evaluate-mode insights, replace what you can, and explicitly allow only what you must.

Follow World Tech on TechByCountry for tomorrow's update.

📸 Get tech in the last 24 hours on Instagram — follow @_techinlast24hrs for daily posts (9 AM–9 PM) and reels at 12:30 PM & 8:30 PM.

Sources

• GitHub Changelog: Workflow execution protections in GitHub Actions generally available (September 17, 2026, incl. October 21 editor's note)
• GitHub Docs: About Actions policies
• GitHub Docs: Securely using pull_request_target
• GitHub Docs: Governing execution of GitHub Actions workflows
• Wiz Blog: GitHub Actions security and the pwn-request reckoning

Related reading on TechByCountry: GitHub Copilot server-to-server authentication, GitHub Copilot assisted permissions, and the Visual Studio 2026 October update.