GitHub will switch off pull_request_target for public repos on 2 November

Execution protections for GitHub Actions left preview this week, and the part worth putting in your calendar is not the feature — it is the date. On 2 November 2026 a default rule that disables the pull_request_target trigger starts being enforced on affected public repositories. Until then it runs in evaluate mode, so the runs that will fail are already visible, if you look.

The feature itself is an allowlist for workflow runs: actor rules say who may trigger a workflow, event rules say which events may start one, and both are evaluated before a run begins. General availability adds three things that turn it from a switch into policy — rules can target individual workflow files rather than a whole repository, so deploy.yml can be restricted to one team while CI stays open to contributors; an insights view shows how the rules are being applied across an organisation; and a REST API creates, reads, updates and deletes rules at enterprise, organisation and repository level, which is what you need if the answer has to be the same across hundreds of repositories.

Why pull_request_target is the one they picked

Because it is the trigger that runs with your secrets available in the context of the base repository, while the code under test came from a fork. That combination is the mechanism behind the class of attacks known as pwn requests: untrusted code executes in a privileged context and walks out with whatever the job can read. GitHub's default rule applies only to public repositories that have no applicable event policy of their own; private and internal repositories are untouched.

What it means

Do the evaluate-mode reading now, not in late October. The rule is already telling you which of your runs would be blocked, and the cost of finding out on 2 November is a broken pipeline on someone else's schedule — the same failure mode as any silent default change, except this one announced itself six weeks ahead.

Then make an actual decision per workflow, not per repository. There are two honest answers. Either the workflow does not need pull_request_target — most do not, and pull_request plus a separate privileged job is the usual rewrite — or it genuinely does, in which case the new file-level targeting lets you allow it for that one file and leave the blanket block in place everywhere else. The thing to avoid is re-enabling the trigger repository-wide because one workflow complained.

And note what this says about defaults in general. GitHub is not shipping a new protection here so much as changing which way the unset value points, for repositories whose owners never expressed a preference. That is the most effective security change a platform can make, and it is also the one most likely to break something quietly at scale — which is exactly why the shadow mode and the six-week runway are the interesting engineering, not the allowlist.