GitHub has rolled out a significant security enhancement to GitHub Actions by updating actions/checkout to block unsafe workflows that abuse the pull_request_target event.

The pull_request_target trigger is widely known as one of the most misused events because it runs with the base repository’s GITHUB_TOKEN, secrets, and default-branch cache access, even when the pull request comes from an untrusted fork.

When maintainers check out the head or merge commit of a forked pull request in this context, attacker-controlled code can run with full CI privileges, a pattern referred to as a “pwn request” that has driven multiple supply-chain compromises across the ecosystem.

To reduce this risk, GitHub has made actions/checkout v7 generally available with secure-by-default behavior designed to stop the most common pwn request patterns.

GitHub Checkout Update Disrupts Workflows

On July 16, 2026, GitHub will backport this enforcement logic into all currently supported major versions, so workflows pinned to floating tags like actions/checkout@v4 will automatically inherit the safer defaults without any manual change.

Pipelines that pin actions/checkout to a specific SHA, minor, or patch version will not be updated automatically and must be upgraded via Dependabot or established internal processes to benefit from the new protections.

Same-repository pull requests are unaffected, and the traditional pull_request event behavior remains unchanged, ensuring standard contribution workflows continue as usual.

The key change is that actions/checkout v7 now refuses to fetch fork pull request code in pull_request_target workflows and in workflow_run jobs where workflow_run.event is a pull_request* event, whenever the configuration clearly targets a fork PR.

The action fails if the repository input resolves to the fork’s repository, if ref matches refs/pull/<number>/head or refs/pull/<number>/merge, or if ref resolves to the fork PR’s head or merge commit SHA.

This update blocks insecure GitHub Actions patterns such as refs/pull/${{ github.event.pull_request.number }}/merge, ref: ${{ github.event.pull_request.head.sha }}, and repository: ${{ github.event.pull_request.head.repo.full_name }} in privileged workflows.

It prevents untrusted pull request code from reaching jobs that execute sensitive commands like run: ./scripts/deploy.sh, which may have access to secrets and production resources.

Under the new behavior, these workflows fail early instead of silently executing attacker-controlled code. GitHub stresses that the update is focused on the most prevalent misuse and does not claim to eliminate every variant of pwn requests.

Workflows remain vulnerable if they manually pull and execute untrusted code using run blocks that call git or the gh CLI to fetch arbitrary refs or repositories, since those operations bypass actions/checkout entirely.

Unsafe patterns triggered by other events, such as issue_comment, also remain out of scope for this change. However, GitHub may expand hardening to additional event types in the future.

The new logic specifically blocks fork PR head and merge checkouts but does not prevent checkouts of other untrusted repositories, meaning any design that executes code from untrusted sources in privileged events still requires careful review and threat modeling.

For legitimate use cases where fork PR code must run with elevated trust, for example, coverage generation using private artifact registries or authenticated checks on incoming changes, GitHub offers an explicit opt-out path.

After reviewing the official guidance on securely using pull_request_target, maintainers can add the allow-unsafe-pr-checkout input to the actions/checkout step to re-enable fork PR checkouts in these workflows.

The input name is intentionally loud and descriptive so that its presence is obvious during code review and static analysis, reinforcing that turning off the default protection is a conscious, high-impact security decision.

In practice, security-focused teams are encouraged to run untrusted forks under pull_request with restricted permissions and to reserve pull_request_target and any unsafe checkouts only for carefully audited pipelines that truly require access to secrets and sensitive resources.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates.