TeamPCP Just Backdoored Checkmarx for the Third Time in Three Months
TeamPCP compromised the Checkmarx Jenkins AST Plugin on May 9, the third attack on Checkmarx in three months. The Dune-themed defacement reads "Checkmarx fails to rotate secrets again." Either secrets rotation was incomplete or TeamPCP retained access through an unremediated persistence mechanism.
Three Checkmarx compromises in three months. Either the secrets rotation was incomplete — as TeamPCP publicly accuses — or the group retained access through a persistence mechanism the security vendor failed to identify during its March incident response. Either explanation is worse than a one-off breach.
TEL AVIV, ISRAEL — Checkmarx disclosed on May 9, 2026 that a modified version of its Jenkins AST Plugin had been published to the Jenkins Marketplace as part of a supply chain attack — the third TeamPCP compromise of Checkmarx in three months. The compromised plugin version 2026.5.09 was backdoored and would have given attackers access to any Jenkins runner credentials accessible during build operations: GitHub tokens, AWS, GCP, and Azure credentials, Kubernetes configurations, Docker credentials, SSH keys, and API keys stored in environment variables. The latest clean version published by Checkmarx is 2.0.13-848.v76e89de8a_053, available on GitHub and the Jenkins Marketplace; the pre-compromise safe version is 2.0.13-829.vc72453fa_1c16 published December 17, 2025.
TeamPCP also defaced the Checkmarx Jenkins AST Plugin's GitHub repository, renaming it to "Checkmarx-Fully-Hacked-by-TeamPCP-and-Their-Customers-Should-Cancel-Now" with the description "Checkmarx fails to rotate secrets again. with love – TeamPCP." The compromised cx-plugins-releases GitHub account bore Dune-themed repository names — kralizec-navigator-709, tleilaxu-thumper-952, ghola-cogitor-195, fedaykin-laza-800, mentat-navigator-124 — with the consistent description "A Mini Shai-Hulud has Appeared," TeamPCP's signature operational fingerprint across multiple campaigns. Checkmarx attributes the current intrusion to credentials originally compromised through the March 23, 2026 Trivy Supply Chain Attack — part of the broader pattern documented across TeamPCP and PCPJack cloud worm tradecraft and the cumulative 2026 supply chain trust crisis.
What the backdoored plugin does
The Jenkins AST plugin is installed specifically to improve the security of build pipelines — integrated into CI/CD workflows to scan code for vulnerabilities before deployment. A backdoored version inverts that security posture: the plugin runs with the same Jenkins runner privileges as the legitimate version, which on most installations means access to source code being built, environment variables containing secrets, cloud provider credentials used for deployment, and Kubernetes configurations used to apply changes. SOCRadar summarized the operational trust problem cleanly in its coverage: a backdoored security plugin doesn't just compromise one project; it rides trusted infrastructure into every build pipeline it touches, with access to whatever secrets the runner can see.
The Checkmarx plugin had been installed by several hundred Jenkins controllers at the time of the disclosure. The Marketplace listing initially still showed version 2026.5.09 as the most recently available release, though pull requests filed Monday morning indicated it would be pulled down. Any Jenkins instance that pulled the compromised version during the exposure window should be treated as potentially compromised, regardless of whether the plugin has since been downgraded or replaced.
The three-month pattern this extends
TeamPCP first compromised Checkmarx infrastructure in March 2026, gaining access through the Trivy supply chain attack of March 23. That access enabled the group to push malicious code to checkmarx/ast-github-action and checkmarx/kics-github-action, deploying credential-stealing payloads that harvested CI runner secrets. Data exfiltrated from Checkmarx GitHub repositories was subsequently published on the dark web by the Lapsus$ extortion group in late April. In April, TeamPCP returned with a second wave targeting Checkmarx KICS Docker Hub images and two VS Code extensions — ast-results and cx-dev-assist — on the OpenVSX marketplace, with adjacent compromise of the Bitwarden CLI npm package through a similar GitHub Actions vector.
The Jenkins AST Plugin compromise on May 9 makes three Checkmarx incidents in three months. The Hacker News quoted SOCRadar's framing of the operational question: either the initial remediation was incomplete and credentials were not fully rotated, or the group retained a foothold that wasn't identified during the March response. A second Checkmarx incident happening this soon suggests the group is actively watching for re-entry points, testing the depth of past remediations, and capitalizing on any gaps.
What gets stolen from a compromised Jenkins runner
The Jenkins runner environment is one of the highest-value credential locations in most modern enterprises. A typical runner has access to GitHub personal access tokens or app credentials for source code access, cloud provider credentials for AWS, GCP, or Azure deployment, Kubernetes service account tokens or kubeconfig files for cluster deployment, Docker registry credentials, SSH keys for server access, and any API keys stored in Jenkins credentials stores or .env files mounted into build environments. A compromised plugin running inside the build process can read every one of these, exfiltrate them, and use them for lateral movement into the customer's production environment.
The cumulative compromised Checkmarx artifact list across all three attacks: checkmarx/ast-github-action (versions 2.3.35 and below; safe at 2.3.36); checkmarx/kics-github-action; ast-results VS Code extension (versions 2.63 and 2.66; safe at 2.64.0); cx-dev-assist VS Code extension (versions 1.17 and 1.19; safe at 1.18.0); checkmarx/kics Docker Hub images (multiple tags archived); and the Jenkins AST Plugin (version 2026.5.09; safe at 2.0.13-829.vc72453fa_1c16 or 2.0.13-848.v76e89de8a_053).
The known C2 domains and what to block
Checkmarx's incident guidance identifies two malicious domains used in the campaign: audit.checkmarx[.]cx, resolving to 94.154.172[.]43, and checkmarx[.]cx, resolving to 91.195.240[.]123. Both should be blocked at the egress layer for any Jenkins runner or CI/CD environment that may have pulled the compromised plugin. SOCRadar's additional defender guidance recommends auditing Jenkins build logs for outbound traffic to unknown domains and searching GitHub organizations for Dune-themed repository names (kralizec-, tleilaxu-, ghola-, fedaykin-, mentat-*), which can indicate fallback exfiltration activity from the TeamPCP campaign infrastructure.
The CyberSignal Analysis
Signal 01 — Vendor breach persistence is a documented risk class now
Three Checkmarx compromises in three months establishes vendor breach persistence as a documented pattern, not a one-off incident. The right operational response is not to wait for Checkmarx to demonstrate that its remediation is complete; the right response is to treat any Checkmarx artifact published after March 23, 2026 as potentially compromised until verified otherwise. Pin to known-good SHAs, validate checksums before deployment, and assume the next compromise is in the pipeline.
Signal 02 — Pinned SHAs and signed manifests are no longer optional for security tooling
The defensible CI/CD practice for security scanning tools specifically is pinned SHA references rather than version tags, with signed manifest validation before any plugin or container is loaded into a build pipeline. The TeamPCP campaign's defining tradecraft is force-pushing version tags to malicious imposter commits while preserving original metadata — a technique that defeats version-string trust but is blocked by SHA pinning. Implement this for every security tool in your CI/CD this week, not just Checkmarx.
Signal 03 — Vendor concentration risk is now a board-level question
Organizations heavily dependent on a single security scanning vendor are exposed to breach persistence across multiple product lines from that vendor. The TeamPCP-Checkmarx pattern demonstrates concretely what this looks like in practice: GitHub Actions, Docker images, VS Code extensions, and Jenkins plugins all compromised through related access. Brief boards on the concentration risk in your security tooling, and consider diversification for critical security infrastructure where single-vendor dependence creates persistent exposure.
What to do this week
- Audit your Jenkins plugin versions. Check whether version 2026.5.09 of the Checkmarx Jenkins plugin was installed in any of your Jenkins instances. If yes, treat that Jenkins environment as potentially compromised and rotate all secrets accessible from affected runners: GitHub PATs, cloud credentials (AWS, GCP, Azure), Kubernetes tokens, Docker credentials, SSH keys, and any API keys stored in environment variables or Jenkins credentials stores.
- Block outbound traffic from Jenkins runners and CI/CD environments to audit.checkmarx[.]cx (94.154.172.43) and checkmarx[.]cx (91.195.240.123). Add these to your egress monitoring and DNS blocklists, and look back 30 days for any prior outbound connections.
- Downgrade affected Jenkins installations to safe version 2.0.13-829.vc72453fa_1c16 (December 17, 2025) until you can verify the new clean release 2.0.13-848.v76e89de8a_053 in your environment.
- Search your GitHub organizations for Dune-themed repository names — kralizec-, tleilaxu-, ghola-, fedaykin-, mentat-* — which could indicate TeamPCP fallback exfiltration activity. Their presence is a high-confidence indicator of compromise.
- For broader Checkmarx exposure: audit your direct Checkmarx product usage across the cumulative compromised artifacts (Jenkins AST Plugin, KICS Docker images, VS Code extensions ast-results and cx-dev-assist, GitHub Actions checkmarx/ast-github-action and checkmarx/kics-github-action). Engage Checkmarx for a comprehensive security posture review if your organization is heavily dependent on Checkmarx tooling.
