GitHub will block pull_request_target in public repos from December 2

I have a confession. The first time I wired up pull_request_target, it was to auto-label PRs from first-time contributors, and I picked it because plain pull_request kept failing on fork PRs with a token that couldn't write labels. It worked on the first try. I felt clever for about a week, until a colleague asked what would happen if that workflow ever checked out the contributor's code, and I didn't have a good answer.

GitHub has now picked an answer for all of us. According to the GitHub Changelog, starting December 2, 2026, GitHub Actions will block pull_request_target events by default in all public repositories unless an applicable Actions event policy explicitly allows them. Enforcement had previously been scheduled for November 2, so you get one extra month and two rehearsals.

The dates and the scope

The default flips on December 2. Until then the rule runs in evaluate mode, so you can see which workflow runs it would block without anything actually stopping.

Two brownouts come first: November 9 and November 16, 2026, each from 16:00 to 18:00 UTC. During those windows the block is real. Affected workflows produce failed runs with an error annotation and don't execute. Both dates are Mondays, which puts the window in late morning on the US east coast and late afternoon in central Europe. Plenty of people will be mid-review when their bot goes quiet.

The scope is narrower than the headline. It covers public repositories on GitHub Free, Team and Enterprise Cloud. Private and internal repositories aren't affected, and neither is GitHub Enterprise Server.

Why your secrets are the point

GitHub's reasoning is short. pull_request_target runs in the context of the base repository and can access its secrets. If a workflow on that trigger executes untrusted code from a fork, that code could compromise the pipeline or steal those secrets.

For context on how we got here: with plain pull_request, a fork PR gets a read-only token and no repository secrets. Safe, and frustrating if all you wanted was a label. pull_request_target became the workaround because it runs the workflow definition from the base branch with the base repository's permissions. That holds up as long as the job only touches PR metadata. It falls apart the moment a step checks out the PR head and runs a build script, an install hook or a test suite from it, because now someone else's code is running next to your tokens.

I understand why so many of us reached for it. It made the contributor experience nicer: a label on arrival, a welcome comment, sometimes a preview deploy. After December 2, that convenience needs a deliberate decision from someone with the rights to make it.

Getting ready before November 9

Start by finding out what you own. GitHub points you to Insights to review the workflows the rule would affect. A local search is a quick second check, and it takes seconds per repo:

grep -rln "pull_request_target" .github/workflows/

Then decide workflow by workflow. The changelog lists two options: keep the default block, or explicitly allow pull_request_target in an applicable Actions event policy. If you allow it, workflow file targeting lets you allow specific workflows instead of the trigger as a whole.

My own rule of thumb: a workflow that only reads PR metadata and writes labels or comments is a candidate for a narrow, targeted allow. A workflow that builds, tests or deploys the fork's code should move to pull_request, where the fork gets no secrets, with any privileged step kept apart from it.

Treat the brownouts as a free test run. If something you care about breaks on November 9, you have a week to fix it before November 16, and two more weeks before the block sticks.

Rough edges

The failure is quiet for contributors. A blocked run fails with an annotation in the Actions tab, and a first-time contributor has no reason to know why the welcome bot never showed up. If your triage depends on that bot, tell your maintainers before the first brownout.

An allow restores the old behaviour, risk included. Workflow file targeting keeps the allowance small, but if the allowed workflow still checks out and runs fork code, the policy just puts your name on the hole.

Evaluate mode only helps if someone looks at it. Teams that learn about this from a red build on a Monday afternoon will have less time than the calendar suggests.

How other CI systems treat fork code

Running a stranger's code near your credentials is an old problem, and most CI systems landed on secrets for forks being opt-in. GitLab runs merge request pipelines from forks in the fork's own project by default, so they don't see the parent project's CI/CD variables unless a parent project member chooses to run the pipeline in the parent project. Jenkins, through its GitHub Branch Source plugin, has a trust setting for fork PRs and reads the Jenkinsfile from the target branch when the fork isn't trusted. CircleCI keeps passing secrets to builds from forked pull requests switched off until a project admin turns it on.

Across all three, a person with admin rights makes the call, and the default is no. GitHub's change brings pull_request_target in public repositories into the same model.

What I'm watching next: how many popular open-source projects add a blanket allow on December 1 to make the red go away, and how many use workflow file targeting to allow one labeling workflow and nothing else. Run that grep this week and tell me what turned up. I suspect a few of us will find a workflow we forgot we wrote.