"Running untrusted code on the pull_request_target trigger may lead to security vulnerabilities," GitHub notes in its documentation.
GitHub's actions/checkout v7: a default refusal on risky fork checkouts
Effective June 18, 2026, the official GitHub action actions/checkout was updated to refuse common pwn request patterns by default. The change, delivered in actions/checkout v7, is intended to stop workflows from accidentally fetching and running attacker-controlled code when they are triggered by pull_request_target or certain workflow_run events. GitHub plans to backport the behavior to all currently supported major versions on July 16, 2026.
According to the release notes, "Actions/checkout v7 refuses to fetch fork pull request code in pull_request_target and workflow_run workflows (the latter only when workflow_run.event is a pull_request* event)." When the refusal conditions are met, checkouts of a forked pull request's head or merge commit will fail rather than deliver untrusted code into a privileged runner.
The pull_request_target trigger and pwn request attacks
The change addresses a specific attack pattern known in the Actions ecosystem as a "pwn request." Pull_request_target workflows run automatically when a pull request is opened, reopened, or when the head branch is updated, and they run in the context of the base repository's default branch. Those workflows therefore have access to the repository's secrets and a GITHUB_TOKEN with read and write permissions.
GitHub warns that combining pull_request_target with actions/checkout so the workflow checks out the pull request head can let attacker-controlled code execute with the workflow's full privileges. "Workflows triggered by pull_request_target run with the base repository's GITHUB_TOKEN, secrets, and default-branch cache access," the documentation states. The practical consequence: a malicious forked pull request that is checked out and executed inside a pull_request_target workflow can lead to cache poisoning, disclosure of secrets, or unintended write privileges being used by an attacker.
The source documents that in recent months, multiple supply-chain incidents have exploited this behavior — including compromises of packages associated with the Nx build system in a campaign codenamed s1ngularity, and breaches of PostHog, TanStack, and the Emacs package "kubernetes-el/kubernetes-el."
Exact criteria that trigger refusal — and the opt-out
Actions/checkout will refuse to fetch fork pull request code when the pull request originates from a fork and any of these conditions is true, unless a workflow author explicitly opts out by setting the allow-unsafe-pr-checkout flag to true:
- repository resolves to the fork pull request's repository
- ref matches refs/pull/number/head or refs/pull/number/merge
- ref resolves to a fork pull request's head or merge commit SHA
When those criteria are met, actions/checkout v7 will fail for pull_request_target events from forks that provide these "insecure inputs." Authors who understand and accept the risk can override the protection with allow-unsafe-pr-checkout=true, but the default is to refuse the checkout.
Scope and limits: Socket and the guardrail distinction
The Microsoft-owned subsidiary identified in the release notes as Socket emphasized that this update is narrowly scoped. "This change only blocks checkouts of the fork pull request head and merge commits," Socket said. It does not block checkouts of other untrusted repositories, for example when repository: is set to an unrelated third-party repository.
Socket framed the modification as a guardrail rather than a complete solution. "The protection in this update only covers checkouts performed through actions/checkout," it stated. Workflows that run with secrets, write permissions, deployment permissions, or OIDC publishing access still require careful review because checking out and executing any untrusted code in a privileged event remains a pwn request risk. The update also omits other event types and techniques: pwn requests triggered via other events (for example, issue_comment) or performed using git or the GitHub CLI are out of scope.
What this means for developers, security teams, and open-source maintainers
Developers: If your workflows do not need elevated permissions or access to secrets, swap pull_request_target for pull_request to avoid privileged execution of untrusted code. Where pull_request_target is required, audit uses of actions/checkout and avoid allowing checkouts of fork heads or merge commits unless you intentionally opt out.
Security teams: Treat this update as a practical guardrail to reduce the most common pwn request vector, but not a panacea. Continue to restrict workflow permissions, minimize secrets and token scopes, and review any workflow that runs with write or deployment privileges.
Open-source maintainers: The change will cause failing workflows for some forked pull requests until authors either alter inputs or explicitly opt out. Maintain clear contributor guidance: explain why a checkout may be refused, when it's safe to opt out, and when contributors should open changes on branches in the base repository instead of from forks.
GitHub's actions/checkout v7 narrows a well-known attack surface by defaulting to safer behavior for forked pull requests in privileged workflows. It lowers the immediate risk of the common pwn request pattern — while leaving developers and maintainers with a practical choice: accept a stricter default that blocks convenience in some contributor workflows, or deliberately opt out and retain prior behavior. The update reduces a frequent footgun; it does not remove the need for careful workflow design and permissions hygiene.
