GitHub blocks pull_request_target Dec 2; 36% of top repos use it

From December 2, 2026, GitHub Actions will block the pull_request_target trigger by default in every public repository, GitHub said in its changelog on November 2. Only an Actions event policy that allows it keeps it running. If your team keeps a public repo on GitHub Free, Team or Enterprise Cloud, workflows that label or triage pull requests from forks may stop.

The trigger is common. We cloned the workflow folders of the 100 most-starred repositories on GitHub on November 3, and 36 of them had at least one workflow that uses it.

Two test blocks come first

GitHub will enforce the block during two brownouts before it becomes permanent: November 9 and November 16, each from 16:00 to 18:00 UTC. During those windows, blocked runs fail with an error annotation and the workflow does not execute. Afterward the rule returns to evaluate mode, where workflows run with warnings.

Enforcement had been scheduled for November 2. Private and internal repositories are not affected, and neither is GitHub Enterprise Server. Classmethod’s timeline, published October 30, also gives December 2 and records the date change in an editor’s note dated October 21.

Why GitHub is switching it off

pull_request_target runs in the context of the base repository and can read its secrets. If a workflow runs code from a fork, “that code could compromise your pipeline or steal secrets,” the changelog says. GitHub’s documentation calls the classic mistake, checking out the pull request’s head commit and running it, a “pwn request.”

This has happened to a real project. In December 2024, an attacker got code running in a pull_request_target workflow at Ultralytics, a Python AI library, by putting a payload in a branch name, William Woodruff wrote. Version 8.3.41, which shipped to PyPI on December 4, contained a crypto miner.

Most uses are housekeeping

For fork pull requests, the ordinary pull_request event gets a read-only token and no access to other secrets, the same docs say. So chores that write to the repo, such as adding a label, reach for pull_request_target. The docs name “labeling, triage” as its intended use.

Our scan found 88 such workflow files across the 36 repositories. The names are mostly chores: 17 contain “label”, and others run CLA checks, PR-template checks and spam filters, at projects including React, Node.js, Electron, n8n and Hugging Face Transformers.

Of the 88 files, 18 reference the pull request’s head branch or commit. That is where the risky patterns start: Ultralytics fell to a branch name, and the docs warn against checking out the head commit. A reference alone is not a flaw, and we did not check whether any is exploitable. We also cannot see which of these repositories already set a policy that allows the trigger, so 36 counts use, not breakage.

What to do now

1. Look before November 9. In the repository or organization, open Settings, then Actions, then Policies. Policy insights lists the runs the rule would block, the docs say.
2. Drop the trigger where you can. If a workflow never needs secrets or write access for fork PRs, switch it to pull_request.
3. Allow only what you need. For labelers and CLA bots, add an event policy scoped to those workflow paths rather than allowing the trigger repository-wide.
4. Check what the allowed ones run. Never check out and execute the PR head inside them. The trade-off is plain: every workflow you allow keeps the exposure the default block removes.
5. Find your own count. Run grep -rln pull_request_target .github/workflows in each public repo to list the files the November 9 brownout will touch.

Sources

• GitHub changelog, “pull_request_target blocked by default December 2,” November 2, 2026: https://github.blog/changelog/2026-11-02-pull_request_target-blocked-by-default-december-2
• GitHub Docs, “Securely using pull_request_target”: https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target
• GitHub Docs, “Controlling workflow execution”: https://docs.github.com/en/actions/how-tos/administer/control-workflow-execution
• Classmethod (Yuji Nishimura), October 30, 2026: https://dev.classmethod.jp/en/articles/github-actions-pull-request-target-pwn-request/
• William Woodruff, Ultralytics compromise, December 6, 2024: https://blog.yossarian.net/2024/12/06/zizmor-ultralytics-injection
• 28creation scan: the .github/workflows folders of the 100 most-starred repositories (GitHub search API, sorted by stars), shallow-cloned November 3, 2026, searched for a pull_request_target trigger line