GitHub Actions pull_request_target misuse turns forks into RCE

At a glance

What this is: Orca Security shows that GitHub Actions pull_request_target misuse can convert a forked pull request into remote code execution on privileged runners.

Why it matters: This matters because CI/CD workflow identity is part of the attack surface, and privileged automation can turn a routine pull request into secret exposure, branch tampering, or supply chain compromise.

Context

GitHub Actions workflow triggers control where code runs, which permissions apply, and whether repository secrets are available. The problem is not CI/CD itself but the common assumption that a workflow can safely inspect or execute code from an untrusted fork while retaining base-repository privileges.

In the pull_request_target pattern, the job executes in the base repository context rather than the fork context, so the default token and any exposed secrets can be reachable if the workflow checks out attacker-controlled code. That makes workflow design, token scope, and runner trust part of the identity model for the pipeline.

The article focuses on misconfigured workflows in high-profile repositories, which means this is not an isolated edge case. It is a representative failure mode for teams that still treat pull_request_target as a convenience trigger rather than a privileged execution boundary.

Key questions

Q: What breaks when pull_request_target workflows process untrusted input?

A: The workflow can turn attacker-controlled text or branch names into executable shell syntax while still running with the base repository's permissions. That creates a path from harmless-looking metadata to secret exposure, release tampering, or package publication. The failure is not the trigger alone. It is the combination of privileged context, unsafe interpolation, and insufficient separation between review and execution.

Q: Why do fork based pull request workflows increase supply chain risk in cloud native development?

A: Because a fork can carry malicious workflow files, scripts, or package metadata that are later executed in the context of the upstream repository. That breaks the usual boundary between contributor space and trusted production automation. Teams should assume every external contribution path can become an execution path unless permissions, checkout rules, and secret exposure are tightly constrained.

Q: What do teams get wrong about securing GitHub Actions with token permissions?

A: A common mistake is treating workflow security as a one-time setting instead of a per-action requirement. Another is assuming a single permission model fits every job. The safer approach is to maintain action-level permission data, review API usage, and update the workflow configuration whenever actions change. That keeps permissions aligned with real behavior.

Q: How should teams separate safe PR automation from privileged execution?

A: Use one workflow for non-execution tasks such as labeling and a different, tightly controlled workflow for tests or builds. The privileged path should not execute forked code until trust is explicitly established, because workflow order determines whether the job behaves like inspection or like remote code execution.

Technical breakdown

Why pull_request_target changes the trust boundary

The pull_request_target event runs workflow logic in the base repository context, unlike pull_request, which keeps forked code at arm's length. That distinction matters because the base context can expose secrets and grant the default GITHUB_TOKEN read or write permissions depending on repository configuration. The safe use case is metadata-only work such as labeling or triage. The risk appears when teams combine that trigger with checkout of attacker-controlled code, because the runner then executes untrusted content with repository-level authority.

Practical implication: Treat pull_request_target as privileged execution, not as a generic PR trigger.

How privileged runners become a supply chain path

Once attacker-controlled code executes inside a privileged workflow, the runner itself becomes the bridge to broader compromise. On GitHub-hosted runners, that may mean secrets theft, branch manipulation, or malicious package publishing. On self-hosted runners, the blast radius grows because the job can inherit access to internal systems, cloud credentials, or build infrastructure that sits outside GitHub's guardrails. In supply chain terms, the workflow is no longer just automation. It is an identity-bearing control plane that can be abused to alter trusted software paths.

Practical implication: Separate untrusted PR handling from any job that can mutate code, packages, or infrastructure.

Why token scope and checkout order decide the outcome

The critical failure pattern is not merely a broad token. It is broad token scope combined with a checkout step that pulls the pull request head into a privileged job. That sequence lets attacker code inherit write access, repository secrets, and any follow-on permissions attached to the workflow. Fine-grained permissions reduce the damage, but only if the workflow never executes untrusted code before privileges are needed. In practice, the order of operations in CI/CD is an access-control decision, not just an engineering detail.

Practical implication: Review workflow step order as rigorously as you review IAM policy.

Threat narrative

Attacker objective: The attacker wants privileged execution inside the trusted CI/CD pipeline so they can steal secrets, modify repository state, and move malicious changes into the software supply chain.

1. Entry occurs when an attacker submits a malicious pull request from a fork into a repository with a misused pull_request_target workflow.
2. Credential access follows when the workflow runs in the base repository context and exposes secrets or a write-enabled GITHUB_TOKEN to the job.
3. Escalation happens when the workflow checks out and executes attacker-controlled code, allowing the attacker to push changes, alter workflows, or abuse package publishing rights.
4. Impact is supply chain compromise, including remote code execution on GitHub-hosted or self-hosted runners, secret exposure, and tampering with trusted branches and dependencies.

Breaches seen in the wild

• 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).
• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

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

Privileged CI/CD context is an identity boundary, not a convenience setting. pull_request_target shifts trust from the fork to the base repository, which means the workflow is acting with repository identity and associated authority. Once teams forget that the workflow itself is privileged, they create a path where untrusted code inherits trust by execution order rather than by approval. Practitioners need to treat workflow triggers as part of access governance, not just build orchestration.

Checkout of untrusted PR code inside a privileged job is the failure mode that matters. The dangerous pattern is not simply that a token exists, but that attacker content is executed before the job's privileges are constrained. That is a workflow-originated supply chain risk because it converts a source-code review event into a control-plane execution event. The practical conclusion is that build pipelines must distinguish inspection from execution with absolute clarity.

Pull request automation still assumes human-paced review of code before privileged action. That assumption breaks when a workflow itself decides when to run code that came from outside the trust boundary. In that sense, CI/CD governance is really delegated identity governance for software delivery, and the reviewer is no longer the only actor with effective control. Teams should stop treating automation as neutral and start mapping where authority is actually exercised.

Write-enabled tokens and self-hosted runners enlarge the blast radius beyond GitHub. Once a workflow can mutate branches, publish packages, or reach internal runner infrastructure, the compromise can extend into release pipelines and downstream environments. The result is not merely repository tampering but software trust failure. Practitioners should assume that any privileged workflow touching untrusted input can become a supply chain pivot.

Workflow privilege needs the same rigor as human and machine identity governance. CI/CD jobs, service tokens, and runner contexts are identities with lifecycles, scope, and offboarding requirements. The article shows what happens when those controls are implied instead of enforced. The field should treat workflow identity as a first-class governance domain, not an operational afterthought.

From our research library:

• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Workflow privilege is now part of CI/CD governance. Teams that still treat pull_request_target as a convenience trigger are leaving an identity decision hidden inside pipeline design. The better programme view is to classify every workflow by who it executes for, what it can mutate, and whether untrusted input can ever cross into a privileged context.

Runtime trust boundaries must be enforced before execution, not after review. Once a job checks out attacker-controlled content inside a privileged context, the blast radius is already in motion. The practical response is to move untrusted PR handling out of privileged paths and to reserve elevated tokens for narrowly bounded jobs that never touch forked code.

Workflow identity is a lifecycle problem as much as a permissions problem. Secrets, runner access, and token scope need ownership, review, and retirement just like any other non-human identity. The next maturity step for most programmes is to stop asking whether a workflow is common and start asking whether it is safely governed across its full lifecycle.

For practitioners

• Audit every pull_request_target workflow Identify any workflow that combines pull_request_target with checkout or execution of forked code, then classify it as privileged until proven otherwise.
• Separate triage from execution Keep labeling, commenting, and metadata updates in one workflow, and move build or test execution for forked code into a separate unprivileged path.
• Restrict token permissions by default Set GITHUB_TOKEN to the minimum permissions required for each workflow and remove write access from jobs that do not need to change repository state.
• Block untrusted code before privileged steps Ensure no checkout or script execution of forked content occurs until the workflow has passed an explicit trust gate or approval control.
• Review self-hosted runner exposure Confirm that externally triggered workflows cannot reach self-hosted runners unless those runners are isolated from secrets, package publishing, and internal network access.

Key takeaways

• Misused pull_request_target workflows can turn a forked pull request into privileged code execution on GitHub-hosted or self-hosted runners.
• The failure mode is a trust-boundary collapse in CI/CD, where untrusted code inherits base-repository permissions and secrets.
• Teams can reduce the blast radius by separating PR triage from execution, tightening token scope, and keeping untrusted code out of privileged jobs.

Key terms

• Pull_request_target workflow: A GitHub Actions trigger that runs in the context of the base repository, not the contributor’s fork. That means it can access repository secrets while processing untrusted pull request content, which creates a sharp trust boundary and a common route to secret theft if not carefully segmented.
• Privileged Workflow: A privileged workflow is any access or administrative process that can change sensitive systems, accounts, or controls. Because these workflows can create audit and abuse risk quickly, they need independent approval, logging, and review, especially when one person could otherwise control multiple steps.
• Workflow trust boundary: A workflow trust boundary is the point where one step in a business or technical process stops being fully trusted and must be checked before the next step continues. It defines where identity, data, or action permissions change, and where controls such as approval, validation, logging, or isolation should be applied.
• Self-hosted runner: A CI/CD execution environment managed by the organisation rather than the platform vendor. It often has broad access to source, secrets, and deployment targets, which makes it a high-value persistence and exfiltration point if workflow controls are weak.

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.