Overview
GitHub has introduced an important security update to its widely used actions/checkout workflow component, aimed at reducing the risk of a software supply chain attack technique known as a Pwn Request.
The change focuses on preventing developers from unintentionally executing untrusted code from forked repositories within privileged GitHub Actions workflows. While the update adds a valuable security guardrail, GitHub has made it clear that it is not a complete solution and secure workflow design remains essential.
For organisations building software through GitHub Actions, this update is a timely reminder to review workflow permissions and understand how code from external contributors is handled.
Understanding the Risk
The vulnerability centers around the pull_request_target workflow trigger.
Unlike a standard pull_request event, pull_request_target runs with access to:
- Repository secrets
- Privileged GITHUB_TOKEN permissions
- Default branch cache access
- Write permissions in some environments
This makes it useful for trusted automation tasks such as:
- Labelling pull requests
- Applying metadata
- Automated reviews
- Repository management
The problem occurs when developers combine pull_request_target with actions/checkout and automatically download code submitted from an untrusted fork.
If that code contains malicious scripts, attackers can potentially execute code with the same permissions as the workflow itself.
What GitHub Changed
Beginning with actions/checkout v7, GitHub now blocks common Pwn Request patterns by default.
The action will refuse to check out forked pull request code when:
- The repository resolves to a forked pull request repository.
- The workflow references pull request head commits.
- The workflow references pull request merge commits.
- The event is considered a high-risk privileged workflow scenario.
Developers can override the protection using the:
allow-unsafe-pr-checkout: true
setting, although GitHub strongly recommends reviewing the security implications before doing so.
The protection will also be backported to currently supported versions of actions/checkout.
Why This Matters
Pwn Request attacks have become an increasingly attractive technique for threat actors targeting software supply chains.
By exploiting insecure workflow configurations, attackers can gain access to:
- Source code
- Deployment credentials
- Package publishing tokens
- Cloud credentials
- CI/CD infrastructure
Several notable software supply chain incidents have leveraged similar workflow weaknesses, impacting open-source projects and software vendors alike.
The challenge is that the workflow itself may appear completely legitimate while silently executing attacker-controlled code.
What This Doesn’t Protect Against
GitHub has been careful to position this update as a security safeguard rather than a complete fix.
The new protection only applies to code checked out using actions/checkout.
It does not prevent:
- Unsafe Git operations performed manually
- GitHub CLI checkouts
- Other workflow triggers
- Checkouts from unrelated third-party repositories
- Poorly configured privileged workflows
Developers should therefore view the update as an additional layer of protection rather than a replacement for secure workflow design.
Defensive Recommendations
Development and DevSecOps teams should consider the following:
- Use pull_request instead of pull_request_target whenever possible.
- Restrict workflow permissions to the minimum required.
- Review workflows that have access to secrets.
- Limit write permissions for GITHUB_TOKEN.
- Avoid executing code from untrusted repositories.
- Audit GitHub Actions workflows regularly.
- Monitor CI/CD environments for unusual activity.
Security teams should also review repositories that accept contributions from external users, as these environments are often the most exposed to this type of attack.
Expert in the Cloud Insight
This update highlights a growing reality in cybersecurity: attackers are increasingly targeting the software delivery pipeline rather than the software itself.
Modern development environments contain secrets, deployment credentials, cloud access tokens, and automation workflows that can be just as valuable as a production server.
GitHub’s latest change is a welcome improvement, but it also reinforces an important lesson. Security controls should not depend on a single safeguard. Secure software delivery requires layered protection, least privilege, continuous review, and a clear understanding of how trust flows through the CI/CD process.
As organisations accelerate software delivery, the security of the build pipeline is becoming just as important as the security of the application being built.
Expert in the Cloud – The Future Is Now
Leave a Reply