Jenkins remains one of the most popular CI/CD platforms, so its integration with security tools like Checkmarx’s AST scanner makes it attractive to hackers. Recently, Checkmarx disclosed that a modified version of their Jenkins AST plugin had been published to the official Jenkins Marketplace. This “rogue” release (version 2026.5.09) was not built via the normal pipeline: it lacked any GitHub release or tag and used an unusual date-based version string. Within days, Checkmarx urged users to revert to the last known safe build (2.0.13-829 from Dec. 2025) and warned that any secrets accessed with the malicious plugin should be considered compromised.
TeamPCP Launches Broad Supply-Chain Attack Campaign
Compromised plugin connected with TeamPCP, an international cybercrime organization that is behind a series of attacks against developer tools. The breach of Checkmarx represents the third part in a supply chain series of attacks initiated in late March 2026 by TeamPCP:
- Mar 2026 (Trivy): backdoored Aqua Security’s Trivy vulnerability scanner to steal Trivy credentials for Checkmarx GitHub access.
- Apr 2026 (KICS): maliciously distributed Checkmarx KICS scanner that scans the security of Infrastructure as Code. The Trojan reportedly stole information from development environments.
- May 9, 2026 (Jenkins): Checkmarx AST Scanner (2026.5.09) plugin compromised in Jenkins’ update center through an infostealer credential thief planted inside it.
The intruder is said to have posted a message on Checkmarx’s GitHub: “Checkmarx fails to rotate secrets again… With love – TeamPCP.” Methods match: exploit trusted pipeline to deploy malware (often “Shai-Hulud” worm self-propagation technique) and target credentials of developers. TeamPCP was also associated with attacks against the npm Bitwarden CLI and PyTorch Lightning packages.
Supply Chain Infiltration
Signs of a Rogue Plugin Release
These clues helped confirm the backdoor. Checkmarx’s advisory makes clear that any installations of version 2026.5.09 should be considered compromised, and that only versions 2.0.13-829 or earlier (released Dec. 2025) are safe.
Some of the warning signs of the suspicious Jenkins plugin included:
- No official release artifacts: The build was uploaded directly to the repo without going through GitHub Actions or other publishing tools.
- Unfamiliar versioning: Legitimate plugins used a
revision-changelistscheme (e.g.2.0.13-848.v76e89de8a_053), but this one was date-coded. - Forensics preserved: Jenkins engineers archived the URLs and checksums for the malicious files to analyze the breach.
All of these findings provided sufficient information for detecting a backdoor. It can be seen from the Checkmarx advisory that any package beyond version 2026.5.09 should be treated as compromised. Versions 2.0.13-829 and below released on December 2025 are secure.
Credential-Stealing Malware Payload
The term “infostealer” means malware that secretly harvests sensitive data (passwords, keys, tokens) from an infected machine. In this case, the compromised plugin was designed to drop such a payload into every Jenkins build that ran it. While Checkmarx has not detailed the exact code, users should assume all credentials accessible during a scan were stolen. Checkmarx thus recommends rotating every secret that might have been exposed.
This scenario mirrors other recent breaches. For example, the PyTorch Lightning package hack in May 2026 installed a JavaScript trojan called “ShaiWorm” on importer machines. That infostealer scanned for .env files, API keys, cloud credentials, browser data, GitHub tokens and more, siphoning them out to attacker servers. Lightning AI warned that anyone who ran the compromised version might have had their tokens and secrets exfiltrated. Likewise, Checkmarx users are advised to treat this Jenkins plugin incident with maximum caution.
Jenkins Ecosystem and Supply Chain Risks
The popularity of Jenkins increases the chances that any minor flaw may cause substantial damage. Tens of thousands of businesses use Jenkins for automation purposes. Hence, there is high demand for official plugins that may be leveraged as a malware vector. The official Jenkins blog post mentions that the solution is currently “widely used and trusted.” Indeed, industry reports indicate that 32,000+ companies utilize Jenkins for their production workloads. Thus, any backdoor placed inside an official plugin will affect a large developer community.
According to 2025 Data Breach Investigation Reports, third-party participation in data breach incidents increased to 30%. In other words, almost one-third of all significant cybersecurity events in 2025 involved the misuse of an organization’s supplier. The modern world is dominated by software engineering practices based on supply chains and “systemic failure modes” that leverage the trust developers have in their tools. Therefore, even automated scans performed by CI/CD pipelines can serve as malware distribution channels.
- Widespread adoption: Jenkins is used by nearly a third of software teams, behind only GitHub Actions in popularity.
- Rising attack share: Supply-chain breaches are now reported in ~30% of all incidents, up from 15% just a year prior.
- Toolchain trust: Leading research notes that attackers increasingly target developer workflows and package registries to bypass defenses.
All these facts explain why the Checkmarx incident should be seen as a wake-up call: a minor malicious plugin exploited a popular CI/CD tool.
Other Recent Supply-Chain Incidents
This recent incident involving the Checkmarx plugin falls into a similar trend observed in languages and ecosystems throughout the year. Namely:
- Several npm packages are known to contain credential theft code delivered in malicious updates (“the Shai-Hulud worm campaigns”). In particular, in May 2026, a campaign affected many packages of the TanStack library collection which includes packages with >12M weekly downloads.
- A backdoored Bitwarden CLI npm package was linked to TeamPCP in March 2026; this was designed to steal developer tokens from victims.
- Python-related products are also targeted by the supply chain attack actors. Apart from PyTorch Lightning, multiple PyPI packages (>1M monthly downloads for one) are detected pushing infostealers to developers.
- IDE plugins and Docker containers are vulnerable as well, with malicious packages embedded in legitimate VS Code extensions and Docker images.
As we see, all these incidents involve the use of malicious CI/CD automation to distribute malware on a massive scale. This way, by compromising the release pipeline and automating malware distribution through it, threat actors manage to generate malicious software which comes with legitimate (even SLSA-provenance attested) signatures.
Conclusion: When a Trusted Jenkins Plugin Becomes the Secret Stealer
The Checkmarx Jenkins AST plugin incident shows how dangerous software supply chain compromise becomes when it reaches CI/CD. A trusted security plugin is not expected to behave like an infostealer, but that is exactly why this type of attack is so effective. Developers install it, pipelines trust it, and build environments often expose the secrets attackers want most.
Why This Threat Matters
CI/CD systems hold the keys to the software factory.
- Jenkins plugins run inside trusted automation workflows
- Build servers often have access to source code, tokens, credentials, and deployment secrets
- Infostealers can harvest sensitive data before teams notice abnormal behavior
- A compromised plugin can turn security tooling into an attack path
- One poisoned component can create downstream risk across repositories, pipelines, and production environments
When the build system is compromised, the attacker is no longer outside the software lifecycle. They are inside it.
Where Xcitium Changes the Outcome
If you have Xcitium in place, this attack would NOT succeed the way the attacker needs.
With Xcitium Advanced EDR, malicious plugin behavior and follow-on payload execution fail at runtime.
- Unknown code is isolated the moment it attempts to run
- Code can run without being able to cause damage
- Credential harvesting, persistence, and outbound theft lose the execution path they depend on
- Developer workstations and build servers remain protected even when trusted tools are compromised
Secure the Pipeline Before It Builds the Breach
The lesson is clear. CI/CD infrastructure must be treated like production, because attackers already do. Validate plugins, rotate secrets, monitor build environments, and stop unknown code before a trusted extension becomes a credential theft engine.
