TL;DR: Misconfigured GitHub Actions workflows can expose tokens, allow code execution, and propagate compromise across downstream repositories, according to Grip Security’s analysis of the Trivy breaches. The pattern shows that CI/CD trust assumptions, not just repository hygiene, now define supply chain blast radius.
At a glance
What this is: This analysis explains how misconfigured GitHub Actions workflows in the Trivy incidents enabled token theft, code execution, and downstream supply chain expansion.
Why it matters: It matters because CI/CD pipelines now sit inside the trust boundary for software supply chain security, and IAM-style controls over runners, tokens, and permissions determine blast radius.
Context
GitHub Actions is a CI/CD automation layer, but in practice it also becomes an identity and trust boundary for build and release operations. When workflows run untrusted pull request code or inherit broad permissions, the pipeline can expose secrets, mutate release artifacts, and carry compromise into downstream repositories.
The Trivy incidents show why workflow governance now sits at the intersection of supply chain security and identity control. Misconfigured triggers, over-privileged tokens, and weak tag integrity create a path from initial workflow abuse to credential theft and wider ecosystem impact. That is a common failure mode in modern CI/CD, not an edge case.
Key questions
Q: What breaks when GitHub Actions workflows are allowed to access secrets without approval?
A: When workflow secret access is not gated, an attacker can turn the CI runner into the exfiltration tool. A malicious workflow can dump secrets, upload them as an artifact, and remove traces before anyone notices. At that point, detection becomes reactive only, and organisations are left rotating credentials after exposure instead of preventing the theft in the first place.
Q: Why do compromised CI/CD tokens create such a large supply chain blast radius?
A: Because one token often carries more authority than the job that exposed it. A stolen GitHub credential can modify tags, publish artifacts, change repository state, or seed malicious dependencies downstream. In supply chain terms, the attacker is not just stealing access, they are inheriting the trust that other systems place in the pipeline.
Q: How do teams know a GitHub Actions workflow is too permissive?
A: Look for workflows that can write to repositories, publish releases, or access secrets without a narrow business need. Another warning sign is a workflow that reacts to external pull requests while also checking out attacker-controlled code. If a build job can alter release state, the permission model is already wider than the task requires.
Q: What should security teams do when a release tag may have been force-pushed?
A: Treat the release channel as potentially contaminated and validate the commit history, signature state, and downstream consumers before trusting the tag again. Force-pushed tags indicate that release identity may no longer match release content, so teams need to verify integrity before continuing automation or dependency consumption.
Technical breakdown
Why pull_request_target creates a trust boundary problem
The pull_request_target event runs in the context of the target repository, not the forked contributor. That means the workflow can inherit secrets and permissions intended for trusted code while still reacting to untrusted input. If the workflow checks out the pull request head or executes scripts influenced by that content, the job can become a code execution path. The core issue is not GitHub itself, but the mismatch between trigger trust and code trust. In CI/CD terms, the pipeline is making an authentication decision before it has established whether the code deserves that level of access.
Practical implication: Treat untrusted pull request content as hostile unless the workflow is isolated from secrets and write permissions.
How token exfiltration from runners turns one workflow into a supply chain pivot
Runner memory is a valuable target because CI jobs often load GitHub tokens, deployment secrets, and package publishing credentials during execution. If a malicious step can read process memory or abuse a script path, the attacker may capture credentials with write access to releases, tags, or dependent repositories. That converts a single workflow compromise into a reusable identity problem. The article’s Trivy example shows how a stolen token can be used to rename repositories, delete releases, or push malicious artifacts without further exploitation of GitHub. The issue is lifecycle and privilege scope, not just secret presence.
Practical implication: Restrict runner access, shorten token lifetime, and separate publishing privileges from build execution where possible.
Why tag integrity matters once credentials are compromised
In software supply chain attacks, tags and release references are part of the trust fabric. If an attacker gains write access, they can force-update tags or replace release pointers while downstream consumers continue to trust the original name. Immutable pinning to commit SHA reduces that risk because it makes the referenced content harder to silently rewrite. In the Trivy chain, the attack moved from workflow abuse to authenticated repository operations, which is why the blast radius expanded quickly. This is a control problem about integrity, not just access. Release governance has to assume that authenticated misuse can be as damaging as external exploitation.
Practical implication: Require immutable references for GitHub Actions dependencies and verify tag and commit integrity before consuming releases.
Threat narrative
Attacker objective: The objective was to turn CI/CD trust into durable repository and release control that could be reused to spread compromise across the software supply chain.
- Entry occurred through a misconfigured GitHub Actions workflow that could be triggered from untrusted pull request activity.
- Credential harvesting followed when the workflow exposed a GitHub token or runner-accessible secrets from the CI environment.
- Escalation happened when the stolen credential was reused for authenticated repository actions, including tag and release manipulation.
- Impact was supply chain expansion, with malicious artifacts and downstream exposure across many repositories that depended on the compromised action.
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).
- 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.
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
GitHub Actions has become an identity plane, not just an automation plane. The article shows that workflow triggers, repository permissions, and runner credentials now determine whether a pipeline is trustworthy. That shifts supply chain governance from simple code review to identity-aware control of who or what can execute with release authority. Practitioners should treat workflow design as access design.
Misconfigured workflow trust is the root cause, not the visible token theft. The Trivy incidents worked because the workflow accepted untrusted code or retained privileges that should have been segregated. That is a governance failure of the CI/CD boundary, where authentication and authorisation happened before trust was established. Teams should focus on the control gap at workflow entry, not only on the stolen secret.
Immutable release references are now a supply chain integrity control. When tags can be force-pushed after credential compromise, downstream consumers inherit false trust in a familiar release name. This is why build and release integrity must be governed as a lifecycle problem, not a one-time repository setting. Practitioners should assume that signed, pinned, and attestable release paths are part of operational resilience.
AI-assisted scanning of public workflows changes attacker scale, not the underlying weakness. The article’s campaign references an AI bot hunting for vulnerable workflows, which means exposed patterns can be found faster and abused repeatedly. That does not create a new class of flaw, but it does compress the time between misconfiguration and exploitation. Security teams should expect automated discovery of workflow mistakes.
GitHub supply chain abuse now sits squarely inside NHI governance. Tokens, runner credentials, and repository permissions are machine identities with real privilege, and they behave like any other unmanaged NHI when lifecycle control is weak. The named concept here is CI/CD trust collapse: a workflow starts as a build control and ends as a credential exfiltration path. Practitioners should govern pipeline identities with the same discipline as service accounts.
From our research library:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- 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
CI/CD trust collapse: the real lesson in GitHub Actions abuse is that workflow permissions, runner credentials, and release integrity now behave like a single control surface. If any one of those elements is over-broad, an attacker can turn automation into a persistence and distribution layer. Practitioners should review pipeline identity as part of supply chain governance, not as an isolated DevOps concern.
The blast radius grows fastest when tokens live longer than the job that exposed them. In this article’s Trivy chain, credential reuse and tag rewriting show how one workflow compromise can spread across dependent repositories, which is why lifecycle control for runner credentials and pinned dependencies should be treated as a release integrity requirement.
For practitioners
- Lock down untrusted pull request execution Avoid running pull_request_target workflows against untrusted code unless the job is fully isolated from secrets and write privileges.
- Enforce immutable dependency and release pinning Pin GitHub Actions dependencies to commit SHAs and verify that tags cannot be rewritten after release publication.
- Separate build permissions from publishing rights Keep CI runners on the minimum permissions needed for build and test, and move release or repository write access into a narrower publishing path.
- Monitor for token exfiltration patterns in workflows Alert on workflow steps that combine network utilities with references to GITHUB_TOKEN or secrets expressions, especially in YAML changes.
- Review CI/CD credentials as machine identities Inventory GitHub tokens, runner credentials, and action permissions as non-human identities with owners, expiry, and revocation paths.
Key takeaways
- Misconfigured GitHub Actions workflows can turn CI/CD into a credential exposure and release tampering path, especially when untrusted code reaches privileged jobs.
- The article’s Trivy example shows how a single compromised workflow can expand into downstream supply chain abuse across many dependent repositories.
- Immutable pinning, narrow runner permissions, and machine-identity lifecycle controls are the practical barriers that reduce the blast radius of workflow compromise.
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 SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on token exposure from misconfigured workflows and runner memory. |
| NHI-05 — Overprivileged NHI | GitHub tokens and CI runners gained more privilege than the job required. | |
| NHI-07 — Long-Lived Secrets | Stolen CI credentials remained useful long enough to enable follow-on authenticated abuse. | |
| Recommendation — Scan workflow logs, runners, and YAML changes for exposed secrets and revoke any leaked credentials immediately. Reduce workflow and runner permissions to the minimum needed for each pipeline stage. Shorten token lifetimes and rotate CI credentials as soon as compromise is suspected. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The attack chain used credential theft to pivot into repository and downstream supply chain abuse. |
| Recommendation — Map CI/CD compromise to credential access and lateral movement to prioritise detections around runner memory and release actions. | ||
| CIS Controls v8 | CIS-5 — Account Management | Workflow credentials and publishing rights behaved like unmanaged accounts with excess reach. |
| Recommendation — Apply account management controls to CI/CD identities and remove unused or excessive workflow privileges. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is excessive workflow authorisation and weak entitlement boundaries in GitHub Actions. |
| Recommendation — Review GitHub Actions entitlements so each workflow only receives the permissions its task actually needs. | ||
| SLSA | L2 — Build provenance | Force-pushed tags and poisoned releases undermine build provenance and artifact trust. |
| Recommendation — Require provenance and immutable references before consuming build artifacts or release tags. | ||
Key terms
- Pull Request Target Risk: A workflow risk pattern where untrusted pull request content is processed in a privileged context. Because the job may run with write access or access to secrets, the boundary between review and execution collapses. The control failure is not the pull request itself, but the permissions attached to the trigger.
- Runner Credential Exposure: The moment a CI/CD job can access tokens, secrets, or other sensitive credentials during execution. If the runner is exposed to attacker-controlled input, those credentials may be harvested and reused outside the intended task, expanding the impact from a single job to repository or supply chain compromise.
- Immutable Release Pinning: A release control that binds dependencies or workflow references to a specific commit or verified artifact rather than a mutable tag. It reduces the chance that an attacker can rewrite trusted release pointers after gaining repository or publishing access.
- CI/CD privilege boundary: A CI/CD privilege boundary is the point where untrusted repository content meets elevated execution rights. If that boundary is weak, a build or review workflow can become a route from ordinary contribution activity to token exposure, repository compromise, or supply-chain publishing.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It helps security and identity practitioners connect lifecycle control to the broader access model their programmes depend on.
Published by the NHIMG editorial team on August 15, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org