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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Orca Security's research: Fork-based pull requests can abuse privileged GitHub Actions workflows to execute code, expose secrets, and compromise repositories.
Why it matters: IAM and DevSecOps teams need to treat workflow trust boundaries as identity boundaries because untrusted contribution paths can inherit write access, token scope, and deployment reach.
Context
GitHub Actions workflows become a governance problem when untrusted pull request content can reach privileged execution paths. In this case, the article argues that pull_request_target can turn a contribution workflow into a high-trust runtime if maintainers check out fork code or grant write permissions too broadly.
For identity teams, the issue is not simply CI/CD hygiene. It is delegated access control across repositories, runners, tokens, and secrets, where the workflow runner behaves as an identity with effective power over code, packages, and cloud assets.
The examples in the article show that the same pattern can affect major repositories as well as smaller projects, which makes the risk architectural rather than exceptional.
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. That lets an untrusted contribution inherit repository rights, secret access, or release permissions that should never be available during validation. The result is token leakage, unauthorized repository actions, or both, especially when pull_request_target is combined with broad permissions.
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. That makes it suitable for metadata tasks, but risky for any workflow that executes contributor-controlled code or checks out the pull request head.
A: Treat every value derived from artifacts, pull request data, or workflow outputs as untrusted until it has been validated. Never write that input directly into environment files or shell commands. Use the narrowest possible token permissions, prefer workflow outputs over environment variables, and add fork and human approval checks for workflows that can reach sensitive repositories or deployment steps.
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.
Technical breakdown
Why pull_request_target changes the trust boundary
pull_request_target runs in the context of the target repository, not the fork, so its default trust assumptions are much stronger than a normal pull_request workflow. If the job checks out fork content or executes modified scripts, the forked code inherits access to repository secrets, write-scoped tokens, and privileged automation steps. That is why the article describes reverse-shell execution and repository writes from what appears to be a routine contribution path. The security issue is not GitHub Actions itself, but the decision to mix untrusted input with trusted execution context.
Practical implication: separate untrusted contribution validation from privileged repository actions and keep fork code out of trusted runner contexts.
How runner tokens and write permissions become the abuse path
The article shows that a GitHub Actions runner can receive a GITHUB_TOKEN with read and write permissions when workflow configuration is too permissive. Once attacker-controlled code executes, that token becomes enough to push branches, modify repository state, create deployments, or access other workflow-connected assets. In the Google example, the same job also exposed a Gemini API key, showing how build-time credentials and workflow permissions can combine into a wider identity blast radius. This is a classic privilege amplification problem inside an automation pipeline.
Practical implication: inventory every workflow token, narrow its scope, and assume any writable runner context can be turned into a repository compromise.
Why reusable workflows and scripts widen supply chain exposure
Reusable workflows and helper scripts make the attack path easier to miss because the sensitive action may sit several layers away from the original trigger. The article’s Microsoft and Nvidia examples show that a single checkout or script change can cascade into remote code execution, branch creation, cloud token access, or lateral movement in connected environments. In identity terms, this is delegated authority without enough verification at each hop. The workflow chain acts like a supply chain for trust, and the weakest step defines the attack surface.
Practical implication: review every reusable workflow, script call, and runner permission as part of one supply chain control surface, not as isolated jobs.
Threat narrative
Attacker objective: The attacker wants trusted workflow execution to become a bridge into repository control, secret exposure, and broader software supply chain compromise.
- Entry occurs through a forked pull request that is accepted by a workflow using pull_request_target and an unsafe checkout pattern.
- Credential access follows when attacker-controlled workflow code reaches the runner’s GITHUB_TOKEN, repository secrets, or embedded API keys.
- Escalation happens as the token is used to push branches, modify workflow logic, create deployments, or pivot into connected cloud and build assets.
- Impact includes source code compromise, secret exposure, malware delivery, lateral movement, and downstream supply chain abuse.
Breaches seen in the wild
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Trusted workflow context is the real blast-radius multiplier: When a workflow runs with write-scoped tokens, secrets, or deployment permissions, a single code path can cross repository, CI/CD, and cloud boundaries in one step. That is why this pattern belongs in OWASP-NHI thinking even though the subject is GitHub Actions, because the machine identity and its privileges are the asset under abuse. The right question is how much authority the workflow inherits, not whether the contributor is external.
Privilege review for automation needs contribution-aware controls: Standard access reviews assume a stable identity and a stable entitlement. Fork-based workflow abuse shows that those assumptions fail when the identity is an ephemeral runner executing untrusted input under inherited privileges. The implication is not just to add controls, but to rethink where the authority boundary sits in CI/CD and who is allowed to cross it.
Identity blast radius is now a software delivery metric: The Microsoft, Google, and Nvidia examples show that workflow misconfiguration can turn source control into a launch point for branch tampering, secret theft, and cloud compromise. That makes workflow permission design part of identity governance, not just developer convenience. Security teams should measure how far one compromised workflow can travel across code, secrets, and deployments.
Safe-by-default pull requests require explicit deny-by-context design: The article makes clear that the dangerous state is not an exotic exploit chain but a common trust misalignment between trigger type, checkout behavior, and token scope. In practice, this means keeping untrusted PR validation and privileged repository automation in separate control planes. The field should treat pwn requests as a permanent governance pattern, not a one-off GitHub quirk.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Identity blast radius now includes the CI/CD runner: When a workflow runner can write to the repository, expose secrets, and trigger deployments, the runner is effectively acting as a privileged non-human identity. That means CI/CD governance needs the same scrutiny usually reserved for service accounts and cloud automation, especially where untrusted code can reach the job context.
The governance question is no longer whether a workflow is automated, but whether its trust boundary matches the privilege it inherits. In practice, teams should expect fork-based contribution paths to remain a durable abuse pattern wherever pull_request_target, broad tokens, and unchecked script execution still coexist.
For practitioners
- Separate untrusted PR validation from privileged execution Run forked pull requests in workflows that never inherit write permissions, deployment rights, or secrets. Keep any job that can modify repository state away from code coming from external contributors.
- 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.
- Audit reusable workflows and script checkout paths Review every workflow that calls reusable jobs or executes scripts from the checked-out tree, because the trust break often sits one layer away from the trigger that looks risky.
- Reduce token scope and secret exposure in runners Replace broad GITHUB_TOKEN permissions with the minimum required scope, and keep API keys or cloud credentials out of jobs that process external pull requests.
Key takeaways
- Forked pull requests become dangerous when they are allowed into trusted workflow contexts that can execute code or access secrets.
- The article’s examples show that the same misconfiguration can lead to branch tampering, secret exposure, and cloud or supply chain compromise.
- The control failure is not the existence of GitHub Actions, but the lack of boundary separation between untrusted input and privileged automation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Forked PR workflows let external contributors abuse trusted automation. |
| NHI-05 — Overprivileged NHI | The article centers on workflows and runners inheriting write access beyond need. | |
| NHI-07 — Long-Lived Secrets | The examples show secrets and tokens being exposed from trusted runner contexts. | |
| Recommendation — Treat external contribution paths as third-party NHI trust boundaries and isolate them from privileged execution. Reduce workflow and runner privileges to the minimum required for each job. Keep secrets out of jobs that process external code and rotate any exposed credentials immediately. | ||
| MITRE ATT&CK | TA0006;TA0008;TA0004 — Credential Access; Lateral Movement; Privilege Escalation | The article describes token theft, repo compromise, and movement into connected systems. |
| Recommendation — Map vulnerable workflow paths to credential access, privilege escalation, and lateral movement detections. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Workflow permissions and token scopes are the core control boundary in this article. |
| Recommendation — Review workflow entitlements so external PRs cannot inherit write or deployment authorizations. | ||
| CIS Controls v8 | CIS-5 — Account Management | The abuse path depends on how tokens and automation accounts are provisioned and scoped. |
| Recommendation — Audit automation accounts and revoke unnecessary rights from CI/CD identities. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The workflow token and secret handling failures resemble broken authentication in automation paths. |
| Recommendation — Validate that automation tokens cannot authenticate untrusted input to privileged actions. | ||
Key terms
- Pull Request Trust Boundary: The point at which untrusted contributor input crosses into a workflow or system that can execute privileged actions. In GitHub Actions, this boundary determines whether forked code can influence secrets, deployment steps, or repository writes. Treating it as explicit identity scope is essential to preventing abuse.
- Session Token Exposure: Session token exposure occurs when authentication tokens or session artifacts are stored, transmitted, or logged in places they should not be. Once exposed, they can function like reusable credentials. This makes them part of identity and access risk, not only application behaviour.
- Ephemeral Runner: A disposable build executor that exists only for a single job or short-lived task. Ephemeral runners reduce the chance that credentials, state, or malicious changes persist across builds, which makes them a key control for pipeline isolation and supply chain resilience.
- Trusted Execution Environment: A Trusted Execution Environment is a protected hardware-backed area where code runs with stronger isolation from the host system. In AI inference, the point is not just secrecy in transit, but limiting what operators, hypervisors, and surrounding infrastructure can observe during processing.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org