Compromised GitHub Action tags can exfiltrate CI/CD secrets

At a glance

What this is: This is an analysis of a compromised GitHub Action where every tag was repointed to malicious code that steals CI/CD credentials from runner memory.

Why it matters: It matters because identity and access assumptions in pipelines collapse when third-party actions can inherit decrypted secrets, exposing both machine identities and downstream human-controlled environments.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read StepSecurity's analysis of the compromised actions-cool GitHub Action tags

Context

CI/CD pipelines become identity-rich execution environments the moment they decrypt secrets for a job. If a third-party GitHub Action is compromised, the runner can expose credentials, tokens, and other secrets even when the workflow itself looks unchanged. This article is primarily about supply chain compromise in software delivery, with a direct identity and secrets-management intersection.

The governance gap is trust in mutable references. Tag-based action usage assumes the tag still points to legitimate code, while the runtime assumes the action will not inspect process memory or exfiltrate credentials. That assumption fails when an attacker repoints every tag to an imposter commit and uses the runner’s own decrypted context against it.

Key questions

Q: What breaks when a GitHub Action tag is repointed to malicious code?

A: Tag repointing breaks the assumption that a version label still maps to trusted code. Workflows continue to run, but they may execute attacker-controlled logic with the same permissions and secrets the original action expected. That turns a versioning choice into a supply chain trust decision, especially when the action can read runner memory or call external endpoints.

Q: Why do CI/CD pipelines create non-human identity risk?

A: CI/CD pipelines create non-human identity risk because they authenticate to other systems, carry secrets, and perform privileged actions automatically. When a workflow is compromised, the attacker can inherit that authority and move into cloud, source control, or publishing systems. The pipeline is therefore an identity-bearing control point, not just an execution engine.

Q: What do teams get wrong about secrets management in pipelines and scripts?

A: They often treat the vault as the finish line. In practice, a secret can be copied into code, tickets, chat tools, and automation jobs, which means governance must include discovery, removal, and proof of cleanup. Rotation alone does not fix duplicate exposure.

Q: Who is accountable when a third-party action steals deployment credentials?

A: Accountability is shared across the repository owner, the platform team, and the application owner that approved the dependency. The practical question is whether the organisation pinned immutable versions, reviewed action provenance, and limited secret scope. Frameworks such as NIST SP 800-53 and OWASP NHI both support that shared control model.

Technical breakdown

How malicious GitHub Action tags turn trust into execution

GitHub Actions workflows often reference third-party code by tag or version, which is convenient but mutable. If an attacker can move a tag, the workflow still resolves the same label, but the underlying commit changes. That creates a hidden dependency on repository integrity and release discipline rather than on the workflow file alone. In this case, the dangerous part is not just code execution, but code execution under the privileges of the pipeline runtime, where secrets have already been made available to the job.

Practical implication: pin external actions to full commit SHAs and monitor for tag-to-commit drift.

Why runner memory becomes a high-value secret source

CI/CD runners frequently hold decrypted secrets, short-lived tokens, and session context inside process memory while jobs execute. A malicious action does not need to wait for configuration files or logs if it can inspect the runner process directly. Memory scraping is especially effective because the secrets are already present in use, often in a form intended only for local job execution. The issue is not just secret storage, but secret exposure during runtime when the isolation boundary is weakest.

Practical implication: reduce the secret lifetime inside runners and isolate jobs so memory inspection yields less usable data.

Why outbound exfiltration control is the last line of defence

Once a malicious action has harvested credentials, the attacker still needs a path out of the runner. Network egress policy, domain block lists, and runtime detection are the control layer that can stop theft after execution has already begun. This makes egress controls a containment mechanism, not a substitute for secure sourcing of actions. In pipeline security, the best control stack is layered: provenance, execution policy, and outbound restriction.

Practical implication: apply egress restrictions and alerting to build defense in depth around pipeline execution.

Threat narrative

Attacker objective: The attacker aims to steal usable CI/CD credentials and reuse them for broader environment access, persistence, or downstream supply chain compromise.

1. Entry occurs when the attacker repoints trusted GitHub Action tags to imposter commits that workflows will still resolve as legitimate versions.
2. Escalation happens inside the runner when malicious code reads the Runner.Worker memory space to harvest decrypted credentials and session material.
3. Impact follows when stolen secrets are exfiltrated to an attacker-controlled domain and can be reused across CI/CD, cloud, or source-control systems.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• 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

Mutable action references are a governance failure, not a convenience feature. When a pipeline trusts a tag more than a commit hash, it inherits the repository’s release integrity as part of its access model. That is a weak boundary because tags can move while workflow syntax stays unchanged. For identity and access teams, the lesson is that provenance has to be treated as part of authorization policy, not just software hygiene.

Pipeline secrets are effectively non-human identities in motion. Once a runner can decrypt tokens, API keys, or cloud credentials, those secrets behave like transient machine identities with far too much trust. The article shows how quickly an attacker can convert that trust into lateral movement. OWASP-NHI and NIST SP 800-53 both reinforce the need to govern issuance, usage, and revocation as a lifecycle, not as isolated events.

Memory scraping inside build runners is the specific failure mode this attack exploits. The attacker did not need a vault break-in if the secrets were already resident in process memory during execution. That creates a standing exposure window inside the job, even when external secret stores remain intact. Practitioners should treat runtime secret exposure as a separate control problem from storage encryption.

Tag compromise in third-party actions widens the blast radius of supplier trust. A single compromised action can affect many downstream repositories because workflows reuse the same dependency label at scale. That makes third-party action governance a supply chain issue with direct identity consequences, especially where cloud and source-control credentials are passed into jobs. Teams need supplier trust reviews that include action pinning, provenance checks, and egress control.

Named concept: runtime credential exfiltration through mutable action tags. This attack pattern combines release tampering, process-memory access, and outbound exfiltration into one repeatable chain. It is more precise than generic secret sprawl because the problem is not merely exposed secrets, but secrets harvested from a trusted execution context after tag manipulation. The practical conclusion is that pipeline identity controls must account for code mutability and runtime abuse together.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• From our research: 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
• From our research: Explore Guide to the Secret Sprawl Challenge for remediation patterns that reduce secret exposure across build and release pipelines.

What this signals

Runtime credential exfiltration through mutable action tags is the pattern defenders should now name explicitly. The control problem is not limited to secrets rotation or vault hygiene, because the attacker is abusing the trusted execution window inside CI/CD itself. Aligning workflow governance with the OWASP Non-Human Identity Top 10 and NIST SP 800-53 access control expectations helps teams focus on the lifecycle of credentials inside runners.

Credential exposure in automation pipelines is now a speed problem as much as a control problem. Our research shows exposed AWS credentials can be probed within 17 minutes on average, which means detection and containment have to operate faster than normal change-review cycles.

Pipeline owners should prepare for more supplier-trust attacks that target action provenance rather than infrastructure directly. Immutable references, egress controls, and least-privilege job design are becoming baseline requirements, not advanced hardening.

For practitioners

• Pin third-party actions to full commit SHAs Replace tag-based references with immutable commit identifiers for every external GitHub Action, and fail builds when a workflow drifts from an approved SHA. This closes the tag-repointing path used in the attack and makes provenance review auditable.
• Restrict secrets available to job runtime Minimise which credentials are injected into each runner, scope them to the narrowest possible job, and separate workflows that do not need secret access from those that do. The goal is to reduce the value of any memory scrape.
• Block suspicious outbound destinations from runners Enforce egress allowlists or deny risky domains at the runner layer so exfiltration attempts fail even after malicious code executes. Pair that with detection for unusual processes such as bun, python3 child processes, or memory access against /proc/*/mem.
• Review third-party action trust boundaries Inventory every reusable action, confirm the maintainer, and validate whether the workflow depends on tag semantics that could be rewritten without notice. Prioritise actions that can reach credentials, cloud tokens, or deployment secrets.

Key takeaways

• Compromised GitHub Action tags can turn a routine workflow update into credential theft inside the runner.
• The attack succeeds because decrypted secrets are available at runtime, where memory scraping and outbound exfiltration can reach them quickly.
• Immutable pinning, secret minimisation, and egress control are the controls that narrow the blast radius of third-party action compromise.

Key terms

• Mutable Action Reference: A mutable action reference is a workflow pointer that can change without the workflow file changing, such as a moving tag or version label. In CI/CD, this creates a trust dependency on repository integrity, because the same label can later resolve to different code and different security behaviour.
• Runner Memory Scraping: Runner memory scraping is the extraction of secrets or session material directly from a build or automation process while it is executing. It bypasses storage protections by targeting the runtime state where decrypted credentials often exist briefly and in usable form.
• Pipeline Egress Control: Pipeline egress control restricts which external destinations a CI/CD job can contact during execution. It is a containment measure that can stop stolen secrets from leaving the environment, even if malicious code succeeds in running.
• Imposter Commit: An imposter commit is a malicious commit placed so that a trusted label or tag resolves to attacker-controlled code rather than the legitimate repository history. It preserves the appearance of version continuity while silently changing what the workflow executes.

What's in the full analysis

StepSecurity's full blog post covers the operational detail this post intentionally leaves for the source:

• The full tag-to-commit evidence trail for both compromised actions, including the affected versions and timestamps.
• Detection indicators from Harden-Runner, including the bun process behaviour and the outbound call pattern.
• The compromised actions policy logic and block-list handling used to stop execution and exfiltration.
• The IOC inventory that helps teams map affected workflows and runners to remediation work.

👉 The full StepSecurity post includes the tag movement details, runner IOCs, and mitigation controls.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It is designed for practitioners who need to connect identity controls to real-world pipeline and runtime risk.