GitHub Is Blocking pull_request_target in Public Repos on December 2

GitHub is about to block a workflow trigger in public repos. On November 2, GitHub posted that starting December 2, 2026, GitHub Actions will block pull_request_target events by default in public repositories, unless an Actions event policy explicitly allows them. Before that, two brownouts: on November 9 and November 16, blocked runs fail for two hours. If you maintain a public repo, this week is a good week to look at your workflow files.

What's changing

From GitHub's changelog post (November 2, 2026):

• December 2, 2026: pull_request_target is blocked by default in public repos, unless an applicable Actions event policy allows it. Enforcement had been scheduled for November 2, 2026, and was moved back a month.
• Brownouts: November 9 and November 16, 16:00-18:00 UTC (11 AM to 1 PM Eastern). During each window, pull_request_target runs that the default rule blocks become failed runs with an error annotation, and the workflows don't execute. After each window, the rule goes back to evaluate mode, so workflows run with warnings.
• Who it hits: public repositories on GitHub Free, GitHub Team and GitHub Enterprise Cloud. Private and internal repos aren't affected, and neither is GitHub Enterprise Server. GitHub's docs add that the default policy doesn't replace an event policy you've already set up.

Why GitHub is doing it

pull_request_target runs in the context of the base repository. The job gets the base repo's GITHUB_TOKEN and access to its secrets, and it fires on pull requests from forks. That's what makes it useful for labeling, triage and posting status checks on outside contributions.

By default it's safe, because the workflow and the checkout come from your default branch, so no fork code runs. The trouble starts when a workflow checks out the pull request's head and then builds or tests it. GitHub's docs show the pattern as an insecure example:

# INSECURE. Provided as an example only.
on:
  pull_request_target:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      - name: Test
        run: make test

Here make test runs a Makefile from the fork, with your secrets and token. GitHub calls this a "pwn request" and says it "has been the root cause of multiple supply-chain compromises."

It shows up in AI tooling too. Claude Code's GitHub Action has a security section on running with pull_request_target or workflow_run, because both run with the base repository's secrets. Its advice: don't check out an untrusted ref into the workspace root before the action runs.

Check your repo this week

1. Open your repo (or org) Settings, then Actions > Policies, and look at Policy insights. GitHub says to use Insights before November 9 to see which runs the rule would block.
2. Search your .github/workflows/ folder for pull_request_target. A coding agent like Claude Code can do this across every repo you maintain and explain what each workflow does with the pull request.
3. For each hit, ask: does it need secrets or a write token? If not, GitHub recommends switching it to pull_request.
4. If it really needs the trigger, allow it in an Actions event policy and target only that workflow file. Then harden it: least-privilege GITHUB_TOKEN, only the secrets it needs, and never build or run code from an untrusted pull request.
5. GitHub's docs describe an actions/checkout protection for fork pull request refs, and you opt out of it with allow-unsafe-pr-checkout: true. GitHub says to do that only after confirming the checked-out code is never executed.

Here's how you get paid

My opinion: lots of open-source maintainers and small companies with public repos won't notice this until a run fails on November 9. That's a short, clear job you can sell this week.

Sell a pre-brownout Actions fix, priced per repo:

• Find: list every workflow that uses pull_request_target, plus what Policy insights says would be blocked. Claude Code does the first pass.
• Move: switch the workflows that don't need secrets to pull_request, and test them on a fork PR.
• Lock down: for the ones that stay, write a policy that allows only those workflow files, trim the token permissions and secrets, and remove any step that runs fork code.

Hand over a one-page note of what changed and why. No income is guaranteed, but the deadline does the selling for you.