GitHub is moving to strengthen software supply chain security by updating “actions/checkout” to block pwn request attacks that exploit the risky use of the “pull_request_target workflow” trigger to run malicious code with the workflow’s full privileges.
Effective June 18, 2026, the latest version of “actions/checkout,” the official GitHub action for checking out a repository into the workflow’s runner, refuses common pwn request patterns by default. The change is expected to be backported to all currently supported major versions on July 16, 2026.
“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),” it added.
The refusal occurs when the pull request is from a fork, and any of the following criteria is met, unless workflow authors explicitly opt out of it by setting the “allow-unsafe-pr-checkout” flag to “true” in “actions/checkout” –
- repository: resolves to the fork pull request’ 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
The change is aimed at preventing the most common form of pwn requests in the Actions ecosystem. As a result, “actions/checkout” will fail for “pull_request_target events” from forks with insecure inputs.
“Pull_request_target” is a workflow trigger that’s automatically run without requiring manual approval when a pull request is opened or reopened, or when the head branch of the pull request is updated. It’s important to note that the event runs in the context of the default branch of the base repository, potentially exposing secrets and a privileged GITHUB_TOKEN with both read and write permissions.
“Running untrusted code on the pull_request_target trigger may lead to security vulnerabilities,” GitHub notes in its documentation. “These vulnerabilities include cache poisoning and granting unintended access to write privileges or secrets.”
The danger arises when a “pull_request_target” is combined with “actions/checkout” to download and execute code submitted by an untrusted fork. Should a bad actor submit a pull request containing malicious scripts and the workflow checks out and runs the code, it can allow the attacker to steal the GITHUB_TOKEN and other secrets, leading to what’s called a pwn request attack.
“Workflows triggered by pull_request_target run with the base repository’s GITHUB_TOKEN, secrets, and default-branch cache access,” GitHub said. “Checking out the head of an unreviewed pull request from a fork inside one of these workflows typically lets attacker-controlled code execute with the workflow’s full privileges.”
In recent months, a number of software chain attacks have weaponized this behavior. The most severe of them was the compromise of multiple packages associated with the Nx build system as part of a campaign codenamed s1ngularity, as well as the breach of PostHog, TanStack, and the popular Emacs package, “kubernetes-el/kubernetes-el.”
“Pull_request_target was designed for trusted automation around pull requests, such as labeling, commenting, or applying project metadata,” Socket said. “But the checkout step controls which code actually lands in the runner workspace. If it pulls code from a forked pull request, the workflow can end up running attacker-controlled code with the base repository’s privileges.”
That said, the Microsoft-owned subsidiary emphasized that pwn requests triggered via other event types besides pull_request_target (e.g., issue_comment) or through other means, such as git or the GitHub CLI, are out of scope of this change.
“This change only blocks checkouts of the fork pull request head and merge commits,” it added. “It does not block checkouts of other untrusted repositories. For example, setting repository: to an unrelated third-party repository is not blocked. Checking out and executing any untrusted code in a privileged event remains a pwn request risk that should be reviewed.”
To counter the risk posed by “pull_request_target,” developers are advised to assess and use it only when necessary, switch to “pull_request” if the workflow does not require elevated permissions or access to secrets, restrict permissions granted to the workflows, and ensure user-controlled input does not result in execution of untrusted code.
“The protection in this update only covers checkouts performed through actions/checkout,” Socket said. “That makes this a guardrail, not a complete solution for Actions security. Workflows that run with secrets, write permissions, deployment permissions, or OIDC publishing access still need careful review.”
