Checkmarx KICS GitHub Action tag compromise exposes CI/CD secrets

At a glance

What this is: All release tags in Checkmarx/kics-github-action were reported compromised with malware that turns tagged workflow references into attacker-controlled code execution.

Why it matters: This matters because CI/CD pipelines often hold the secrets, tokens, and cloud access that let a compromised action become a broad identity and infrastructure incident.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read StepSecurity's analysis of the Checkmarx KICS GitHub Action compromise

Context

CI/CD supply chain compromise happens when trusted build or deployment components are poisoned and then executed as part of normal automation. In this case, a tagged GitHub Action was reported as carrying an infostealer, which means the trust decision was made at reference time rather than at runtime and repository integrity became part of the identity problem for the pipeline.

For IAM, PAM, and NHI teams, the important point is that build systems hold machine credentials with broad reach across cloud, source control, and deployment environments. A poisoned action can turn a routine workflow into credential theft, privilege abuse, and downstream access expansion, so the starting assumption that a pinned tag is safe is not a reliable control model.

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 make secret theft easier for attackers?

A: Pipelines often concentrate cloud keys, package tokens, environment variables, and deployment credentials in one execution path. That concentration gives attackers a single place to harvest multiple NHI types at once. When the pipeline is trusted to run automatically, any malicious workflow update can turn that trust into credential exposure.

Q: How can security teams tell if a pipeline identity is over-permissioned?

A: Look for workflows that can deploy, provision, or administer environments without separate approval, short-lived credentials, or environment-specific scoping. If a single action can access cloud, Kubernetes, and source control secrets, the identity is larger than the job it supports. Over-permissioning shows up where compromise can cross control planes.

Q: Who should be accountable when a poisoned automation action exposes secrets?

A: Accountability should sit with the team that owns the workflow, the identity and access model behind it, and the approval path for external dependencies. Security, platform, and application owners all have a role, but no single team can manage supply chain trust if action provenance, secret scope, and runner isolation are separated.

Technical breakdown

How tag poisoning turns a trusted action into attacker-controlled code

GitHub Actions references can point to mutable version tags, commit SHAs, or branches. When a release tag is retargeted or compromised, every workflow that calls that tag inherits the malicious commit even if the repository still appears normal on the surface. In supply chain attacks, the danger is not only the code in the action itself but the privileges of the runner that executes it. CI/CD environments often expose cloud tokens, deployment keys, and repository credentials to automation, which makes code provenance a control issue, not just a software integrity issue.

Practical implication: treat tagged third-party actions as untrusted references until the exact commit is verified and pinned.

Why runner memory is a high-value target for secret theft

CI/CD runners frequently hold short-lived or long-lived secrets in memory while jobs execute. Malware that reads process memory can capture credentials before they are written to logs, secrets stores, or audit trails. That bypasses controls that focus only on file-based secret protection. In modern pipelines, especially those that invoke infrastructure scanning, deployment, or cloud provisioning, the attack surface includes the ephemeral runtime context where tokens, service account material, and API keys are loaded for automation.

Practical implication: isolate runner execution and minimise the secret footprint available to each job.

How persistence changes a pipeline compromise from theft to ongoing access

The reported payload attempted persistence through systemd backdoors and privileged Kubernetes pods when cluster credentials were available. That pattern matters because a one-time secret theft can become durable access if the attacker can install a foothold in the build or cluster environment. Once the compromised workflow has permission to deploy, the boundary between CI/CD and production identity becomes thin, especially where service accounts, kubeconfig files, and cloud roles are reused across stages.

Practical implication: bind automation identities to narrowly scoped, short-lived permissions and revoke anything exposed to the compromised workflow.

Threat narrative

Attacker objective: The attacker aimed to steal reusable CI/CD secrets and convert pipeline trust into persistent access across cloud and Kubernetes environments.

1. Entry occurred through compromised Git tags in the Checkmarx/kics-github-action repository, so workflows referencing version tags executed attacker-controlled setup.sh code.
2. Credential harvesting targeted cloud provider credentials, SSH keys, Kubernetes service account tokens, and secrets resident in CI/CD runner memory.
3. Escalation and persistence were attempted through encrypted exfiltration to an attacker domain, a systemd backdoor, and privileged Kubernetes pods where cluster access was available.
4. Impact was potential broad compromise of CI/CD secrets and downstream cloud, container, and deployment access controlled by those credentials.

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

Tag pinning is not a provenance control if the tag itself can be poisoned. This incident shows that many CI/CD teams still trust a mutable reference as though it were an immutable artifact. The governance gap is not just secret storage, but the assumption that a named version tag represents the same code over time. For pipeline identity, provenance needs commit-level verification and controlled release workflows, not just convenient references.

CI/CD runners should be treated as high-value non-human identities, not disposable build workers. The compromised action targeted credentials in memory and at runtime, which is exactly where machine identity controls become critical. When runners can access cloud roles, container registries, and Kubernetes tokens, they function as privileged identities with their own lifecycle, scope, and revocation requirements. Practitioners should govern runner access like any other NHI estate.

Secret theft becomes materially worse when automation identities are reused across environments. A poisoned action is often only the first step. The real risk appears when the stolen material can reach cloud control planes, deployment tooling, and cluster administration without additional verification. This is where least privilege, workload identity, and short-lived credentials converge into one control plane for machine access.

Pipeline compromise is now an identity governance problem as much as a software supply chain problem. That matters because security teams often split responsibility between DevOps, cloud, and IAM groups. The attacker does not respect those boundaries. Organisations need a single governance view for actions, runners, service accounts, and the secrets those components can touch.

Ephemeral execution does not eliminate standing privilege if the workflow identity remains over-permissioned. The attack demonstrates a named concept we would call pipeline trust collapse: a short-lived job inherits enough authority to become a durable breach path. Once trust collapses at the automation layer, downstream access controls only limit damage if they are already scoped and isolated.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• From our research: Internal repositories are 6x more likely to contain secrets than public ones, with 32.2% versus 5.6% prevalence, according to The State of Secrets Sprawl 2026.
• From our research: Review our Guide to the Secret Sprawl Challenge for the operational patterns behind secret exposure, rotation, and revocation.

What this signals

The next control question is not whether a workflow uses GitHub Actions, but whether the workflow identity can be proven, constrained, and revoked like any other privileged machine account. That means treating runners, action references, and deployment tokens as a governed identity surface, not as implementation detail. The OWASP Non-Human Identity Top 10 is a useful lens here, especially where secret lifecycle and overprivilege intersect with supply chain trust.

Pipeline trust collapse: when a mutable action reference becomes the compromise point, the security boundary shifts from code review to runtime identity control. Teams should expect more attacks that target runner memory, action provenance, and downstream cloud roles rather than the application code itself.

Supply chain incidents of this kind also reinforce the case for strict secret revocation and short-lived credentials in automation. If a pipeline can be poisoned once and retain access long enough to matter, then the secret lifecycle is already too permissive for modern CI/CD risk.

For practitioners

• Disable tag-based trust for third-party GitHub Actions Replace version-tag references with verified full commit SHAs for all external actions, and revalidate those SHAs whenever a workflow changes. Where possible, allow only approved action sources through repository policy controls.
• Rotate every credential exposed to CI/CD jobs Assume cloud provider credentials, SSH keys, Kubernetes tokens, database credentials, API keys, Docker registry credentials, and GitHub PATs used by affected workflows are compromised and rotate them immediately.
• Shrink runner privilege to the minimum deployment path Separate build, scan, and deploy identities so a poisoned action cannot reach production-grade roles. Use short-lived credentials, isolated runners, and environment-specific service accounts with explicit approval gates.
• Inspect for persistence in build and cluster layers Search for systemd services, suspicious Kubernetes pods, unexpected service account bindings, and unusual outbound connections from CI/CD infrastructure to attacker-controlled domains.

Key takeaways

• This incident shows that CI/CD trust can fail at the reference layer, where version tags are treated as if they were immutable and safe.
• The scale of secret exposure in modern Git workflows means a single compromised action can convert into cloud, Kubernetes, and deployment access.
• The limiting control is not only detection but identity governance for automation, including commit pinning, scoped runners, and rapid secret revocation.

Key terms

• GitHub Action Tag Poisoning: A supply chain attack where a version tag that should point to trusted code is retargeted or compromised so workflows execute malicious content. The danger comes from treating a mutable label as a stable security boundary, especially when the action runs with privileged automation access.
• CI/CD runner: A CI/CD runner is the execution environment that performs build, test, or deployment jobs. It often has access to source code, tokens, and cloud credentials, which makes it a high-value identity surface when workflows are compromised.
• Pipeline Trust Gap: The mismatch between the trust a build or release system is given and the level of identity governance it actually receives. It appears when CI/CD accounts, signing identities, and automation tokens can change production outcomes without the monitoring, scope limits, or lifecycle controls usually reserved for privileged access.
• Machine identity lifecycle: Machine identity lifecycle is the full governance process for a non-human identity from creation to retirement. It includes provisioning, access scoping, rotation, renewal, offboarding, and auditability, and it fails when any one of those steps is handled manually or inconsistently.

What's in the full analysis

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

• Timeline detail on how the compromised Git tags were identified and why the repository state mattered for workflow execution.
• The exact malicious behaviour observed in setup.sh, including credential theft, memory dumping, and encrypted exfiltration paths.
• Indicators to help teams check for exposure in CI/CD runners, Kubernetes pods, and cloud credentials used by affected workflows.
• The original advisory context and update notes for teams tracking remediation status and repository recovery.

👉 The full StepSecurity post covers the attack chain, exposed secret types, and immediate workflow changes to make.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and identity lifecycle controls. It helps practitioners build the governance model that automation-heavy environments now require.