TeamPCP Breaches Checkmarx Jenkins Plugin Weeks After Initial Compromise

Checkmarx confirmed over the weekend that TeamPCP successfully published a compromised version of its Jenkins AST plugin to the Jenkins Marketplace, marking the cybercrime group's second breach of Checkmarx infrastructure in less than a month. Organizations using the Jenkins AST plugin must immediately verify they are running version 2.0.13-829.vc72453fa_1c16 published on December 17, 2025, or earlier versions. Checkmarx has since released version 2.0.13-848.v76e89de8a_053 to both GitHub and the Jenkins Marketplace, though the company's incident update indicates publication is still in progress.

Attack Timeline and Scope

This compromise follows TeamPCP's March 2026 attack on Checkmarx's KICS Docker image, two VS Code extensions, and a GitHub Actions workflow. That initial breach delivered credential-stealing malware and briefly compromised the Bitwarden CLI npm package. The speed of this second intrusion—occurring just weeks after the initial incident—raises critical questions about the completeness of Checkmarx's remediation efforts.

Security researcher Adnan Khan and SOCRadar documented that TeamPCP gained unauthorized access to the plugin's GitHub repository, renaming it to 'Checkmarx-Fully-Hacked-by-TeamPCP-and-Their-Customers-Should-Cancel-Now.' The attackers added a pointed message: 'Checkmarx fails to rotate secrets again. with love – TeamPCP.' This public defacement demonstrates not just technical capability but strategic messaging aimed at damaging target reputation.

Persistent Access or Incomplete Remediation

SOCRadar's analysis identifies two probable scenarios for TeamPCP's rapid re-entry. Either Checkmarx's initial remediation was incomplete with credentials inadequately rotated, or TeamPCP maintained an undetected foothold from the March breach. The attackers' taunt about failed secret rotation suggests the former, though both possibilities indicate serious gaps in incident response procedures.

The fact that TeamPCP successfully published malicious code to the Jenkins Marketplace indicates compromise of credentials with significant publishing privileges. This level of access requires either direct compromise of maintainer accounts or exploitation of automated publishing workflows—both scenarios that should have been addressed during initial remediation.

TeamPCP's Broader Campaign

TeamPCP has orchestrated a series of supply chain attacks since March 2026, exploiting the inherent trust in software development toolchains. Their campaign demonstrates sophisticated understanding of developer workflows and targets high-value components in the DevSecOps pipeline. By compromising security tooling specifically, they position themselves to harvest credentials from organizations implementing security best practices.

The group's selection of targets—Docker images, VS Code extensions, GitHub Actions workflows, and now Jenkins plugins—reveals strategic focus on automation and CI/CD infrastructure. These components typically operate with elevated privileges and access sensitive credentials, making them force multipliers for credential harvesting operations.

What Checkmarx Has Not Disclosed

Checkmarx has not publicly disclosed the attack vector used to publish the malicious plugin version. The company has not detailed which credentials were compromised, how long the malicious version was available, or how many organizations downloaded the compromised plugin. This lack of transparency complicates response efforts for affected organizations and prevents the broader security community from learning from the incident.

The company also has not addressed the implications of TeamPCP's claim about failed secret rotation. If accurate, this suggests fundamental problems with their credential management and incident response processes—particularly concerning for an organization providing security tooling to enterprises.

Recommendations for Security Teams

• Immediately audit all Checkmarx Jenkins AST plugin installations and verify version numbers against the December 17, 2025 baseline
• Rotate all credentials that may have been accessible to systems running potentially compromised plugin versions
• Review Jenkins plugin update mechanisms and implement controls requiring manual approval for security-critical plugins
• Implement supply chain verification including checksum validation and signed artifact verification for all CI/CD components
• Establish monitoring for unusual credential usage patterns and API calls from CI/CD infrastructure
• Document and test credential rotation procedures with specific timelines for completion after security incidents
• Evaluate alternatives to consolidating multiple security tools from single vendors to reduce concentrated supply chain risk

Implications for Supply Chain Security

This incident demonstrates that even security-focused vendors face supply chain compromise. The two-week timeframe between incidents suggests attackers are actively monitoring remediation efforts and testing for incomplete responses. Organizations cannot rely on vendor security alone and must implement verification mechanisms for all external dependencies, regardless of vendor reputation.

The targeting of Jenkins Marketplace specifically highlights vulnerabilities in plugin ecosystems. These centralized distribution channels represent single points of failure that, when compromised, enable rapid propagation of malicious code. Security teams should reassess trust models for plugin repositories and implement additional verification layers before deploying updates to production environments.