Checkmarx KICS GitHub Action tag compromise exposes CI/CD secrets

At a glance

What this is: This is a supply chain compromise of a GitHub Action where poisoned release tags caused CI/CD workflows to run attacker-controlled code and leak secrets.

Why it matters: It matters because release tags, runner memory, and workflow-scoped secrets are all part of the identity and trust model for CI/CD, and one compromised action can cascade across pipelines.

Context

CI/CD pipelines are not just automation systems, they are high-trust identity environments with access to secrets, cloud control planes, and deployment permissions. When a reusable action is compromised, the issue is not limited to the package itself, because the workflow inherits whatever credentials and privileges the pipeline can reach.

This case shows how tag-based dependency trust can fail when the referenced tag no longer points to immutable, reviewed code. For teams managing NHI, workload identity, or secret governance, the real control question is not only what ran, but what secret material the runner could access while it ran.

The incident is typical of modern CI/CD supply chain abuse, where attackers target the workflow’s trust boundary rather than the application runtime.

Key questions

Q: What breaks when a CI/CD action is pinned to a compromised version tag?

A: The workflow no longer runs reviewed code, it runs whatever commit the tag currently resolves to. That breaks the trust assumption behind release tagging and turns the pipeline into an execution path for attacker-controlled logic. The practical failure is not just malicious code, but secret exposure through the runner’s inherited privileges.

Q: Why do compromised CI/CD runners and workflow tokens create outsized security risk?

A: They sit inside the software delivery trust chain, so one credential can reach source code, build artefacts, release systems, and cloud services. A runner or workflow token often has more practical reach than a human account because it can operate at machine speed across multiple systems. That makes credential scope and execution boundaries the decisive controls.

Q: What signs suggest a pipeline has been abused to steal secrets?

A: Unexpected memory dumping, abnormal outbound connections, secret access outside normal job scope, and privileged follow-on activity in clusters or hosts all point to compromise. In this article’s pattern, the malicious action also attempted persistence, which means post-job host and Kubernetes telemetry matter as much as build logs.

Q: How should teams respond when a reusable build action is compromised?

A: Isolate the affected workflows, revoke every secret the action could reach, and verify that no downstream systems reused those credentials for access or persistence. Then rebuild trust from immutable references and least-privilege workflow design. The key decision is to contain identity exposure before assuming the package itself is clean again.

Technical breakdown

How poisoned Git tags turn a trusted action into execution risk

Git tags are often treated as stable release pointers, but in a compromised repository they become mutable trust anchors. If a workflow references an action by tag rather than an immutable commit SHA, the pipeline executes whatever code the tag resolves to at run time. That matters in CI/CD because the action inherits the runner’s environment, including repository secrets, cloud credentials, and deployment context. In this case, the master branch appeared clean while release tags pointed to malicious commits, which means the control failure sits in dependency pinning and provenance verification, not just in code review.

Practical implication: pin reusable actions to verified commit SHAs and treat tag-based references as an unstable supply chain dependency.

Why runner memory is a secrets target in pipeline compromise

CI/CD runners frequently handle secrets in memory after injection from environment variables, secret stores, or workflow steps. An infostealer that can inspect process memory can recover credentials even when they never appear in source code or logs. The article describes memory dumping of the GitHub Actions Runner.Worker process, which is a classic post-execution extraction path in supply chain incidents. This is why secret exposure in CI/CD is not only about vault hygiene; it is also about runtime containment, credential lifetime, and limiting which secrets are present on the runner at all.

Practical implication: minimise what each job can access, and assume in-memory secrets on shared runners are recoverable if the action is compromised.

How persistence expands a pipeline compromise into broader environment access

Once attackers obtain CI/CD credentials, they can move beyond theft and attempt persistence in connected environments. The article notes attempts to deploy a systemd backdoor and privileged Kubernetes pods, which indicates a pivot from pipeline execution to longer-lived footholds. That changes the governance problem from a single compromised build step to a broader trust collapse across deployment targets. The technical lesson is that pipeline identity must be constrained separately from cluster and host identity, or a compromised action can become a bridge into production-adjacent systems.

Practical implication: separate pipeline permissions from cluster administration and monitor for persistence techniques that indicate CI/CD compromise has crossed into runtime infrastructure.

Threat narrative

Attacker objective: The attacker aimed to harvest pipeline secrets and turn CI/CD trust into broader cloud and Kubernetes access.

1. Entry occurred through compromised Git tags in the Checkmarx/kics-github-action repository, causing pinned workflows to run attacker-controlled setup.sh code.
2. The malicious payload stole cloud credentials, SSH keys, Kubernetes service account tokens, and other workflow secrets from the CI/CD environment.
3. The attacker attempted persistence by using stolen access for a systemd backdoor and privileged Kubernetes pod deployment where cluster credentials were available.
4. Impact included exposure of CI/CD secrets and the possibility of follow-on compromise across cloud, container, and deployment environments.

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).
• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.

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

Version tags are not a governance boundary when the repository can be poisoned. CI/CD teams often treat semantic tags as a safe compromise between usability and control, but this case shows that a mutable tag is only as trustworthy as the repository’s release integrity. The named failure mode here is tag-based trust without immutable provenance, which leaves pipelines exposed to code substitution at execution time. Practitioners should treat release references as part of the trust model, not just a developer convenience.

CI/CD secrets have a shorter effective lifespan than most organisations assume. Once a workflow can execute attacker-controlled code, the exposure window is measured in the time it takes to run the job, not in the time it takes to detect the compromise. That makes classic secret rotation necessary but insufficient if the same credentials remain accessible to the same class of workflow. The deeper governance issue is secret availability at runtime, not only secret storage location.

Pipeline compromise is now an identity problem, not only a DevOps problem. The article shows workload credentials, service account tokens, and deployment permissions converging in one execution environment. That is exactly where NHI governance becomes relevant, because CI/CD actions behave like non-human identities with delegated authority. Teams that do not inventory, scope, and revoke these identities will keep treating supply chain incidents as isolated events when they are actually identity failures.

Container and cluster controls inherit the blast radius of pipeline trust. Privileged Kubernetes pod deployment and persistence attempts show how quickly build-time compromise can become runtime compromise. That means the control gap is not just vulnerable code in the action, but excessive downstream authority in the environments the pipeline can reach. NHI governance, least privilege, and deployment segregation have to be aligned or the pipeline becomes a standing bridge into production.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

CI/CD compromise should now be treated as an identity governance problem as much as a software supply chain problem. When a workflow can inherit deployment and cloud authority, the real control boundary is the secret-bearing runtime, not the repository reference alone.

Pipeline trust boundary collapse: the main lesson is that mutable release references, runner memory exposure, and downstream deployment permissions form one governance surface. Teams should separate those layers and review them together rather than assuming source control, build, and runtime controls are independent.

The 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools according to the Ultimate Guide to NHIs, which is why compromise of a single reusable action can have system-wide consequences.

For practitioners

• Replace tag-pinned actions with immutable commit SHAs Inventory every reusable GitHub Action and replace version tags with verified commit SHAs so the referenced code cannot change behind a release label.
• Rotate all pipeline-accessible secrets after action compromise Treat cloud credentials, SSH keys, Kubernetes tokens, API keys, GitHub PATs, and registry credentials as exposed wherever the compromised action had access.
• Reduce secret exposure on CI/CD runners Scope each job to the minimum credentials it needs and remove any standing access to secrets that are not required for that execution path.
• Monitor runners and clusters for persistence behaviour Look for unexpected systemd changes, privileged pod creation, or other post-execution persistence indicators that suggest pipeline credentials were reused outside the job.

Key takeaways

• This compromise shows how a single poisoned Git tag can convert a trusted CI/CD action into an attacker-controlled execution path with broad secret exposure.
• The article ties the compromise to cloud credentials, SSH keys, Kubernetes tokens, and persistence attempts, which makes the blast radius far wider than a routine package issue.
• Immutable references, reduced secret scope, and stronger runtime containment are the controls that materially shrink the impact of pipeline supply chain abuse.

Key terms

• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
• CI/CD Runner Memory Theft: CI/CD runner memory theft is the extraction of secrets, tokens, or sensitive build data from a pipeline runner while it is executing jobs. It typically targets process memory, environment variables, cached files, or temporary artifacts. The risk is that ephemeral automation can still expose credentials long enough for reuse, lateral movement, or supply chain compromise.
• Workflow Identity: A workflow identity is the non-human identity represented by an automated CI/CD process when it authenticates, accesses secrets, or performs actions in other systems. In practice, it is the authority carried by the pipeline itself, and it must be governed with explicit scope, review, and revocation.
• Supply Chain Persistence: Supply chain persistence is the ability of an attacker to remain active by abusing trusted software distribution paths rather than staying on one host. It often relies on repeated publication, compromised maintainer access, or reusable automation secrets that let the attacker keep reintroducing malicious artifacts.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners connect pipeline trust, privilege, and lifecycle control across modern environments.