Blog
2 min read

GitHub Actions Will Block pull_request_target by Default in Public Repos From 2 November

GitHub made workflow execution protections generally available on 17 September 2026: actor and event rules that control who and what can trigger workflows. For public repositories, a default rule disabling pull_request_target starts in evaluate mode and will be enforced on 2 November 2026. Why, and what maintainers should do now.

On 17 September 2026, GitHub made workflow execution protections generally available. They let enterprises, organisations and repositories allowlist who can trigger workflows (actor rules) and which events can start them (event rules) — checked before a run starts.

The part most maintainers need to act on: for public repositories, GitHub added a default rule that disables pull_request_target, which will be enforced automatically on 2 November 2026 for affected repos.

Why pull_request_target is being switched off

pull_request_target runs workflows in the context of the base repository — with access to its secrets and a write-capable token — even for pull requests from forks. If such a workflow checks out and runs the fork's code (installing its dependencies, running its tests or build scripts), an attacker's pull request can steal secrets or poison caches and releases. It's been behind a long list of real supply-chain incidents. (GitHub Actions Secrets, npm Supply Chain Security)

Who's affected

  • Public repositories without an applicable event policy that used the default pull_request_target policy before GA.
  • Not private or internal repositories.

The rule starts in evaluate mode — logging what it would block — until enforcement on 2 November.

What maintainers should do now

  1. Check Insights for your repository's workflow execution protections: evaluate mode shows which runs would fail once enforcement begins.
  2. Decide per workflow:
    • If you don't need pull_request_target, keep the rule and switch the workflow to pull_request (no secrets for forks — usually what you want).
    • If you do need it (labelling, commenting on fork PRs), explicitly allow it in an Actions event policy, using workflow file targeting to allowlist only that workflow.
  3. Never check out and execute fork code in a pull_request_target workflow that has secrets. Restrict its token permissions to the minimum.
  • cache-mode limits cache access per workflow/job; low-trust triggers like pull_request_target default to read-only. (GitHub Actions Caching)
  • Self-hosted runner minimum versions are now enforced on GitHub Enterprise Cloud.

The takeaway

Defaults are getting safer, but your workflows are still your code. Treat anything triggered by an outsider as untrusted input — the same rule that applies to AI agents reading web pages. (Prompt Injection in Coding Agents)

Source: GitHub Changelog: Workflow execution protections generally available

EasySpawn keeps your deploy credentials on your own server rather than in CI secrets that fork workflows might reach, with GitHub Actions as an independent check on every pull request. See how it works or join the waitlist.

Related: GitHub Actions CI Basics · Secret Scanning · Principle of Least Privilege · GitHub Actions Removed Node 20

Keep reading