TeamPCP Backdoors Checkmarx Jenkins Plugin: Your Security Scanner Is the Backdoor

On May 9, 2026, TeamPCP published a backdoored version of the Checkmarx Jenkins AST plugin to the official Jenkins Marketplace. It sat live for over 31 hours, harvested CI/CD secrets from 1,000+ enterprise environments, and exfiltrated them to a command-and-control server disguised as Checkmarx’s own domain. The plugin’s job was to scan your code for vulnerabilities. Instead, it stole your AWS credentials.

What Happened

CVE-2026-33634 (CVSS 9.4). Version 2026.5.09 of the Checkmarx Jenkins AST plugin — a widely deployed integration that runs Checkmarx SAST scans inside Jenkins pipelines — was published to repo.jenkins-ci.org outside Checkmarx’s standard release process. The malicious build enumerated all environment variables visible to the Jenkins runner and shipped them to checkmarx[.]zone (not checkmarx.com).

Jenkins runners see everything: GitHub Personal Access Tokens, AWS and GCP and Azure credentials, Kubernetes configs, Docker registry tokens, SSH keys. That’s by design — they need those secrets to build and deploy. The Checkmarx plugin ran inside that context, so the malware did too.

Checkmarx confirmed the incident on May 11. Exposure window: May 9 at 01:25 UTC to May 10 at 08:47 UTC. Arctic Wolf estimates at least 1,000 enterprise environments were affected downstream.

How TeamPCP Got There: A Seven-Step Cascade

This wasn’t a random opportunistic attack. It was the fifth or sixth move in a campaign that began in March 2026 and used credentials stolen from each prior victim to unlock the next target:

• March 20: Trivy (Aqua Security’s open-source vulnerability scanner) was compromised. TeamPCP poisoned Trivy v0.69.4 binaries and the aquasecurity/trivy-action GitHub Action. CI/CD credentials harvested.
• March 23: Stolen Trivy contributor credentials — some contributors worked on both projects — gave TeamPCP write access to Checkmarx’s repositories. The checkmarx/ast-github-action and checkmarx/kics-github-action were compromised. The team briefly renamed a repository to “Checkmarx-Fully-Hacked-by-TeamPCP-and-Their-Customers-Should-Cancel-Now.”
• March 24: LiteLLM PyPI packages 1.82.7 and 1.82.8 were poisoned. LiteLLM receives roughly 97 million downloads per month.
• April 22: A second Checkmarx wave surfaced despite claimed remediation — suggesting credentials were never fully rotated, or TeamPCP retained a foothold.
• May 9: The Jenkins Marketplace strike. The most privileged vector yet.

Each attack wasn’t just opportunistic expansion — it was harvested credentials being reused systematically. Incomplete remediation after March is why TeamPCP was able to publish the Jenkins plugin in May.

Are You Affected?

Check your installed plugin version immediately. In Jenkins: Manage Jenkins → Manage Plugins → Installed, then search for “Checkmarx.”

• Malicious version: 2026.5.09
• Safe (pre-attack): 2.0.13-829.vc72453fa_1c16
• Post-patch: 2.0.13-848.v76e89de8a_053

Also check internal Artifactory mirrors or artifact caches — if your organization mirrors the Jenkins plugin registry, the malicious version may have been cached and served to multiple Jenkins instances from there.

What to Do Now

If you ran 2026.5.09, or cannot confirm you didn’t during the exposure window, assume the environment is compromised:

1. Rotate all Jenkins runner secrets immediately: GitHub PATs, AWS/GCP/Azure credentials, Kubernetes configs, Docker credentials, SSH keys. Any secret that was an environment variable during a build between May 9-10 is potentially exposed.
2. Upgrade the plugin: Install 2.0.13-848.v76e89de8a_053 from the Jenkins Marketplace or Checkmarx’s official security update page.
3. Hunt for IOCs in CI/CD logs: Look for outbound connections to checkmarx[.]zone, downloads of tpcp.tar.gz, or references to repositories with Dune character names — TeamPCP’s signature.
4. Audit builds from May 9-10: Any release artifacts produced during the exposure window should be treated as potentially poisoned and rebuilt from scratch.

# Check installed Checkmarx plugin version via Jenkins CLI
java -jar jenkins-cli.jar -s http://jenkins.example.com/ list-plugins | grep -i checkmarx

# Scan local plugin directory for malicious version
grep -r "2026.5.09" /var/lib/jenkins/plugins/ 2>/dev/null

# Hunt for C2 traffic in Jenkins logs
grep -rE "checkmarx\.zone|tpcp\.tar\.gz" /var/log/jenkins/ 2>/dev/null

The Structural Problem Nobody Wants to Talk About

Security tools run with the same privilege as your most sensitive build steps. They have to — SAST scanners need to read source code, access test environments, and sometimes touch staging credentials. That privilege is load-bearing. And yet those tools are routinely left on auto-update, unverified by checksum, and pulled from marketplaces with no cryptographic guarantee that what you’re downloading matches what the vendor published.

SLSA provenance doesn’t fix this. TeamPCP published the malicious Jenkins plugin through Checkmarx’s own release pipeline using stolen credentials. The provenance would have been valid. The publisher was just compromised. Trend Micro’s analysis confirms the malicious code was published after obtaining credentials from the earlier supply chain compromise.

The only real defense is to treat security tooling with the same skepticism you apply to every other production dependency: pin versions, verify hashes, use short-lived credentials so the blast radius of any single plugin compromise stays small, and monitor for unexpected network egress from your build environment. If your Jenkins runner can reach the internet and has production AWS credentials, a compromised plugin is game over.

TeamPCP is not done. The pattern — compromise a trusted tool, harvest credentials, compromise the next trusted tool — is replicable across any ecosystem with shared contributors, auto-updating plugins, and elevated CI/CD trust. The Checkmarx Jenkins attack is probably not the last entry on this campaign’s list.