Checkmarx Confirmed on May 11 That a Modified Version of Its Jenkins AST Plugin Was Published to the Jenkins Marketplace Between May 9 and May 10. TeamPCP Took Credit by Renaming the GitHub Repository to "Checkmarx-Fully-Hacked-by-TeamPCP-and-Their-Customers-Should-Cancel-Now" With the Description "Checkmarx Fails to Rotate Secrets Again." This Is the Third Time TeamPCP Has Compromised Checkmarx in Three Months. The Trivy Scanner Started It in March. The KICS Docker Image, GitHub Actions, and VS Code Extensions Followed in April. The Jenkins Plugin Is May. CVE-2026-33634, CVSS 9.4. The Pattern Is the Story.

WHAT ACTUALLY HAPPENED

A malicious version of the Checkmarx Jenkins AST plugin, numbered 2026.5.09, was uploaded to the Jenkins Marketplace on Saturday May 9, 2026 at 01:25 UTC. The plugin was built to function identically to the legitimate Checkmarx Jenkins AST plugin during pipeline execution while quietly harvesting credentials from the Jenkins runner. The legitimate plugin uses a revision-changelist versioning scheme (for example, 2.0.13-848.v76e89de8a_053). The malicious version used a date-coded format (2026.5.09), which was an immediate indicator for any defender who knew to look. The build had no corresponding GitHub release tag and was not produced by the normal CI pipeline.

The malicious plugin remained available on the Jenkins Marketplace until Sunday May 10 at 08:47 UTC, when Checkmarx and Jenkins removed it. The exposure window was approximately 31 hours. Any organization running Jenkins with automated plugin updates configured was at risk of pulling the compromised version during that window. Several hundred Jenkins controllers reportedly had the Checkmarx AST plugin installed at the time of the incident, though the exact number that received the malicious update is not yet public.

TeamPCP took credit publicly through a series of repository modifications on the Checkmarx GitHub organization. The cx-plugins-releases repository was renamed to "Checkmarx-Fully-Hacked-by-TeamPCP-and-Their-Customers-Should-Cancel-Now." The repository description was changed to "Checkmarx fails to rotate secrets again. with love - TeamPCP." Additional repositories appeared on the compromised account with Dune-themed names (kralizec-navigator-709, tleilaxu-thumper-952, ghola-cogitor-195, fedaykin-laza-800, mentat-navigator-124) all carrying the description "A Mini Shai-Hulud has Appeared." The naming references are consistent with the broader Shai-Hulud campaign that has been propagating through npm and PyPI ecosystems through April and May.

CVE-2026-33634 was assigned to the compromise with a CVSS score of 9.4. Checkmarx has published a clean version 2.0.13-848.v76e89de8a_053 on May 9 and confirmed that the last known safe version prior to this wave is 2.0.13-829.vc72453fa_1c16, published December 17, 2025. Organizations running that version or earlier are not affected by this specific wave.

THE THREE-MONTH CAMPAIGN

The Jenkins AST plugin compromise is not an isolated incident. It is the third wave of a sustained TeamPCP campaign against Checkmarx specifically, which itself sits inside a broader TeamPCP campaign against the developer tooling supply chain. The narrative across the three months is the substantive story.

March 19, 2026. The cybersecurity community publicly reported on a supply chain attack against Aqua Security's Trivy vulnerability scanner. TeamPCP had compromised Trivy and the compromised version was distributing credential-stealing payloads to downstream users. The attack methodology used the inherent trust developers place in vulnerability scanning tools, which are typically allowed to read sensitive parts of the build environment.

March 23, 2026. Checkmarx identified a cybersecurity incident in its own GitHub repositories. The company's later forensic analysis attributed the breach to credentials stolen through the Trivy attack. Checkmarx had used Trivy in some part of its development environment, and the credentials harvested by the Trivy compromise gave TeamPCP access to Checkmarx's GitHub. Once inside, TeamPCP began publishing malicious versions of various Checkmarx artifacts. The same campaign reportedly compromised at least 66 npm packages and potentially exposed more than 1,000 enterprise SaaS environments.

April 22, 2026. The second wave hit Checkmarx specifically. Between 12:31 UTC and 12:59 UTC, the public KICS Docker image on DockerHub was tampered with. Between 14:17 UTC and 15:41 UTC, the ast-github-action GitHub Action workflow was compromised. Both VS Code extensions for Checkmarx AST Results and Developer Assist were replaced with malicious versions across Microsoft and Open VSX marketplaces. The malicious code was designed to collect GitHub personal access tokens, AWS/Azure/Google Cloud credentials, Kubernetes service account tokens, SSH keys, and Docker registry credentials. The exfiltration domain was checkmarx[.]zone, an attacker-controlled lookalike.

April 25, 2026. LAPSUS$ extortion group published data stolen from Checkmarx's GitHub repositories on the dark web. The data had been exfiltrated on March 30 during the initial TeamPCP intrusion. The Checkmarx-LAPSUS$ link is one of the open questions in the campaign: TeamPCP appears to be the primary intrusion actor, but LAPSUS$ may be a downstream consumer of the stolen data or a coordinated partner.

May 9, 2026. The third wave hit Checkmarx through the Jenkins AST plugin. The fact that TeamPCP regained the ability to publish malicious artifacts six weeks after Checkmarx's first remediation suggests either incomplete credential rotation or a persistent foothold that was not identified during the March/April incident response. The attacker's own taunt ("Checkmarx fails to rotate secrets again") leans into exactly this narrative. SOCRadar's assessment is that TeamPCP is "actively watching for re-entry points, testing the depth of past remediations, and capitalizing on any gaps."

The same TeamPCP campaign has produced compromises across the broader developer tooling ecosystem: the Bitwarden CLI npm package (March), PyTorch Lightning (May 1, previously covered by Atarus), LiteLLM (March, named in yesterday's GTIG disclosure), the TanStack library family in May, multiple npm packages via the CanisterWorm propagation mechanism, and the active "Shai-Hulud: Here We Go Again" worm campaign across npm and PyPI ecosystems. The Checkmarx attacks are the high-visibility center of a much broader campaign.

WHY THE TARGETING IS PARTICULARLY DAMAGING

The Checkmarx Jenkins AST plugin is a tool customers install specifically to improve the security of their CI/CD pipelines. The plugin scans application code during the build process and reports vulnerabilities to the development team. Customers install it because they trust the Checkmarx brand and they trust the Jenkins Marketplace distribution channel. The compromise weaponizes both forms of trust simultaneously.

This is the practitioner observation that compounds. Security tooling is the highest-leverage compromise target in the developer ecosystem. The security scanner has access to the source code. The CI/CD plugin has access to build secrets. The static analysis tool has access to credentials configured for testing. The vulnerability management platform has access to environment information that maps the entire attack surface. When the security tool is the compromise vector, the customer's defensive investments become the attacker's offensive enablement.

The Atarus blog covered this pattern from a different angle in the Trellix source code breach post on May 4. Trellix was a security vendor compromise. Checkmarx is a security vendor compromise. The two together are not coincidences. They are two data points in a broader pattern that has now produced six major security vendor compromises in eighteen months (SolarWinds 2020, FireEye 2020, Okta 2022 and 2023, LastPass 2022, Microsoft Midnight Blizzard 2024, Trellix 2026, plus now Checkmarx as a sustained campaign). Each one weaponized the customer's trust in the vendor. Each one produced downstream exposure that customers could not directly remediate. Each one was disclosed in stages that took weeks or months to resolve operationally.

The blast radius framing from Sunday's synthesis piece applies directly to the Checkmarx incident. The capability of the Jenkins AST plugin was within its design envelope: it scanned code, reported findings, integrated with build pipelines. The blast radius was determined by what credentials the plugin could access. Jenkins runners typically hold GitHub PATs, cloud provider credentials, Kubernetes configurations, Docker registry credentials, SSH keys, and API tokens for the services the pipeline interacts with. The plugin's blast radius is the union of all those secrets. The compromise extracts the union.

WHAT THIS MEANS FOR JENKINS USERS

The immediate practitioner work is incident response for any organization that ran Jenkins with the Checkmarx AST plugin during the exposure window. The window was approximately 31 hours from May 9 at 01:25 UTC to May 10 at 08:47 UTC. Organizations with automated plugin updates are the highest-risk group because the malicious version could have been pulled silently without any human review. Organizations with manual plugin updates or with the plugin pinned to a specific known-good version are not affected by this wave.

The exposure scope, for organizations that did pull the malicious version, includes every secret accessible to the affected Jenkins runner. GitHub personal access tokens used by the pipeline. Cloud provider credentials (AWS, GCP, Azure) configured for deployment. Kubernetes service account tokens for cluster access. Docker registry credentials for image push and pull. SSH keys for remote system access. API keys for third-party services integrated into the build. Any of these that was visible to the Jenkins runner during the exposure window should be treated as compromised and rotated immediately.

The longer-term practitioner work is the structural review the Checkmarx campaign earns. Organizations that build their CI/CD on Jenkins with marketplace plugins are operating on the same trust model that just produced the compromise. The trust model is not wrong, but it is not free either. Each plugin installed extends the blast radius of the Jenkins environment. Each automated plugin update increases the exposure window when a vendor compromise occurs. The deployment architecture decisions about plugin pinning, manual update review, and least-privilege credential scoping for Jenkins runners are the controls that determine the exposure to the next supply chain attack, which the pattern suggests is approximately one month away.

INDICATORS AND TIMELINE

WHAT TO DO TODAY