Checkmarx says a modified version of its Jenkins AST Scanner plugin was published to the Jenkins Marketplace, adding another CI/CD component to the company’s ongoing supply-chain incident. The vendor’s May 9 update lists Checkmarx Jenkins AST Plugin version 2026.5.09 as malicious, with affected marketplace artifacts exposed from 2026-05-09 01:25 UTC to 2026-05-10 08:47 UTC.[1]
The practical advice is unusually direct: Checkmarx told users of the Jenkins AST plugin to ensure they are running version 2.0.13-829.vc72453fa_1c16, published on December 17, 2025, or an earlier version.[1] The Jenkins plugin release page also shows that safe baseline in the plugin’s public release history, which gives administrators a concrete version to compare against local Jenkins installations.[2]
This is not just a plugin-version housekeeping issue. Security scanners sit inside build systems, where they may see source code, environment variables, API tokens, cloud credentials, container registry secrets, and deployment metadata. A malicious scanner plugin can therefore turn a trusted defensive control into a credential-harvesting point inside the pipeline.
The Jenkins plugin warning also lands in the middle of a larger TeamPCP-linked supply-chain campaign against developer and security tooling. Akamai described the 2026 TeamPCP activity as a cascading credential and supply-chain attack that began with Trivy and later affected Checkmarx-related components and other developer packages.[3] Wiz previously documented how the Checkmarx KICS GitHub Action compromise searched CI runners for environment variables, SSH keys, cloud material, Kubernetes tokens, and other secrets before exfiltration.[4] That broader pattern is why a Jenkins plugin exposure should be handled as a possible secrets incident, not only as a bad artifact download.
For howtofix readers, the story rhymes with other recent trust-chain failures: fake AI repositories pushing infostealers through familiar setup steps and poisoned developer packages stealing CI secrets from package ecosystems. If your team uses Jenkins to run security scans, the key question is simple: did the malicious plugin version run inside a pipeline that had access to useful credentials?
What Jenkins administrators should do now
| Environment | Recommended response |
|---|---|
| Jenkins does not use Checkmarx AST Scanner | No direct action for this plugin, but review whether other Checkmarx artifacts from the broader incident are used in CI/CD. |
Plugin is pinned to 2.0.13-829.vc72453fa_1c16 or older |
Keep the version pinned, verify the installed artifact source and checksum where possible, and monitor Checkmarx for a clean newer release.[1] |
Plugin version 2026.5.09 was installed or auto-updated |
Disable or roll back the plugin, preserve Jenkins logs and plugin files for review, and treat CI/CD credentials exposed to that controller or agent as potentially compromised. |
| Unsure which version ran | Check Jenkins plugin inventory, update-center logs, plugin manager history, filesystem timestamps under the Jenkins plugins directory, and recent pipeline runs that invoked Checkmarx scans. |
Start triage with the Jenkins controller and any build agents that executed Checkmarx AST scans during the exposure window. Review plugin installation logs, outbound network activity from build nodes, unusual child processes spawned during scan steps, and any pipeline that passed secrets through environment variables. If the malicious artifact ran, rotate secrets from a clean administrative workstation: SCM tokens, Jenkins credentials, cloud keys, container registry tokens, Checkmarx tokens, SSH deploy keys, GitHub/GitLab tokens, and Kubernetes service-account material should all be considered in scope.
For future protection, pin security tooling to known-good versions or checksums, avoid broad auto-update permissions for CI plugins, limit secrets available to scan jobs, and prefer short-lived credentials wherever possible. The awkward lesson is that build-time security tools need the same supply-chain controls as production dependencies. If they can read secrets, they can leak secrets when the update channel is compromised.
Checkmarx lists SHA-256 hashes for the malicious .hpi, .jar, and .pom artifacts in its official update.[1] Administrators who keep artifact caches should compare stored plugin files against those hashes and retain matches for incident response rather than deleting everything immediately.
References
- Checkmarx Team. “Update: Ongoing Checkmarx Supply Chain Security Incident.” Checkmarx, updated May 9, 2026. https://checkmarx.com/blog/ongoing-security-updates/
- Jenkins. “Checkmarx AST Scanner | Jenkins plugin releases.” Jenkins Plugin Index, accessed May 11, 2026. https://plugins.jenkins.io/checkmarx-ast-scanner/releases/
- Akamai Security Intelligence Group. “The Telnyx PyPI Compromise and the 2026 TeamPCP Supply Chain Attacks.” Akamai, March 27, 2026. https://www.akamai.com/blog/security-research/2026/mar/telnyx-pypi-2026-teampcp-supply-chain-attacks
- Rami McCarthy, James Haughom, and Benjamin Read. “KICS GitHub Action Compromised: TeamPCP Strikes Again in Supply Chain Attack.” Wiz, March 23, 2026. https://www.wiz.io/blog/teampcp-attack-kics-github-action
Leave a Comment