Checkmarx supply chain compromise shows CI/CD secret theft risk

At a glance

What this is: This is a supply chain compromise affecting Checkmarx CI/CD tooling that enabled secret theft from pipeline environments through poisoned workflows and malicious extensions.

Why it matters: It matters because CI/CD teams need to treat runner secrets, extension trust, and pipeline execution paths as a single governance surface, not separate controls.

By the numbers:

• A critical supply chain vulnerability, CVE-2026-33634, was disclosed with a CVSS score of 9.4.
• The affected Checkmarx components include ast-github-action, kics-github-action, ast-results v2.53.0, and cx-dev-assist v1.7.0.

Context

Checkmarx supply chain compromise is a CI/CD secret theft problem, not just a software vulnerability story. The article describes poisoned workflows and malicious extensions that can harvest credentials during pipeline execution, which means trust boundaries around build and scan steps are being crossed in real time.

For identity and access teams, the issue sits at the junction of secrets management, workload identity, and third-party pipeline dependencies. Once trusted actions or extensions can execute inside a runner, the control question shifts from whether credentials exist to whether they can be exposed, copied, and reused before the pipeline finishes.

Key questions

Q: What happens when a trusted CI/CD workflow is compromised through a malicious or broken action?

A: A compromised workflow can exfiltrate secrets, tamper with build outputs, or propagate bad code through downstream releases before the issue is detected. Because CI/CD often has broad access to repositories and deployment credentials, one abused action can become an entry point into multiple systems. The practical response is to combine detection, baseline review, and tighter egress control.

Q: Why do stolen CI/CD secrets create lateral movement risk?

A: CI/CD secrets often authenticate to cloud services, deployment targets, and repository systems that are broader than the original build job. If an attacker reuses those credentials, they can move from one pipeline to adjacent repositories or infrastructure. The risk is high when the secret is valid outside the original execution context.

Q: How can security teams tell whether a pipeline compromise is still dangerous after patching?

A: If affected runners, workflows, or extensions previously handled secrets, the environment should still be treated as exposed until credentials are rotated and untrusted components are removed. Patching the vulnerable component closes one path, but it does not prove the stolen secrets were never copied. Exposure assessment has to continue after remediation.

Q: What should teams do after a CI/CD supply chain compromise involving secrets theft?

A: Contain the affected pipeline, revoke and replace any credentials that may have been exposed, and verify that malicious actions or extensions are no longer installed. Then review which repositories, deploy targets, and cloud services those credentials could reach so the incident response matches the actual blast radius.

Technical breakdown

How poisoned CI/CD updates steal secrets during execution

The compromise uses trusted delivery channels, including GitHub Actions and OpenVSX extensions, to deliver malicious code inside the pipeline context. That matters because secrets are often present in runner memory, filesystem paths, environment variables, and cached tool state while the job executes. A malicious step does not need to break authentication if it can inherit the pipeline's already-authorised runtime context. In practice, the attack converts normal automation into a credential collection point, especially where build and security-scanning steps share the same execution environment.

Practical implication: Treat pipeline execution as a credential-exposure zone and constrain what secrets are mounted into runner jobs.

Why CI/CD runners create lateral movement potential

CI/CD runners frequently hold cloud tokens, deployment credentials, and repository write access, so a single compromise can move from code delivery into broader infrastructure access. When stolen secrets are reusable beyond the pipeline, the attacker can pivot across repositories, deployment targets, and connected services. This is why supply chain compromise often becomes lateral movement: the initial objective is not the code itself, but the trust relationships embedded in the delivery path. The article's emphasis on downstream propagation reflects a broader pattern in which one poisoned integration can fan out across many environments.

Practical implication: Segment runner privileges and isolate credentials so compromise of one workflow cannot authenticate to unrelated systems.

Why malicious extensions are an identity problem, not just a software problem

Developer tooling extensions can act as identity-bearing software when they run with access to secrets, tokens, or authenticated sessions. If an extension is trusted at install time but not governed at runtime, the organisation has effectively delegated access without continuous assurance. The article's reference to malicious OpenVSX updates shows how extension trust can become a secret exfiltration path. That moves the issue into NHI governance because the extension, workflow, and runner collectively form a machine identity chain that must be inventoried, authorised, and revoked like any other non-human access path.

Practical implication: Inventory every trusted extension and action that can touch secrets, then remove any that are not essential to build execution.

Threat narrative

Attacker objective: The attacker aims to steal reusable CI/CD credentials and use them to expand control across repositories, build pipelines, and connected production systems.

1. Entry occurs through poisoned GitHub Actions and malicious OpenVSX updates delivered into affected CI/CD environments.
2. Credential access follows when the malicious code harvests secrets from runner memory and filesystem paths during pipeline execution.
3. Escalation and lateral movement occur as stolen cloud credentials and tokens are reused across repositories, infrastructure, and downstream build systems.
4. Impact is pipeline compromise, with possible service disruption, data exposure, and broader infrastructure control.

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

Pipeline trust is an identity assumption, not just an integrity check: This compromise shows that CI/CD systems often assume trusted actions and extensions remain benign for the duration of execution. That assumption fails when malicious code can run inside the same context that holds cloud tokens, signing material, and deployment credentials. The practical conclusion is that trust for pipeline components must be treated as a governed identity relationship, not a one-time installation decision.

Secret exposure in runners is a blast-radius problem: Once credentials are present inside a runner, the question is how far they can travel before the job ends. The article describes harvesting from memory and filesystem paths, which means the effective blast radius includes every environment the token can reach after the initial compromise. Practitioners should read this as a reminder that secret placement, not only secret storage, defines exposure.

Third-party build tooling is part of the NHI estate: Trusted actions and extensions operate with delegated access, and delegated access without lifecycle control is the same governance problem seen in overprivileged service accounts. The difference is that the exposure happens through software distribution rather than direct account provisioning. Identity blast radius: this is the point where one compromised integration can extend into multiple repositories and environments, so practitioners must govern extension trust as part of NHI lifecycle management.

CVSS is not enough for CI/CD remediation priority: The article is explicit that exposure context matters, including internet accessibility, runtime reachability, and asset criticality. That is the right prioritisation model for pipeline compromise because the same vulnerable component can sit on isolated infrastructure or on a path to production deployment. The field needs more risk-based remediation and less dependency on raw severity scores.

Supply chain compromise is now a secrets governance issue: The important failure mode here is not just malicious code delivery, but the capture of credentials that outlive the poisoned workflow. That means secrets rotation, access scope, and release trust have to be managed together. Practitioners should treat every pipeline integration that can read secrets as a governed access path with an explicit owner and removal trigger.

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.
• 74% of organizations report identity-related breaches, and privileged access is a leading cause of lateral movement.
• Read next: Guide to NHI Rotation Challenges

What this signals

Secret exposure is the governing failure mode here: CI/CD environments often look secure at the repository layer while remaining vulnerable at execution time, where credentials are temporarily present in runner memory and filesystem paths. That is why pipeline security needs to shift from static trust to runtime containment, especially when third-party actions can inherit access inside the job.

The practical signal for teams is simple: any build or scanning workflow that can read reusable credentials should be treated like a privileged access path. Once that mindset changes, secrets placement, action pinning, and runner isolation become identity controls, not just DevOps hygiene.

For practitioners

• Rotate exposed pipeline secrets and tokens Assume any credential touched by affected runners, extensions, or workflows is compromised and replace it with fresh credentials that are scoped to the minimum required repositories and services.
• Remove untrusted actions and extensions Inventory every GitHub Action and OpenVSX extension used in build and scanning pipelines, then remove anything that is not essential or cannot be pinned to a trusted release process.
• Separate build secrets from general runner context Stop mounting long-lived cloud credentials into jobs that do not require them, and isolate deployment secrets from scanning or analysis steps wherever possible.
• Prioritise exposure-based remediation Rank affected assets by internet reachability, runtime access, and business criticality rather than by CVSS alone, then remediate the highest blast-radius pipelines first.

Key takeaways

• This compromise shows how trusted CI/CD components can turn pipeline execution into a credential theft path.
• The affected tooling and TeamPCP exploitation demonstrate that the risk is not theoretical and can extend across repositories and infrastructure.
• Rotating exposed secrets, removing untrusted extensions, and narrowing runner access are the controls that reduce the blast radius.

Key terms

• CI/CD secret exposure: CI/CD secret exposure is the accidental or unauthorized disclosure of credentials used by build and deployment pipelines. It includes API keys, tokens, certificates, passwords, and signing material appearing in logs, code, artifacts, environment variables, or pipeline configuration. Exposure creates immediate risk because attackers can impersonate systems, alter releases, or move laterally.
• 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.
• Runner Blast Radius: The amount of access and downstream impact a compromised build runner can create. It includes credentials in memory, secrets in environment variables, and permissions inherited from the workflow, which means a small execution foothold can become a multi-system identity incident.
• Delegated Build Access: Delegated build access is the temporary authority granted to pipeline components, runners, and extensions to perform tasks on behalf of the organisation. For CI/CD environments, the key governance question is whether that delegated access is narrow, observable, and revocable when the job ends.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.