TL;DR: A compromised Checkmarx/kics-github-action release-tag supply chain attack injected an infostealer into setup.sh, targeting cloud credentials, SSH keys, Kubernetes tokens, and runner memory, according to StepSecurity. Version-tag pinning in CI/CD is a trust boundary failure, not a convenience feature.
NHIMG editorial — based on content published by StepSecurity covering the Checkmarx KICS GitHub Action compromise: malware injected in all Git tags
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
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.
👉 Read StepSecurity's analysis of the Checkmarx KICS GitHub Action compromise →
Checkmarx KICS tag poisoning: what CI/CD teams need to do now?
Explore further
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.
A few things that frame the scale:
- 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.
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Checkmarx KICS GitHub Action tag compromise exposes CI/CD secrets