The affected release has been identified as version 2026.5.09 of the Checkmarx AST Scanner plugin, distributed as tampered HPI, JAR and POM artifacts. The exposed window ran from 01:25 UTC on May 9 to 08:47 UTC on May 10, creating a risk for organisations that installed or updated the plugin during that period. The last known-good build cited for users is 2.0.13-829. vc72453fa_1c16, published on December 17, 2025, while Checkmarx has since worked to publish clean plugin versions.
The Jenkins AST plugin is used to connect Jenkins continuous integration and delivery pipelines with Checkmarx One application security testing, making the compromise significant for software teams that rely on automated scans before code is merged, packaged or deployed. Jenkins remains a core tool across enterprise build systems, and plugins installed inside such environments can gain access to credentials, source code, build logs, cloud tokens and deployment paths if not tightly restricted.
The incident forms part of a broader campaign linked to TeamPCP, a threat group associated with attacks on developer ecosystems and credential-stealing operations. The same wider sequence has included abuse of the Trivy scanner supply chain, malicious Checkmarx-related GitHub Actions, tainted Visual Studio Code and Open VSX extensions, and public claims of access to Checkmarx repositories. Checkmarx has said evidence points to credentials obtained through the earlier Trivy-linked compromise as the likely route into its GitHub environment.
Checkmarx’s chronology shows the first stage of the incident on March 23, when malicious versions of two Open VSX extensions were published and payloads were injected into the checkmarx/ast-github-action and checkmarx/kics-github-action workflows. Those GitHub Actions were exposed for several hours on March 23 before maintainers revoked affected tags and moved users to verified releases. A further wave on April 22 involved KICS Docker Hub images, AST GitHub Action artifacts and marketplace extensions, suggesting either continued access or renewed compromise before the Jenkins plugin event in May.
The most serious risk is not only that a malicious plugin reached a trusted marketplace, but that it sat inside a build environment where secrets are often available by design. CI/CD systems routinely hold access tokens for source repositories, registries, cloud accounts and deployment services. Once a plugin is installed, defenders must assume that any secret reachable by the Jenkins controller or job runners may need to be revoked, rotated and audited.
Security teams are being advised to remove the rogue 2026.5.09 release, verify installed artifacts against known hashes, examine Jenkins logs and build histories, and rotate credentials exposed to affected jobs. Checks should include outbound connections, unexpected repository changes, unfamiliar GitHub Actions activity, suspicious package publications and newly created tokens or service accounts. Organisations using auto-update features for plugins or IDE extensions face a sharper risk because malicious versions can enter production workflows before human review.
The attack also renews scrutiny of trust models around official marketplaces. Developer platforms have improved malware scanning, signing and takedown processes, but the Checkmarx case shows how attackers can exploit legitimate distribution channels after compromising maintainer credentials or release infrastructure. For enterprises, the lesson is that marketplace presence is no longer enough: plugin versions, checksums, publisher activity, release timing and provenance controls now need to be part of routine software risk management.
Checkmarx has said its GitHub repositories are maintained separately from its customer production environment and that customer data is not stored there as standard practice. It also said it retained external forensic specialists, engaged law enforcement, rotated credentials, locked down affected repositories and began broader code audits to confirm no further malicious code remains beyond identified findings.
The company’s guidance for earlier affected components included use of pinned SHAs, review of auto-update settings, blocking attacker-controlled infrastructure and rotation of secrets where exposure is suspected. For the Jenkins plugin issue, the immediate priority is narrower but urgent: confirm that version 2026.5.09 was not installed, downgrade or move to a verified clean build, and treat any environment that executed the compromised artifact as potentially exposed.
Follow Arabian Post
Select Arabian Post as your preferred source on Google and MSN News for trusted business news and Arab politics and updates.
