GitHub has introduced a significant security enhancement to its Actions platform by updating actions/checkout, the official action used to check out repositories into workflow runners. The update is designed to block common pwn request attack patterns that exploit insecure uses of the pull_request_target workflow trigger. Effective June 18, 2026, actions/checkout version 7 now refuses certain risky checkout operations by default, reducing the likelihood of malicious code execution in privileged workflow environments. GitHub also confirmed that the protection will be backported to all currently supported major versions on July 16, 2026.
According to GitHub, actions/checkout v7 will refuse to fetch code from forked pull requests in pull_request_target and workflow_run workflows when the workflow_run event originates from a pull_request related event. The protection is triggered when a pull request originates from a fork and specific conditions are detected. These include situations where the repository parameter resolves to the forked pull request repository, where the reference matches refs/pull/number/head or refs/pull/number/merge, or where the reference resolves to the forked pull request’s head or merge commit SHA. Workflow maintainers can still bypass the restriction by explicitly setting the allow-unsafe-pr-checkout flag to true, although GitHub is encouraging developers to avoid insecure configurations whenever possible. As a result of this change, workflows using pull_request_target events with unsafe checkout patterns from forks will now fail by default.
The move addresses one of the most common attack techniques affecting GitHub Actions environments. The pull_request_target trigger automatically runs when a pull request is opened, reopened, or updated, and it executes within the context of the base repository’s default branch. This means workflows can access repository secrets, caches, and a privileged GITHUB_TOKEN that often includes write permissions. Security concerns arise when actions/checkout is used to download and execute code submitted through an untrusted fork. In such scenarios, attackers can introduce malicious scripts into a pull request and potentially gain access to sensitive credentials or repository resources. This type of compromise is widely known as a pwn request attack because it allows attacker controlled code to run with the same privileges granted to the workflow. GitHub has repeatedly warned that running untrusted code through pull_request_target workflows can result in vulnerabilities such as cache poisoning, unintended exposure of secrets, and unauthorized write access.
Recent software supply chain incidents have highlighted the impact of these risks. Several attacks have leveraged this behavior to compromise development environments and open source projects. Among the most notable examples were the compromise of multiple packages associated with the Nx build system during the s1ngularity campaign, along with breaches affecting PostHog, TanStack, and the widely used Emacs package kubernetes-el/kubernetes-el. Security company Socket noted that while pull_request_target was originally intended for trusted automation tasks such as labeling pull requests, posting comments, and applying project metadata, the checkout process determines what code is actually executed within the runner environment. If forked pull request code is checked out and executed, workflows may inadvertently grant attackers access to elevated privileges belonging to the base repository.
GitHub emphasized that the update specifically targets checkouts performed through actions/checkout and does not address all possible pwn request scenarios. Attack techniques using other event types, including issue_comment, or methods involving direct Git commands or GitHub CLI operations remain outside the scope of this protection. The company also noted that the update only blocks checkouts of fork pull request head and merge commits and does not prevent workflows from checking out other untrusted third party repositories. Developers are encouraged to evaluate whether pull_request_target is truly necessary, use pull_request workflows when elevated permissions are not required, limit workflow permissions wherever possible, and ensure that user controlled input cannot lead to the execution of untrusted code. GitHub and security researchers stress that while the new checkout restrictions provide an important safeguard, workflows that handle secrets, deployment permissions, write access, or OIDC publishing capabilities still require careful security review.
Follow the SPIN IDG WhatsApp Channel for updates across the Smart Pakistan Insights Network covering all of Pakistan’s technology ecosystem.
