GitHub Actions Checkout v7 Blocks Risky pull_request_target Fork Checkouts

GitHub has updated actions/checkout to reduce a common supply chain security risk in GitHub Actions workflows that use pull_request_target incorrectly.

The change, announced in the GitHub Changelog, makes actions/checkout v7 refuse common unsafe fork pull request checkout patterns by default. The goal is to stop workflows from accidentally running attacker-controlled pull request code with elevated privileges.

The issue is known as a “pwn request” pattern. It happens when a privileged workflow checks out and executes code from an untrusted forked pull request, while still having access to the base repository’s token, secrets, cache scope, and runner environment.

Why pull_request_target Can Be Dangerous

The pull_request_target event exists for legitimate automation. It lets a workflow run in the context of the base repository, which helps maintainers label pull requests, comment on reviews, run policy checks, or perform other trusted actions.

The danger begins when that same workflow checks out the pull request branch from an outside fork and runs scripts from it. GitHub’s secure use guidance warns that pull_request_target and workflow_run are privileged triggers and should not explicitly check out untrusted code.

The GitHub Security Lab has warned for years that combining pull_request_target with explicit checkout of untrusted pull request code can expose repository secrets or give attackers write access through the workflow’s GITHUB_TOKEN.

Workflow pattern	Risk level	Reason
pull_request with fork code and limited permissions	Lower	Designed for untrusted pull request testing with restricted access
pull_request_target without checking out fork code	Moderate	Privileged event, but safer when it only uses trusted base repository code
pull_request_target checking out fork PR code	High	Can run attacker-controlled code with base repository privileges
workflow_run executing untrusted artifacts or fork code	High	Can turn a two-stage workflow into a privileged execution path

What actions/checkout v7 Changes

The new actions/checkout v7 release refuses to fetch fork pull request code by default when the workflow runs under pull_request_target. It also applies to workflow_run jobs when workflow_run.event is a pull_request-style event.

GitHub says the action now fails when a fork pull request workflow clearly tries to check out the fork’s repository, the pull request head ref, the pull request merge ref, or the fork PR’s head or merge commit SHA.

This means several patterns that previously looked normal in workflow files will now fail in privileged workflows when the pull request comes from a fork.

• ref values that match refs/pull/<number>/head
• ref values that match refs/pull/<number>/merge
• ref values that use github.event.pull_request.head.sha
• repository values that point to github.event.pull_request.head.repo.full_name
• workflow_run jobs that try to fetch fork PR code after a pull request workflow

GitHub Will Backport the Protection in July

actions/checkout v7 is already generally available. GitHub also plans to backport the enforcement to all currently supported major versions on July 16, 2026.

That matters because many workflows use floating major tags such as actions/checkout@v4. According to the GitHub Changelog, those workflows will automatically inherit the safer behavior once the backport lands.

Workflows pinned to a specific commit SHA, minor version, or patch version will not pick up the change automatically. Those maintainers need to update their workflows through Dependabot, internal dependency management, or manual review.

Workflow reference	Will it receive the backport automatically?
actions/checkout@v4	Yes, because it uses a floating major tag
actions/checkout@v5	Yes, if v5 remains a supported major version
actions/checkout@v7	Already includes the new default behavior
actions/checkout pinned to a full commit SHA	No, maintainers must update it manually or through automation
actions/checkout pinned to a minor or patch version	No, maintainers must upgrade to receive the protection

What the Update Does Not Block

The update targets the most common unsafe checkout patterns, but it does not eliminate every possible pwn request risk.

A workflow can still become vulnerable if it uses a run block to call git or the GitHub CLI and manually fetch untrusted code. GitHub also says the new protection does not block pwn request patterns triggered by other events, such as issue_comment.

The change also does not stop maintainers from checking out unrelated third-party repositories. If a privileged workflow checks out and runs any untrusted code, teams still need to review that design carefully.

Opt-Out Is Available, But GitHub Makes It Explicit

Some projects have legitimate reasons to test fork pull request code while using elevated access. Examples include coverage jobs that need a private package registry or authenticated checks that must run against incoming changes.

For those cases, actions/checkout now includes an allow-unsafe-pr-checkout input. Maintainers can set it to true after reviewing the risk and confirming that the privileged checkout is truly required.

The input name is intentionally direct. It makes the decision visible during code review and easier for security scanners to find.

Why This Matters for Supply Chain Security

GitHub Actions workflows often sit in sensitive parts of the software supply chain. They can build packages, publish releases, deploy cloud infrastructure, sign artifacts, and access production credentials.

The OpenSSF has warned that privileged triggers combined with untrusted code can let attackers steal secrets, push code, compromise release artifacts, or poison workflow caches. The same risk applies when a workflow runs attacker-controlled pull request code in a trusted context.

Because GitHub Actions is widely used across open-source and enterprise projects, a single unsafe workflow can become a path to a broader supply chain compromise. GitHub’s change reduces the chance that maintainers accidentally create that path with actions/checkout.

Recommended Workflow Design

The safest design is to separate untrusted code execution from privileged automation. Test code from outside forks under pull_request with restricted permissions, then use a second trusted workflow only for actions that need elevated access.

GitHub’s security hardening documentation recommends limiting token permissions, avoiding untrusted code checkout in privileged workflows, using CodeQL to detect risky workflow patterns, and keeping actions up to date.

The pwn request guidance also recommends treating external pull requests as untrusted input. Attackers can place malicious behavior in build scripts, test files, package scripts, or any code path the workflow executes.

• Use pull_request for testing untrusted fork code.
• Use pull_request_target only when the workflow truly needs base repository privileges.
• Do not check out fork pull request code inside privileged workflows.
• Set GITHUB_TOKEN permissions to the minimum required scope.
• Use separate workflows for untrusted tests and trusted comments or labels.
• Review any use of allow-unsafe-pr-checkout before merging.
• Update SHA-pinned checkout steps through Dependabot or internal tooling.

What Maintainers Should Review Now

Maintainers should search their workflow files for pull_request_target, workflow_run, refs/pull, github.event.pull_request.head.sha, and github.event.pull_request.head.repo.full_name. These patterns can reveal workflows that may break after the checkout update or that already carry security risk.

Teams should also review workflow permissions. The OpenSSF workflow guidance recommends restricting token permissions and splitting privileged and unprivileged jobs when working with external contributions.

The update improves the default behavior of one widely used action, but it does not replace secure workflow design. Repositories that accept outside contributions should still treat pull request code, titles, descriptions, comments, artifacts, and generated files as untrusted input.

FAQ