TL;DR: A misconfigured GitHub Actions pull_request_target workflow can let forked pull requests run with repository secrets and write access, according to Plerion's analysis of Trivy and related repositories. That turns CI configuration into an access-control problem, because the runner executes attacker-controlled code under trusted credentials.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Plerion's research: pull_request_target workflows can let forked pull requests execute with repository secrets and write access, and the same pattern was found across many public repositories.
Why it matters: IAM and DevSecOps teams need to treat CI workflow context, token scope and code checkout rules as access-control decisions, because a single trigger choice can expose privileged automation to untrusted code.
Context
GitHub Actions separates untrusted pull request execution from trusted repository context, but that boundary only holds when the workflow never checks out attacker-controlled code or reuses privileged credentials. In CI/CD, the security model depends as much on where code runs as on what the code does.
The risk becomes an identity problem when the runner inherits repository secrets, GITHUB_TOKEN permissions or federated cloud credentials. A workflow intended to automate collaboration can instead hand a forked pull request a trusted execution context, which is why workflow design matters more than repository popularity.
Key questions
Q: How do you secure pull_request_target workflows against forked PR abuse?
A: Treat pull_request_target as a privileged automation path and never check out untrusted fork code before secrets, write tokens, or approvals are needed. Use path filters, minimal permissions, pinned actions, and separate unprivileged validation from trusted deployment jobs. Keep repository secrets unavailable to forked contributions unless a maintainer has explicitly reviewed the change.
Q: Why does a forked pull request become dangerous in GitHub Actions?
A: A forked pull request becomes dangerous because the workflow runs with the base repository's context, which can include secrets, write-scoped tokens, and permissions that the attacker-controlled fork should never see. If the job checks out or executes fork content before reducing privilege, the PR can turn workflow code execution into credential exposure or repository compromise.
Q: What is the difference between pull_request and pull_request_target in CI/CD security?
A: pull_request runs workflow logic in the context of a pull request and is generally safer for untrusted contributions. pull_request_target runs with the permissions and secrets of the base repository, which can be useful for controlled review workflows but is much riskier if forked content can influence execution. The key distinction is whether untrusted code can touch privileged context.
Q: What should teams do first when a workflow may expose secrets?
A: First, stop the exposure path by disabling the workflow or removing the secret from the job until you know exactly which step can read it. Then inspect the trigger, permission block, checkout step, and any composite or reusable actions that may receive a privileged token, because the leak is usually caused by execution context rather than the secret itself.
Technical breakdown
Why pull_request_target changes trust boundaries
GitHub Actions uses different execution contexts for pull request events. pull_request runs in the fork's context with read-only permissions and no secrets, while pull_request_target runs in the target repository's context with its secrets and its default token scope. That distinction exists so maintainers can label, comment or otherwise act on a PR without granting the contributor write access. The danger appears when the workflow then reads or executes code from the fork, because the trusted context and untrusted content are combined in one run. See the GitHub and GitHub Actions Security Guide.
Practical implication: Treat pull_request_target as a privileged execution path and reserve it for workflows that never execute contributor-controlled code.
How checkout ref confusion creates code execution
The exploit hinges on a checkout step that points at the PR head rather than the base branch. If actions/checkout pulls the forked branch and later steps run build scripts, tests or shell fragments from that tree, attacker-controlled code executes under repository credentials. Even small variations such as unsafe interpolation in run blocks or weak branch conditions can preserve the vulnerability. The issue is not the trigger alone, but the combination of trigger, checkout ref and downstream execution path. See the OWASP CI/CD Top 10 CICD-SEC-4 Poisoned Pipeline Execution Guide.
Practical implication: Verify that privileged workflows only check out trusted code paths and never run PR head content in a secrets-bearing context.
Why repository tokens and OIDC raise the blast radius
The immediate prize is a live GITHUB_TOKEN, often with broad write permissions to issues, releases, packages and contents. Many repositories also store secrets for deployment or automation, and some expose cloud access through OIDC federation. In that case the runner can request cloud tokens without any stored secret, because the cloud trusts GitHub, GitHub trusts the workflow and the workflow executes attacker code. That makes workflow abuse a route into broader platform access, not just source control manipulation.
Practical implication: Restrict workflow token scope and cloud federation trust so a CI compromise cannot become repository or cloud compromise.
Threat narrative
Attacker objective: The attacker wants trusted CI privileges that let untrusted code modify releases, steal secrets or move into connected cloud environments.
- Entry occurs when an attacker opens a forked pull request against a workflow that uses pull_request_target in the repository's trusted context.
- Credential access follows when the workflow checks out the fork's code and exposes GITHUB_TOKEN, repository secrets or OIDC credentials to that execution.
- Escalation and impact occur when attacker-controlled steps push commits, delete releases, publish malicious packages or assume cloud roles through federated trust.
Breaches seen in the wild
- SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.
- 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
pull_request_target is a privilege boundary, not a convenience feature: CI systems fail when maintainers treat the trigger as harmless automation instead of a trusted execution path. The repository context, token scope and checkout ref all become part of the access decision. Once those elements are mixed with contributor-controlled code, the workflow is no longer just building software, it is authorising execution. Practitioners should classify privileged workflow triggers as identity-bearing control points.
The dangerous assumption is that review equals trust: pull request review does not neutralise untrusted code when the workflow executes before the merge and inherits target-repository credentials. That is a lifecycle failure in CI governance, not a code-quality issue. A malicious or simply mistaken workflow can convert collaboration infrastructure into an access channel without any direct permission grant. Security teams should govern workflow context with the same care they apply to production service accounts.
Secret exposure in CI is really non-human identity exposure: the runner inherits a machine identity, then uses it on behalf of code that was never meant to have it. That makes CI compromise an NHI problem as much as a software supply chain problem, especially when OIDC-backed cloud roles are available. The right control lens is identity scope, not just pipeline hygiene, and Trivy guide belongs in that review for teams using this pattern.
Scale matters because the pattern is repeatable across ecosystems: once one workflow shape produces exploitable trust, the question becomes how many repositories share that same configuration mistake. The validation result shows this is not a one-off maintainer error but a repeatable governance weakness across open-source projects, including security tooling itself. Practitioners should assume the same misconfiguration may exist in their own estates until proven otherwise.
Named concept: Pwn Request workflow abuse: this is the failure mode where a privileged pull-request workflow executes attacker-controlled content from a fork under trusted credentials. It is distinct from ordinary CI injection because the attack depends on a specific trust boundary collapse between contributor content and repository authority. Teams should treat this as a reusable attack pattern and hunt for it wherever privileged PR automation exists.
What this signals
CI privilege has become an attack surface: once workflow context can execute untrusted code with repository authority, the control problem shifts from build integrity to trust boundary management. Security teams should expect attackers to look for the same pattern in any system that combines external contribution with privileged automation.
Pwn Request is a repeatable governance failure, not a one-off bug: the same workflow shape can exist across open-source, cloud and security repositories, so detection has to focus on trigger type, checkout ref and token scope together. Programmes that still treat CI as a developer concern will miss a class of access paths that can reach releases, secrets and federated cloud roles.
For practitioners
- Audit privileged PR workflows for unsafe checkout refs Search for pull_request_target, then confirm whether any job checks out PR head content or executes contributor-controlled scripts before merge.
- Restrict workflow permissions to the minimum viable scope Set permissions: {} by default, then grant only the exact token rights a workflow needs for labels, comments or release steps.
- Split trusted and untrusted pipeline stages Move build and test execution into an unprivileged first stage, then trigger a second trusted stage only after the code path is validated. See the OWASP CI/CD Top 10 CICD-SEC-4 Poisoned Pipeline Execution Guide.
- Review cloud federation trust behind CI runners Check whether GitHub OIDC access can assume cloud roles from privileged workflows, and remove any role that does not need that path.
Key takeaways
- The core failure was a trust-boundary collapse in CI, where a privileged workflow could execute forked code under repository credentials.
- The validation work confirmed 48 exploitable repositories and 34 with no guards, which shows the pattern is broad rather than isolated.
- The most effective fix is to separate untrusted and trusted stages, reduce token scope and remove unsafe checkout behaviour from privileged workflows.
Related NHI Mgmt Group resources: Trivy Guide · GitHub and GitHub Actions Security Guide · OWASP CI/CD Top 10 CICD-SEC-4 Poisoned Pipeline Execution Guide · Out-of-Band Communications for Incident Response Guide
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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Privileged GitHub Actions workflows expose machine credentials to untrusted fork code. |
| NHI-05 — Overprivileged NHI | Default GitHub token scope and secrets exposure create excessive machine privilege in CI. | |
| Recommendation — Restrict privileged workflow contexts so untrusted pull requests never inherit authenticated machine access. Minimise workflow token scope and remove secrets from jobs that do not strictly require them. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack path uses trusted workflow credentials to move from CI execution into repository and cloud access. |
| Recommendation — Map privileged workflow abuse to credential access and lateral movement so detections focus on CI trust boundaries. | ||
| CIS Controls v8 | CIS-5 — Account Management | Workflow identities and repository tokens need lifecycle control and least-privilege assignment. |
| Recommendation — Apply account and token lifecycle controls to CI identities and revoke unused workflow access paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Workflow permissions and repository entitlements govern whether PR-triggered jobs can write or exfiltrate. |
| Recommendation — Enforce least-privilege permissions on workflow identities and review entitlements for privileged CI jobs. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Repository secrets, tokens and federated credentials need lifecycle and scope management. |
| Recommendation — Rotate, scope and revoke CI authenticators so trusted runners cannot be abused by untrusted code. | ||
Key terms
- pull_request_target: pull_request_target is a GitHub Actions trigger for pull requests that runs workflows in the context of the base repository, not the fork. That grants access to repository secrets and write permissions, so it must be used only with strict checks on untrusted code, labels, and workflow steps.
- GitHub Action: A GitHub Action is an automated workflow step that runs inside GitHub-based development and delivery processes. It can be used for build, test, or maintenance tasks, but it also becomes part of the security boundary because compromised actions can access secrets and influence downstream systems.
- GITHUB_TOKEN: GITHUB_TOKEN is the temporary token GitHub creates for each workflow run to authenticate automation against repository resources. Its permissions depend on event type and workflow configuration, which makes scope control important. If over-privileged, it can be used to alter repository state or assist post-exploitation activity.
- OIDC Federation: OIDC federation is a token-based trust model that lets one system accept identity assertions from another. It is commonly used to avoid static cross-environment credentials and to issue short-lived access based on trusted token claims. The control value depends on how tightly the trust relationships are governed.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management. It helps practitioners connect CI/CD trust boundaries to the identity controls that govern machine access.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org