GitHub Actions pull_request_target misuse turns forks into RCE

At a glance

What this is: Orca Security shows that unsafe GitHub Actions workflow design can turn a forked pull request into privileged code execution, secret exposure, and repository compromise.

Why it matters: For IAM, PAM, and NHI teams, this is a reminder that pipeline identities and GitHub tokens need the same lifecycle, scope, and approval discipline as any other privileged non-human access.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes

👉 Read Orca Security's research on GitHub Actions pull_request_target abuse

Context

GitHub Actions workflows become an identity risk when they run untrusted code in a privileged repository context. In this case, the key problem is not source control itself but the misuse of pull_request_target, which can expose secrets and write-capable tokens to code that originated outside the trust boundary.

For NHI governance, GitHub tokens, repository secrets, and self-hosted runners are all machine identities with attached privilege. If those identities can be exercised by forked pull requests without strict approval gates, the CI/CD pipeline becomes an access path into source, packages, and downstream cloud resources.

The article’s central finding is typical of a wider pattern in software supply chain risk: the workflow trigger is legitimate, but the trust model is not. Teams that treat build automation as low-risk infrastructure often discover that pipeline identities have broader reach than the application they support.

Key questions

Q: How should security teams handle forked pull requests in GitHub Actions?

A: Security teams should assume forked pull requests are untrusted until proven otherwise. Run them in isolated, read-only workflows with no secrets, no write tokens, and no access to deployment or package publication steps. Reserve privileged jobs for protected branches and reviewed changes only.

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.

Q: What breaks when CI/CD workflows can run untrusted code with privileged tokens?

A: The trust boundary breaks. Once untrusted code runs with repository secrets or a write-capable token, attackers can steal credentials, alter branches, poison packages, or persist through workflow changes. At that point, the pipeline becomes a supply chain entry point rather than a control point.

Q: Who should own GitHub Actions workflow governance in an enterprise?

A: Ownership should be shared across security, IAM, platform engineering, and application teams. Security defines the control baseline, IAM governs token scope and lifecycle, platform teams standardise runner and workflow patterns, and application owners approve the exceptions tied to their repositories.

Technical breakdown

Why pull_request_target changes the trust boundary

GitHub Actions separates the event that starts a workflow from the code the workflow later executes. The pull_request_target trigger runs in the base repository context, so it can access repository secrets and often receives a write-capable GITHUB_TOKEN. That is useful for safe metadata tasks such as labeling, but dangerous if the workflow checks out code from the pull request head and runs it. In that case, attacker-controlled code inherits the base repository’s privilege model rather than the fork’s limited context.

Practical implication: restrict pull_request_target to non-executable tasks and review every checkout step that references pull request head content.

How secrets and write-enabled tokens get abused in CI/CD

A privileged workflow runner can read repository secrets, push commits, modify pull requests, upload packages, or alter branch state depending on token scope. Once untrusted code executes inside that job, any secret visible to the job is reachable, and any write permission becomes a potential persistence mechanism. Self-hosted runners increase the blast radius because they may sit closer to internal tooling, cloud credentials, or private network access than GitHub-hosted runners.

Practical implication: remove broad token scopes, isolate runner classes, and separate secret-bearing jobs from any job that processes untrusted contributions.

Why misconfigured workflows become supply chain compromise

The supply chain impact comes from chaining small mistakes: an unsafe trigger, an overly broad token, an exposed secret, and a deployment path that trusts repository state. None of those flaws alone guarantees compromise, but together they let an attacker move from a forked pull request to code injection, package poisoning, or branch control. In identity terms, the workflow identity is being allowed to act as though it were a trusted maintainer identity.

Practical implication: model CI/CD workflow identities as privileged non-human identities and apply least privilege, approval, and offboarding controls accordingly.

Threat narrative

Attacker objective: The attacker seeks privileged access to the repository workflow context so they can steal secrets, alter trusted code paths, and persist in the supply chain.

1. Entry occurs through a forked pull request that reaches a workflow triggered by pull_request_target in the base repository context.
2. Escalation happens when the workflow checks out and executes attacker-controlled code with repository secrets and a write-capable token.
3. Impact follows when the attacker uses that access to exfiltrate secrets, modify branches, push malicious code, or abuse package and PR permissions.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

GitHub Actions workflow identities must be governed like privileged NHIs, not treated as incidental automation. The article shows that a repository token, a self-hosted runner, and a secrets-bearing job together function as an identity stack with real blast radius. When that stack is reachable from untrusted pull request content, the issue is not just misconfiguration but over-trusted non-human access. Practitioners should treat workflow identities as first-class governed assets.

pull_request_target is a trust-boundary exception, not a default execution mode. It was designed for metadata operations that need base-repository permissions, not for running code supplied by a contributor. The failure mode is clear: the workflow context becomes privileged before the code being executed has been trusted. Teams that normalize this trigger in build pipelines are encoding a standing privilege pattern into source control.

Secrets exposure in CI/CD is a lifecycle problem as much as a configuration problem. A secret that can be read by an untrusted workflow has effectively lost its intended lifecycle boundary, even if it remains technically valid. The same applies to older broad-scope tokens and legacy repositories that never adopted finer-grained permissions. This is a classic identity governance gap where access outlives the trust decision that justified it.

Forked pull requests create an identity blast radius that crosses source, packages, and deployment control planes. Once a privileged job can write back to the repository, manipulate PRs, or publish packages, the compromise path extends beyond source code review. That cross-plane reach is why CI/CD governance cannot sit only with engineering teams. Security, IAM, and platform owners need a shared control model for pipeline identities and approval state.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• For a broader breach lens, The 52 NHI breaches Report shows how identity control failures repeatedly convert standing access into operational compromise.

What this signals

Workflow identities need the same governance cadence as other privileged NHIs. If a pipeline can read secrets, write branches, and publish packages, then it belongs inside the same review, scope, and ownership model as any other machine identity. The relevant shift is operational, not semantic: teams must decide who can grant, review, and revoke workflow privileges before the next pull request arrives.

Secret exposure in build systems is now a containment problem, not just a detection problem. With 27 days as the average remediation time for a leaked secret in our research, the window between exposure and cleanup is long enough to matter across CI/CD environments. That makes the combination of secret scanning, token minimisation, and branch protection a governance requirement, not an optional enhancement.

The strongest programmes will connect repository governance to identity governance, so a privileged workflow cannot outlive its approval state. That means tying runner access, token scope, and secret distribution to the same lifecycle controls already used for other high-risk non-human identities.

For practitioners

• Harden pull_request_target usage Allow pull_request_target only for metadata workflows that never check out or execute pull request code. Review every workflow step that references github.event.pull_request.head.sha or pulls code from the fork.
• Separate untrusted contributions from privileged jobs Route forked pull requests into isolated workflows with read-only permissions and no secret access. Keep release, deployment, and package publication jobs on protected branches with explicit approval gates.
• Reduce token scope and secret visibility Replace broad repository tokens with narrowly scoped permissions, and ensure secrets are injected only into jobs that genuinely require them. Recheck legacy repositories that still depend on inherited default permissions.
• Treat runners as governed identity endpoints Inventory GitHub-hosted and self-hosted runners as separate access surfaces, then apply lifecycle review to who can schedule jobs, who can approve them, and what internal reach each runner has.

Key takeaways

• Misusing pull_request_target turns GitHub Actions from a convenience layer into a privileged execution path for untrusted code.
• The compromise surface is broader than secrets alone because write-enabled tokens and runner access can alter branches, packages, and deployment state.
• The most effective control is to treat workflow identities as governed non-human identities with strict scope, review, and separation of duties.

Key terms

• Pull Request Target: A GitHub Actions trigger that runs a workflow in the context of the base repository rather than the fork that opened the pull request. It is useful for tasks that need repository-level permissions, but it becomes risky when the workflow executes untrusted contributor code or exposes secrets to that code.
• Workflow Identity: The non-human identity a CI/CD job uses to act on behalf of a repository or pipeline. It can include tokens, permissions, secrets, and runner access, all of which should be governed as privileged access because they can change code, publish packages, or touch downstream systems.
• Runner: The execution environment that performs a GitHub Actions job. Runners can be GitHub-hosted or self-hosted, and both represent access surfaces. If untrusted code reaches a privileged runner, the runner effectively becomes part of the organisation's identity and control plane.
• Supply Chain Compromise: A compromise that starts in the build, dependency, or delivery chain and then reaches trusted software or release processes. In CI/CD, it often begins with privileged automation and ends with tampered code, stolen secrets, or altered deployment state.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Orca Security: GitHub Actions pull_request_target misuse and supply chain risk. Read the original.