Topic starter
11/06/2026 11:33 pm
TL;DR: A single pull request from a fork can turn GitHub Actions workflows into code execution, token theft, secret exposure, and repository compromise across Microsoft, Google, Nvidia, and others, according to Orca Security. The problem is not the fork itself but the assumption that untrusted pull request code can safely enter privileged workflows.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “pull_request_nightmare Part 2: Exploiting GitHub Actions for RCE and Supply Chain”.
Key questions
Q: What breaks when GitHub Actions workflows run untrusted pull requests with write access?
A: The workflow boundary breaks because attacker-controlled input can execute in a privileged context.
Q: Why do pull_request_target workflows create more risk than standard pull request workflows?
A: pull_request_target runs in the base repository context, which can expose secrets and write-enabled tokens to code that came from a fork.
A: Treat every value derived from artifacts, pull request data, or workflow outputs as untrusted until it has been validated.
Practitioner guidance
- Separate untrusted PR validation from privileged execution Run forked pull requests in workflows that never inherit write permissions, deployment rights, or secrets.
- Constrain pull_request_target by repository origin Gate privileged jobs so they only execute when the pull request comes from the same repository, not from a fork, and avoid checking out untrusted fork content in any trusted context.
- Use environment protections for privileged steps Place sensitive jobs behind required reviewers and protected environments so untrusted contribution paths cannot reach deployment or secret-bearing stages without explicit approval.
Bottom line: Forked pull requests become dangerous when they are allowed into trusted workflow contexts that can execute code or access secrets.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 16 hours ago by NHI Mgmt Group
12/06/2026 8:16 am
Fork trust is a governance control, not a social convention: The article shows that contribution provenance and execution privilege are inseparable once fork content enters a privileged workflow. Treating a fork as merely an untrusted source misses the fact that the runner becomes the identity with authority. Practitioners need to model contribution paths as access paths, because the risk is not the pull request itself but the trusted runtime it can reach.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What should teams do immediately when a forked pull request can access privileged workflow steps?
A: Suspend the privileged path for external contributions, remove write permissions and secrets from the job, and move validation into a separate low-trust workflow before restoring normal operation. The priority is to stop untrusted code from running in a context that can alter repositories or expose credentials.
👉 Read our full editorial: GitHub Actions pwn requests expose the limits of fork trust
This post was modified 16 hours ago by NHI Mgmt Group