Checkmarx Jenkins AST plugin compromised in TeamPCP supply chain attack

Checkmarx has confirmed that a modified version of its Jenkins AST plugin was published to the Jenkins Marketplace, extending a wider supply chain incident that began in March 2026.

The malicious plugin version was listed as 2026.5.09. According to Checkmarx, the exposure window ran from May 9, 2026 at 01:25 UTC to May 10, 2026 at 08:47 UTC.

Organizations that installed or automatically updated to that version should treat affected Jenkins environments as potentially compromised. Jenkins pipelines often hold source code access, build secrets, cloud credentials, deployment tokens, and security scanning permissions.

What happened

Checkmarx said a modified version of the Jenkins AST plugin appeared in the Jenkins Marketplace. The plugin lets development teams run Checkmarx AST scans directly from Jenkins CI/CD pipelines.

The incident followed earlier Checkmarx supply chain activity tied to unauthorized access to the company’s GitHub environment. Checkmarx says that access likely came through the earlier Trivy supply chain attack, which may have allowed attackers to obtain credentials.

The Jenkins plugin compromise represents a dangerous escalation because Jenkins sits inside software delivery pipelines. A malicious plugin can run where build secrets, repositories, and deployment systems are already trusted.

At a glance

Item	Details
Affected product	Checkmarx Jenkins AST plugin
Malicious version	2026.5.09
Exposure window	May 9, 2026 at 01:25 UTC to May 10, 2026 at 08:47 UTC
Distribution channel	Jenkins Marketplace
Likely risk	Credential theft, pipeline compromise, and unauthorized CI/CD access
Immediate action	Remove malicious version, verify plugin hashes, rotate exposed secrets, and review Jenkins logs

How the incident connects to earlier Checkmarx attacks

Checkmarx says the broader incident began on March 23, 2026, when malicious artifacts were published after unauthorized access to its GitHub environment.

The company says the likely initial vector was the earlier Trivy supply chain attack reported by the security community on March 19. That campaign was linked to TeamPCP activity and focused on harvesting credentials from downstream users.

Checkmarx later found that data had been exfiltrated from its GitHub environment on March 30. A cybercriminal group then published Checkmarx-related data to the dark web on April 25.

Why the Jenkins plugin compromise is serious

Jenkins is often connected to source code repositories, build systems, container registries, cloud accounts, and deployment workflows. That makes any malicious plugin inside Jenkins especially risky.

A compromised security scanning plugin can blend into normal developer activity because teams expect it to access code and run inside pipelines. This makes detection harder than spotting an unknown tool.

Any organization that installed version 2026.5.09 during the exposure window should assume secrets available to Jenkins jobs may have been exposed.

Important indicators

Type	Indicator	Description
Plugin version	2026.5.09	Malicious Checkmarx Jenkins AST plugin version
File name	checkmarx-ast-scanner-2026.5.09.hpi	Malicious Jenkins plugin file
SHA256	01ff1e56fd59a8fa525d97e670f7f297a1a204331b89b2cd4e36a9abc6419203	Hash of malicious .hpi artifact
File name	checkmarx-ast-scanner-2026.5.09.jar	Malicious Jenkins plugin JAR artifact
SHA256	f50a96d26a5b0beb29de4127e82b2bf350c21511e5a43d286e43f798dc6cd53f	Hash of malicious .jar artifact
File name	checkmarx-ast-scanner-2026.5.09.pom	Malicious Maven POM artifact
SHA256	3ddb8967919a801b3c383e58cddceab21138134c6a26560d99e2672e86f36f2a	Hash of malicious .pom artifact

KICS and other Checkmarx tools were also hit

The Jenkins plugin compromise followed an earlier wave involving Checkmarx KICS, VS Code extensions, Open VSX extensions, and a GitHub Action.

Trend Micro says that on April 22, TeamPCP pushed malicious images to the official checkmarx/kics Docker Hub repository while also poisoning VS Code and Open VSX extensions and modifying the checkmarx/ast-github-action workflow.

The same research says the April 22 activity targeted developer secrets, including GitHub personal access tokens, npm tokens, AWS credentials, Azure credentials, Google Cloud credentials, SSH material, AI configuration files, and shell history.

Broader affected artifacts

Artifact	Reported malicious versions or tags	Risk
Checkmarx Jenkins AST plugin	2026.5.09	Potential compromise of Jenkins CI/CD environments
Checkmarx KICS Docker images	latest, v2.1.20, v2.1.20-debian, and other overwritten tags	Credential theft from build or scanning environments
checkmarx/ast-github-action	Modified versions before the cleaned release	Secret exposure through GitHub Actions workflows
Checkmarx AST Results extension	2.63.0 and 2.66.0	Developer environment compromise
Checkmarx Developer Assist extension	1.17.0 and 1.19.0	Developer environment compromise

What Checkmarx says about customer data

Checkmarx says its GitHub repositories are maintained separately from its customer production environment. The company also says it does not store customer data in its GitHub repository as standard practice.

The company locked down access to the affected GitHub repository while its investigation continued. It also said it had engaged outside experts and law enforcement.

Even so, customers must focus on their own exposure. If a malicious artifact ran in a customer’s environment, secrets available to that environment may need rotation regardless of whether Checkmarx production systems were affected.

What Jenkins administrators should do now

• Check whether any Jenkins controller or agent installed Checkmarx Jenkins AST plugin version 2026.5.09.
• Remove the malicious plugin version immediately.
• Verify plugin hashes against the official Checkmarx advisory.
• Review Jenkins update history and plugin installation logs for the exposure window.
• Rotate credentials available to affected Jenkins jobs.
• Review build logs for unexpected outbound connections or unusual scripts.
• Audit Jenkins credentials, environment variables, service accounts, and deployment tokens.
• Pin critical CI/CD tools to verified versions and hashes where possible.

What security teams should hunt for

Security teams should search for the malicious Jenkins plugin file names and hashes listed by Checkmarx. They should also review network logs for suspicious outbound connections from Jenkins controllers, agents, and build containers.

The wider TeamPCP campaign used Checkmarx-themed infrastructure and Dune-themed repository names in some waves. Teams should check for unfamiliar repositories, unexpected GitHub API activity, and unusual secret access from CI jobs.

Because the campaign focused on credential theft, cleanup should not stop at deleting malicious artifacts. Teams should rotate secrets, revoke stale tokens, rebuild affected runners, and review access logs for follow-on activity.

Why this campaign matters

The Checkmarx incident shows how attackers can turn security tooling into a delivery channel. CI/CD tools, code scanners, plugins, and IDE extensions all sit close to sensitive developer workflows.

That proximity gives attackers a powerful advantage. A poisoned plugin can reach systems that already trust it with source code and secrets.

Organizations should treat developer tooling as part of their core attack surface. Automated updates, broad token permissions, long-lived secrets, and unsigned pipeline components all increase the damage a supply chain attack can cause.

FAQ