"If you are using Checkmarx Jenkins AST plugin, you need to ensure that you are using the version 2.0.13-829.vc72453fa_1c16 that was published on December 17, 2025 or previously," Checkmarx said in a statement over the weekend.
Checkmarx confirmation, versions, and public remediation steps
Checkmarx confirmed that a modified version of the Jenkins AST plugin was published to the Jenkins Marketplace and advised users to rely on a specific older build. The company directed users to version 2.0.13-829.vc72453fa_1c16 — the build published on December 17, 2025 or earlier — as the safe baseline. Separately, Checkmarx has released 2.0.13-848.v76e89de8a_053 on both GitHub and the Jenkins Marketplace; its incident update, however, still notes it is "in the process of publishing a new version of this plugin." In its public advisory, Checkmarx did not disclose how the malicious plugin version was published.
Repository defacement and claimed access by TeamPCP
Security researcher Adnan Khan and SOCRadar reported that TeamPCP gained unauthorized access to the plugin's GitHub repository and renamed it to "Checkmarx-Fully-Hacked-by-TeamPCP-and-Their-Customers-Should-Cancel-Now." The intruders also updated the repository description to read: "Checkmarx fails to rotate secrets again. with love – TeamPCP." Those changes indicate an explicit, visible claim of control over the project workspace in GitHub.
How this fits into TeamPCP's wider supply-chain campaign
This incident is the latest in a string of compromises attributed to TeamPCP. According to the reporting, the activity arrives a matter of weeks after the group was tied to the compromise of Checkmarx's KICS Docker image, two VS Code extensions, and a GitHub Actions workflow that was used to push credential-stealing malware. That earlier breach also briefly compromised the Bitwarden CLI npm package, which was used to serve a similar stealer capable of harvesting a wide range of developer secrets. Security reporting links these events as part of a sprawling campaign exploiting trust in the software supply chain to propagate malware and expand reach.
SOCRadar's assessment: re-entry or incomplete remediation
SOCRadar framed the new intrusion as pointing to one of two possibilities: "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." The firm added: "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." Those observations underscore the challenge of proving a clean environment after a supply-chain compromise and the risk that an attacker will monitor for opportunities to return.
What this means for developers, tool maintainers, and security teams
- Developers and DevOps teams: The public guidance to prefer a specific prior build (2.0.13-829.vc72453fa_1c16) and the rapid release of 2.0.13-848.v76e89de8a_053 signal that teams using the Checkmarx Jenkins AST plugin must validate their installed plugin versions against these exact strings and follow Checkmarx's patch guidance.
- Tool maintainers and open-source project owners: The reported repository rename and description change illustrate how visible claims of compromise can occur within hosted code repositories. Maintain rigorous access controls, audit logs, and credential rotation as primary defenses; publicly, attackers may use defacements to advertise access and undermine trust.
- Security operations teams: SOCRadar's assessment suggests defenders should treat a rapid, repeating incident as evidence to assume potential persistent access. Thoroughly verify remediation steps — including credential rotation and detection of any lingering footholds — rather than relying solely on single remediation events.
Checkmarx has moved to publish a new plugin release, but it has not explained how the malicious version was introduced. That omission — together with TeamPCP's visible return and the earlier KICS, VS Code, GitHub Actions, and Bitwarden CLI incidents — leaves a narrow but concrete set of operational questions for defenders: were credentials or processes the weak link, or did an undetected persistent presence remain after the March response? The answer will determine whether the latest release closes the door or merely changes the locks.
