Supply Chain Compromises: TeamPCP’s Latest Jenkins AST Plugin Takedown Targets Checkmarx Users
The software supply chain continues to be a high-value attack surface, and TeamPCP is proving it knows exactly how to exploit it.
Just weeks after a series of coordinated compromises across Checkmarx’s developer tooling, the threat actor has resurfaced with a modified Jenkins AST plugin now live on the Jenkins Marketplace. For development teams relying on static application security testing (SAST) pipelines, this isn’t just another vendor alert—it’s a direct injection point into CI/CD workflows.
Pin Your Versions: The Immediate Jenkins AST Risk
Checkmarx has issued an urgent advisory for users of the Jenkins AST plugin, recommending an immediate rollback to version 2.0.13-829.vc72453fa_1c16 (released December 17, 2025) or any earlier build. While a newer artifact—<2.0.13-848.v76e89de8a_053—has appeared on both GitHub and the Jenkins Marketplace, the vendor’s incident response notes that a fully vetted replacement is still being published.
The exact vector through which the malicious version was uploaded remains unconfirmed, but the implications are clear: any pipeline pulling the compromised artifact could be executing unauthorized code during the build phase.
The Jenkins AST plugin serves as a bridge between Jenkins automation servers and Checkmarx One’s scanning engine. When tampered with, these plugins often inject credential harvesters, reverse shells, or data exfiltration routines directly into the build environment. Because Jenkins jobs typically run with elevated privileges and access to repository secrets, a compromised plugin effectively hands threat actors a master key to your codebase and infrastructure.
Teams should verify plugin checksums against official vendor signatures and avoid dynamic version resolution for critical pipeline components.
Mapping TeamPCP’s March Campaign
This latest intrusion is the newest chapter in a sprawling supply chain campaign that TeamPCP has been orchestrating since March 2026.
The group’s playbook is methodical: identify trusted developer tools, compromise their distribution channels, and embed credential-stealing payloads that harvest secrets across multiple environments. Their recent footprint includes the compromise of Checkmarx’s KICS Docker image, two VS Code extensions, and a GitHub Actions workflow designed to push malware into downstream repositories.
That chain reaction briefly compromised the Bitwarden CLI npm package, transforming a legitimate password manager utility into a vector for harvesting developer secrets, API keys, and cloud credentials.
Security researcher Adnan Khan and the threat intelligence team at SOCRadar have documented how the group leverages the inherent trust developers place in package managers and marketplace listings to bypass traditional perimeter defenses. By operating inside the supply chain, TeamPCP doesn’t need to breach your firewall—they just need you to pull their code.
Why the Second Breach Signals Deeper Vulnerabilities
What makes this Jenkins incident particularly concerning isn’t just the technical execution, but what it reveals about Checkmarx’s incident response. As SOCRadar noted, the rapid recurrence points to two likely scenarios: either the initial remediation left residual credentials active, or the threat actor maintained a persistent foothold that evaded detection during the March cleanup.
From a technical standpoint, this suggests gaps in credential rotation workflows, insufficient monitoring of administrative access, or inadequate isolation between compromised and production environments. Threat actors like TeamPCP actively probe for re-entry points, testing the depth of past remediations and capitalizing on any misconfigured access controls.
When a vendor’s GitHub repository was defaced with the message “Checkmarx fails to rotate secrets again. with love – TeamPCP,” it wasn’t just a taunt—it was a public admission that secret management practices were either bypassed or left stale. Organizations should treat repeated vendor compromises as indicators of systemic access control failures rather than isolated incidents.
Hardening CI/CD Against Supply Chain Intrusions
For DevSecOps teams, this incident reinforces several non-negotiable practices for securing modern development pipelines:
- Version Pinning & Checksum Verification: Never rely on dynamic version resolution for critical plugins. Pin to known-good hashes and verify artifacts against official vendor signatures before installation.
- Marketplace & Repository Monitoring: Subscribe to vendor security advisories and monitor GitHub repositories for unauthorized commits, description changes, or sudden version bumps. Jenkins’ own documentation emphasizes strict artifact provenance checks.
- Least-Privilege Pipeline Execution: Run Jenkins jobs with restricted service accounts, isolate secret storage, and enforce mandatory approval gates for plugin updates.
- Continuous Secret Rotation: Treat all credentials as ephemeral. Implement automated rotation policies and audit access logs for anomalous token usage or unexpected API calls.
- SBOM & Dependency Scanning: Maintain a Software Bill of Materials for your CI/CD toolchain and scan for known vulnerabilities or supply chain anomalies using tools like Syft or Grype.
The landscape of supply chain attacks is shifting from opportunistic malware drops to targeted, persistent intrusions designed to linger and expand. TeamPCP’s repeated access to Checkmarx’s ecosystem demonstrates how quickly trust can be weaponized when development tooling isn’t treated with the same rigor as production infrastructure.
Staying Ahead of the Next Injection
As development teams continue to integrate more third-party plugins, extensions, and workflow automations, the attack surface grows exponentially.
The Jenkins AST compromise serves as a stark reminder that security isn’t just about scanning your application code—it’s about securing the tools that scan it. By enforcing strict version controls, auditing pipeline permissions, and treating every marketplace artifact as untrusted until verified, organizations can significantly reduce their exposure to supply chain intrusions.
Keep your CI/CD environments monitored, your secrets rotated, and your plugin repositories locked down. The next compromise won’t wait for a security bulletin to drop, and the teams that survive it will be the ones that treat their build pipelines as critical infrastructure from day one.