Checkmarx Jenkins Plugin Backdoored in New TeamPCP Supply Chain Attack

It hasn’t been long since TeamPCP made headlines for compromising Checkmarx’s GitHub Actions and OpenVSX extensions as part of a sprawling supply chain campaign. Now the same threat actor is back; and this time, they went after the Checkmarx Jenkins plugin.

The attack was flagged by a security engineer on X, who noted that TeamPCP had defaced and renamed the Checkmarx Jenkins AST plugin repository on GitHub and backdoored the plugin release with what they’re calling Dune-themed malware.

So what happened, what does it mean, and what should you do about it? Let’s get into it.

What Happened to the Checkmarx Jenkins Plugin?

TeamPCP targeted the Checkmarx Jenkins plugin for AST scanning, which is a widely used integration that lets development teams run Checkmarx security scans directly from their Jenkins CI pipelines.

The attack involved two distinct actions:

Repository Defacement and Renaming

The group gained access to the official GitHub repository for the plugin and renamed it to something provocative: “Checkmarx-Fully-Hacked-by-TeamPCP-and-Their-Customers-Should-Cancel-Now.” The repository description was also altered to read: “Checkmarx fails to rotate secrets again. with love – TeamPCP.”

This is consistent with TeamPCP’s pattern of using defacement as a public announcement alongside their actual payload delivery.

Backdooring the Plugin Release

Beyond the defacement, the group went further and backdoored the plugin itself, targeting the release hosted at plugins.jenkins.io/checkmarx-ast-scanner/releases/ (version 2026.5.09). Any Jenkins instance that pulled this version during the exposure window would have installed a compromised plugin.

The “Dune-Themed” Malware: Meet Shai Hulud

The repositories visible on the compromised cx-plugins-releases GitHub account bear names like kralizec-navigator-709, tleilaxu-thumper-952, ghola-cogitor-195, fedaykin-laza-800, and mentat-navigator-124 – all with the description “A Mini Shai-Hulud has Appeared.”

Why Does This Matter?

This is not TeamPCP’s first time inside Checkmarx infrastructure. In March 2026, the group compromised checkmarx/ast-github-action and checkmarx/kics-github-action, deploying a credential-stealing payload that harvested CI runner secrets and exfiltrated them to checkmarx[.]zone. The same campaign also pushed malicious OpenVSX extensions through a compromised Checkmarx account.

The fact that TeamPCP is back inside Checkmarx systems just weeks later points to one of two possibilities: either the initial remediation was incomplete and credentials were not fully rotated, or the group retained a foothold that wasn’t identified during the March response. The attacker’s own taunt, “Checkmarx fails to rotate secrets again,” leans into exactly this narrative.

The Cascading Trust Problem

What makes this particularly dangerous for Jenkins users is the trust model at play. The Checkmarx Jenkins plugin is a tool people install specifically to improve the security of their pipelines. A backdoored version doesn’t just compromise one project; it rides trusted infrastructure into every build pipeline it touches, with access to source code, environment variables, tokens, and whatever secrets the runner can see.

TeamPCP has shown in previous campaigns that this is exactly what they’re after. Their credential-stealing payloads sweep process memory, scan dozens of filesystem paths for SSH keys, cloud credentials, Kubernetes tokens, and database connection strings, then bundle everything into an encrypted archive for exfiltration.

A Pattern of Persistence

This campaign also reinforces a broader pattern observed across the March supply chain incident: TeamPCP is not operating as a one-off opportunist. They hit Trivy, pivoted to Checkmarx GitHub Actions, published malicious PyPI packages (litellm, telnyx), pushed compromised npm packages via CanisterWorm, and defaced internal repositories, all within roughly a week. A second Checkmarx incident happening this soon suggests the group is actively watching for re-entry points, testing the depth of past remediations, and capitalizing on any gaps.

Who Is at Risk?

If your Jenkins environment uses the Checkmarx Jenkins plugin and pulled an update around the time of this incident, you should treat that environment as potentially compromised until proven otherwise. The affected version is 2026.5.09.

Any secrets visible to the Jenkins runner (GitHub tokens, AWS/GCP/Azure credentials, Kubernetes configs, SSH keys, API keys stored in environment variables) should be considered exposed.

What Should You Do?

Immediate Steps

• Audit your Jenkins plugin versions. Check whether version 2026.5.09 of the Checkmarx Jenkins plugin was installed in any of your Jenkins instances.
• Rotate all secrets accessible from affected Jenkins runners. This includes GitHub PATs, cloud credentials, Kubernetes tokens, Docker credentials, and any secrets stored in .env files or Jenkins credentials stores.
• Search for Dune-themed repository names in your GitHub organizations. Names like tpcp-docs, tpcp-docs-*, or anything with Dune character references could be a sign of fallback exfiltration activity.
• Review Jenkins build logs for outbound connections to unusual domains, especially anything resembling C2 infrastructure used in prior TeamPCP campaigns.
• Pin your Jenkins plugins to verified, known-good versions and validate checksums before deploying updates in sensitive environments.

Longer-Term Hardening

• Apply least-privilege principles to Jenkins credentials stores. Runners should only have access to the secrets they actually need for a given job.
• Consider using short-lived, OIDC-based credentials for cloud access from CI pipelines instead of long-lived static keys.
• Monitor for anomalous outbound traffic from build agents, including to Cloudflare Tunnel URLs (.trycloudflare.com) and similar infrastructure that TeamPCP has used in past campaigns.
• Treat CI/CD environments with the same security scrutiny you apply to production systems. They frequently hold the keys to everything else.

How Can SOCRadar Help?

As the TeamPCP campaign reminds us, supply chain threats don’t announce themselves cleanly. A backdoored Checkmarx Jenkins plugin, a renamed repository, a compromised release – these are the kinds of signals that get buried in noise unless you’re actively watching the right places.

SOCRadar’s Supply Chain Intelligence gives security teams continuous visibility into the security posture of their third-party vendors and dependencies; not just point-in-time assessments. When a vendor like Checkmarx is targeted, SOCRadar surfaces the relevant risk signals, tracks threat actor activity across the ecosystem, and helps teams prioritize what actually needs action before it becomes an incident on their end.

But supply chain attacks like this one don’t stay in the open. The stolen credentials, the exfiltrated secrets, the compromised tokens… they end up somewhere. SOCRadar’s Dark Web Monitoring keeps watch on the places where that harvested data surfaces, alerting you if your organization’s credentials or sensitive assets appear in Dark Web markets, leak channels, or threat actor communities on platforms like Telegram.