GitHub Actions

Public pull_request_target enforcement starts November 2

By CI Tripwire Editorial · Research · Published 2026-09-23 · Updated 2026-09-23 · 10 min read

On November 2, 2026, GitHub will enforce a default pull_request_target block for "affected repositories that were using the default pull_request_target policy before general availability." [1] The default is in evaluate mode, so workflow runs still start. [1] It is added on public repositories with no applicable Actions event policy yet, and it leaves private and internal repositories out. [1]

Key takeaways for the November 2 pull_request_target default

  • The September 17, 2026 changelog says workflow execution protections are "generally available for GitHub Enterprise, organizations, and repositories." [2]
  • That changelog adds workflow-file targeting, an Insights view, and a REST API. The API can add a rule, fetch it, change it, or remove it, and a rule can name a workflow path. Those calls exist at enterprise scope, organization scope, and repository scope. [2]
  • GitHub adds the default on a public repository that does not yet have an applicable Actions event policy. Private repositories are outside it. Internal repositories are outside it. An applicable event policy already in place stays in place. [1]
  • The default is in evaluate mode, so workflow runs still start. Policy insights show which of those runs enforcement would block. [1]
  • Enforcement date: November 2, 2026, for "affected repositories that were using the default pull_request_target policy before general availability." [1]
  • A July 15, 2026 editor's note moved checkout backport enforcement from July 16, 2026 to July 20, 2026. Full SHA pins, minor tags, and patch tags are outside that backport. actions/checkout v1 is excluded from the backport. [3]

Skip to:

November 2, 2026 covers repositories on the default before general availability

Bottom line: Enforcement date: November 2, 2026, for "affected repositories that were using the default pull_request_target policy before general availability." The default is in evaluate mode, so workflow runs still start.

The September 17, 2026 changelog says workflow execution protections are "generally available for GitHub Enterprise, organizations, and repositories." [2] GitHub's Actions policies page says that on public repositories, the new default will block pull_request_target, and that page dates enforcement to November 2, 2026. The page links to Securely using pull_request_target. [4]

Where GitHub's default pull_request_target policy applies, retrieved 2026-09-23 [1]
Repository What the default does now November 2, 2026
Public, and no applicable Actions event policy yet GitHub adds a default that blocks workflows started by pull_request_target. Runs still start during evaluate mode. Enforcement hits the pre-general-availability cohort named in the bottom line.
Public, with an applicable event policy already configured An applicable event policy already in place stays in place. An applicable event policy is not replaced. The November 2, 2026 sentence names repositories on the default before general availability, as its own sentence.
Private or internal Private repositories are outside the default. Internal repositories are outside the default. This default does not add a November 2, 2026 block.
Check the date before you treat it as fixed: A July 15, 2026 editor's note moved checkout backport enforcement from July 16, 2026 to July 20, 2026. Full SHA pins, minor tags, and patch tags are outside that backport. actions/checkout v1 is excluded from the backport. [3] Recheck the pull_request_target guide and the September 17, 2026 changelog before treating November 2, 2026 as fixed. Both were retrieved September 23, 2026.

September 17, 2026 is when the policy feature became generally available

The September 17, 2026 changelog says workflow execution protections are "generally available for GitHub Enterprise, organizations, and repositories." [2] The workflow execution protections guide on this site records the preview setup as of August 5, 2026, including actor rules and event rules. General availability is this later changelog.

The changelog describes an allow list evaluated before a run. Actor rules are the who. Event rules are the what. [2] General availability adds three controls on top of that preview.

  • Workflow file targeting. A rule can name specific workflow files. The changelog's example restricts deploy.yml to a designated team and leaves CI workflows open to all contributors. [2]
  • Insights. Insights shows how Actions evaluates and enforces rules across the enterprise, the organization, and repositories. [2]
  • REST API. A caller can add a rule, fetch it, change it, or remove it. Workflow path conditions are part of that API. The same calls exist for an enterprise, an organization, and a repository. [2]

Evaluate mode from the preview remains. A rule can run in shadow mode, and the runs it would block are visible before enforcement. [2]

The default covers public repositories with no event policy yet

Enforcement date: November 2, 2026, for "affected repositories that were using the default pull_request_target policy before general availability." [1] A separate rule says who receives the default now: GitHub adds it on a public repository that does not yet have an applicable Actions event policy. [1] Private repositories are outside it. Internal repositories are outside it. An applicable event policy already in place stays in place. [1]

Policy insights show which of those runs enforcement would block. [1]

A pull_request_target job receives the base repository's GITHUB_TOKEN and can read repository secrets and organization secrets. [1] GitHub's checkout changelog says these workflows have default-branch cache access. [3] The pull_request_target guide says that cache access is read-only. A workflow or a job can turn that off by declaring a write-capable cache-mode. The page says doing so brings the cache-poisoning risk back. [1] The cache security guide is the longer treatment of that cache. By default, the workflow file comes from the base repository's default branch. An actions/checkout call that does not set ref does too. [1] An unrelated third-party repository input is outside the fork-only refusal. [3]

Fork code is not executed by default. Checkout by itself does not run that code. The bug is finished when a later step executes what a checkout or a fetch brought in: the pull request head, the pull request merge ref, a repository input pointed at the fork, or a fetch outside actions/checkout. That list is not the only way a command runs in this event. The same page also names command injection. [1]

GitHub's name for the resulting bug is a pwn request: checking out an unreviewed fork pull request head inside one of these workflows usually means the fork's code runs with the workflow's privileges. [3] The pull_request_target guide stays the workflow-level writeup. This page is the enforcement date and the repository policy around it.

Labeling and triage are documented uses: GitHub says pull_request_target is useful for automation that answers a fork pull request, and the examples are labeling, triage, and posting authenticated status checks. [1] Keeping the trigger through enforcement means the workflow still needs it and an applicable event policy allows it. [1] The same page says to allow the trigger only when it is necessary. It also says these workflows should not check out, build, or run an untrusted pull request's code when they can read repository secrets or hold a privileged GITHUB_TOKEN. [1]

A SHA pin is outside the July 20 checkout backport

actions/checkout v7 became generally available with the June 18, 2026 changelog. It refuses to fetch fork pull request code during pull_request_target. It also refuses during workflow_run when the workflow run's triggering event is a pull_request* event. [3] The refusal applies when the pull request comes from a fork and any of these inputs match: repository resolves to the fork's repository, ref matches the head form or the merge form GitHub writes as refs/pull/number/head and refs/pull/number/merge, or ref resolves to that fork pull request's head commit or its merge commit. [3]

Same-repository pull requests are unchanged. The pull_request event is unchanged. [3]

A July 15, 2026 editor's note moved checkout backport enforcement from July 16, 2026 to July 20, 2026. [3] Full SHA pins, minor tags, and patch tags are outside that backport. actions/checkout v1 is excluded from the backport. Floating major tags were the pins GitHub said would pick up the change on their own. GitHub says the pins outside the backport need an upgrade, and it names Dependabot or an established upgrade process. [3]

The July 16, 2026 sentence is still in the post body under that note. The editor's note is the revision. The page retrieved September 23, 2026 has no later note saying the July 20, 2026 enforcement finished. A floating major tag was in the plan. A full SHA pin was not.

The SHA pinning guide is how this site treats a full commit pin. November 2, 2026 is the gate for a pull_request_target run only for the cohort in the table above. Private repositories, internal repositories, and a public repository that already has an applicable event policy are outside that default. [1]

Checkout pin scope from the June 18, 2026 post body. The July 15, 2026 note excludes v1 and moves the date. [3]
Pin July 20, 2026 backport
Floating major tag on a supported version other than v1 In the backport plan. GitHub said these tags would pick up the change on their own.
Full SHA, minor tag, or patch tag Outside the backport. The post says a specific SHA, a minor version, or a patch version.
actions/checkout v1 Excluded. The July 15, 2026 note says v1 will not receive the change.
The checkout refusal is narrow: A run step that uses git or gh to pull a head ref, or some other untrusted source that the step then executes, is outside it. An event such as issue_comment is outside it. Checking out an unrelated third-party repository is outside it. [3] GitHub says a privileged event that checks out untrusted code and then executes it is still a pwn request risk. [3] The docs add git fetch, gh pr checkout, and running a downloaded artifact to that uncovered list. [1]

The documented opt-out on the checkout step is allow-unsafe-pr-checkout: true. GitHub's guide says turning that input on permits a checkout of a fork pull request's head ref. The condition is a confirmation that the checked-out code is never executed. The same page says install commands, builds, configuration, and dependencies can run that code, and that this does not require an obvious build step. Before the event is used, that code has to stay data. [1] GitHub chose the input name so a reviewer sees it, and so static analysis sees it too. [1] [3]

Policy insights list the runs enforcement would block

While the default stays in evaluate mode, GitHub's guide says to use policy insights to find pull_request_target workflows that enforcement would stop. [1] The September 17 changelog describes that same Insights pass, then names two outcomes. One is to leave the rule in place to block the trigger once enforcement begins. The other is an explicit allow inside an event policy that applies, if workflows still depend on this trigger. Workflow file targeting can put that allow on named workflow files instead of the whole repository. [2]

The guide splits the per-workflow decision this way. [1]

  • The workflow does not need the trigger. Update the workflow to a safer event where that fits. The guide's example is pull_request. [1]
  • The workflow still needs the trigger. Put this trigger on the allow side of an applicable event policy. Write that policy, or change the one that applies. [1] Workflow file targeting can limit that allow to named workflow files. [2]
  • If pull_request_target is not wanted. Leave the default alone. Once enforcement begins, GitHub blocks runs started by that event. [1]

Related reviews: pull_request_target security, pinning actions to a full SHA, and workflow execution protections.

CI Tripwire Editorial has not commissioned independent expert review of this article. Read more about the organization byline at contributors and the source posture at sourcing.

Corrections can be routed through the corrections note. Sources: 4 entries, all primary GitHub documentation, last reviewed 2026-09-23.

Sources

  1. GitHub Docs, Securely using pull_request_target, retrieved 2026-09-23.
  2. GitHub Changelog, "Workflow execution protections in GitHub Actions generally available", published 2026-09-17.
  3. GitHub Changelog, Safer pull_request_target defaults for GitHub Actions checkout, published 2026-06-18, editor's note 2026-07-15, retrieved 2026-09-23.
  4. GitHub Docs, About Actions policies, retrieved 2026-09-23.