Checkmarx Jenkins AST Plugin Compromised in TeamPCP Supply Chain Attack

Date:

Checkmarx Jenkins Plugin Compromised in Supply Chain Attack

A malicious version of the Checkmarx Jenkins AST Scanner plugin was published to the Jenkins Marketplace in May 2026, exposing organizations using the compromised build to a potentially serious software supply chain attack.

Checkmarx confirmed that a modified version of its Jenkins AST plugin had been published to the Jenkins Marketplace. The company subsequently removed the malicious plugin and released clean replacement versions. Checkmarx assessed that the attacker leveraged access obtained during an earlier March 2026 incident to publish the modified Jenkins plugin.

The incident has been linked to the broader TeamPCP supply chain campaign targeting Checkmarx and other software projects.

Organizations using the affected plugin should immediately verify their Jenkins installations, remove any compromised release and rotate credentials accessible to affected Jenkins pipelines.

Checkmarx Jenkins Plugin Attack at a Glance

Security DetailInformation
VendorCheckmarx
PluginCheckmarx AST Scanner
Jenkins plugin IDcheckmarx-ast-scanner
Incident typeSoftware supply chain compromise
Threat actorTeamPCP
Malicious release2026.5.09
Malicious artifactcheckmarx-ast-scanner-2026.5.09.hpi
Exposure windowMay 9, 2026 01:25 UTC to May 10, 2026 08:47 UTC
Last clean pre-incident release2.0.13-829.vc72453fa_1c16
Clean replacement2.0.13-848.v76e89de8a_053
Additional clean replacement2.0.13-847.v08c0072b_2fd5
Jenkins requirement for replacement builds2.452.4
Primary riskCredential theft and supply chain compromise
Recommended actionRemove malicious build, install verified clean version and rotate exposed credentials

Checkmarx published indicators for the malicious artifacts and confirmed that the affected plugin was removed from the Jenkins Marketplace.

What Happened to the Checkmarx Jenkins AST Plugin?

Checkmarx warned customers on May 9 that a modified version of its Jenkins AST plugin had been published to the Jenkins Marketplace.

The company initially instructed users to ensure they were running 2.0.13-829.vc72453fa_1c16, the version released on December 17, 2025, or an earlier trusted version.

Checkmarx subsequently released clean versions of the plugin after removing the malicious build.

The Jenkins plugin repository currently lists newer releases, including 2.0.13-853.v1fa_8405d5991, which was released after the incident.

What Was the Malicious Checkmarx Plugin Version?

The compromised artifact was identified as:

checkmarx-ast-scanner-2026.5.09.hpi

The malicious release was available through the Jenkins Marketplace during the following window:

May 9, 2026 at 01:25 UTC

through

May 10, 2026 at 08:47 UTC.

Checkmarx also published SHA-256 hashes for the malicious HPI, JAR and POM files to help organizations identify compromised artifacts.

What Did the Malicious Plugin Do?

The compromised plugin contained malicious code designed to search the affected environment for sensitive credentials.

According to Checkmarx, the payload targeted lists of file paths tailored to different operating systems, including Windows, Linux and macOS.

The targeted applications included credentials and sensitive data associated with:

  • AWS
  • GitHub
  • VPN applications
  • Cryptocurrency wallets
  • Other commonly used developer and security applications

Checkmarx said its investigation was still ongoing, but it had not identified references specifically targeting Jenkins credentials in the analyzed payload at the time of its update.

Snyk similarly classified the incident as embedded malicious code and reported that the compromised plugin was intended to scrape and exfiltrate secrets from the Jenkins environment.

Why Is a Compromised Jenkins Plugin Dangerous?

Jenkins is frequently used as part of CI/CD pipelines.

A Jenkins controller or build environment may have access to highly sensitive information, including:

  • Cloud credentials
  • GitHub tokens
  • Container registry credentials
  • Deployment keys
  • API tokens
  • SSH keys
  • Package repository credentials
  • Environment variables
  • Application secrets

A malicious plugin can therefore become a high-value target.

If the compromised plugin executes inside a Jenkins environment, attackers may be able to access information available to that environment.

The potential impact extends beyond the Jenkins server itself because stolen credentials can potentially be used to access other development, cloud and production systems.

TeamPCP and the Checkmarx Supply Chain Campaign

The Jenkins incident was not an isolated event.

Checkmarx said its assessment was that the threat actor leveraged access obtained during an earlier March 2026 incident to later publish the modified Jenkins plugin.

The broader campaign has been attributed to TeamPCP, a threat actor associated with multiple software supply chain compromises.

The earlier activity involving Checkmarx included malicious artifacts associated with the company’s repositories and software ecosystem.

The Jenkins plugin compromise demonstrates why organizations must consider the security of their software suppliers and build infrastructure, not just the security of their own source code.

Which Checkmarx Jenkins Plugin Versions Are Safe?

The last clean release before the malicious Marketplace window was:

2.0.13-829.vc72453fa_1c16

released on December 17, 2025.

Checkmarx subsequently published clean replacement releases including:

2.0.13-848.v76e89de8a_053

and

2.0.13-847.v08c0072b_2fd5

both released on May 9, 2026 and requiring Jenkins 2.452.4.

The Jenkins plugin repository now lists an even newer release:

2.0.13-853.v1fa_8405d5991

Therefore, administrators should use the latest verified release currently available through the official Jenkins plugin distribution, rather than deliberately remaining on an older version.

How to Check if Your Jenkins Server Was Affected

Organizations using the Checkmarx AST Scanner should identify every Jenkins environment running the plugin.

Do not limit the investigation to production Jenkins controllers.

Also check:

  • Development Jenkins servers
  • Test environments
  • Temporary CI servers
  • Self-hosted Jenkins controllers
  • Archived infrastructure
  • Developer-managed Jenkins instances
  • Build agents that executed the plugin

The Jenkins plugin CLI can be used to list installed plugins. For example:

jenkins-plugin-cli --list | grep -i checkmarx-ast

Then compare the installed version against the known malicious release and trusted releases.

Check the Plugin Installation Window

Organizations should pay particular attention to Jenkins systems that downloaded or executed the compromised plugin during:

May 9, 2026 01:25 UTC

to

May 10, 2026 08:47 UTC.

If an affected Jenkins environment executed the malicious plugin during this period, organizations should assume that credentials accessible to the pipeline may have been exposed until proven otherwise.

How to Respond to a Compromised Installation

1. Identify the affected Jenkins instance

Determine every Jenkins controller and build environment that installed or executed the compromised plugin.

2. Remove the malicious plugin

Immediately remove the compromised 2026.5.09 build.

Do not continue using the compromised artifact.

3. Install a verified clean version

Install a clean release from the official Jenkins plugin distribution.

The current Jenkins plugin listing provides newer releases than the initial post-incident versions.

4. Rotate exposed credentials

This is one of the most important steps.

Check every secret that the affected Jenkins environment could access.

Consider rotating:

  • AWS credentials
  • GitHub tokens
  • API keys
  • Cloud credentials
  • VPN credentials
  • SSH keys
  • Container registry credentials
  • Deployment tokens
  • Package repository credentials
  • Other CI/CD secrets

Checkmarx specifically recommends rotating credentials accessible to the pipeline that executed the malicious plugin.

5. Review Jenkins activity

Investigate:

  • Unexpected jobs
  • New credentials
  • Modified pipelines
  • New Jenkins users
  • Unexpected plugin installations
  • Suspicious outbound connections
  • Unexpected file access
  • Unusual API requests
  • Changes to build configurations

6. Investigate downstream systems

If credentials were exposed, investigate the systems those credentials could access.

For example, if an AWS credential was available to the Jenkins pipeline, review AWS CloudTrail and related activity for suspicious actions.

Indicators of Compromise

Checkmarx published several indicators associated with the malicious Jenkins plugin.

Malicious plugin

checkmarx-ast-scanner-2026.5.09.hpi

Malicious plugin SHA-256

01ff1e56fd59a8fa525d97e670f7f297a1a204331b89b2cd4e36a9abc6419203

Checkmarx also published hashes for the corresponding JAR and POM artifacts. Organizations conducting forensic investigations should use the complete official IOC list rather than relying on a single hash.

Network Indicators

Checkmarx identified network connections associated with the malicious activity, including:

hxxps[:]//api[.]github[.]com:443/user

and:

hxxps[:]//registry[.]npmjs[.]org:443/-/whoami

These indicators should be investigated in context rather than treated as proof of compromise because legitimate developer tooling can communicate with these services.

Was Customer Data Stolen?

Checkmarx stated that, based on the available evidence, data published by the threat actor appeared to originate from Checkmarx’s GitHub repository rather than customer data.

The company said it does not store customer data in its GitHub repository and that its investigation into the nature and scope of potentially affected information remained ongoing.

This distinction is important because the compromise of a software vendor does not automatically mean that every customer was breached.

However, customers who executed the malicious Jenkins plugin should independently investigate their own environments and rotate potentially exposed credentials.

Why Jenkins Is a High-Value Supply Chain Target

Jenkins sits at the center of many software development pipelines.

A single CI/CD environment can have access to:

Source code

Build systems

Cloud infrastructure

Container registries

Deployment systems

Production environments

This makes Jenkins plugins an attractive target for attackers.

A compromised plugin can potentially inherit the permissions and credentials available to the Jenkins environment in which it runs.

This is why organizations should treat third-party CI/CD plugins as software supply chain dependencies that require the same security scrutiny as application libraries.

How Organizations Can Reduce CI/CD Supply Chain Risk

Pin plugin versions

Avoid blindly installing whatever version is currently available.

Use controlled and verified plugin versions where appropriate.

Verify plugin integrity

Where possible, validate plugin hashes and signatures against trusted vendor or Jenkins sources.

Minimize Jenkins credentials

A Jenkins job should only have access to the credentials it actually needs.

Use short-lived credentials

Short-lived credentials reduce the potential impact of a compromised build environment.

Restrict outbound network access

CI runners and Jenkins agents should not have unrestricted outbound access when it is not required.

Monitor software supply chains

Track security incidents involving critical vendors, plugins and CI/CD dependencies.

Audit build environments

Regularly review Jenkins controllers, agents, plugins, credentials and pipeline configurations.

Final Verdict

The Checkmarx Jenkins AST Scanner compromise is a serious software supply chain incident because a malicious plugin was distributed through the Jenkins Marketplace and designed to search environments for sensitive credentials.

The compromised build was:

checkmarx-ast-scanner-2026.5.09

and was available during a limited window from May 9 to May 10, 2026.

Checkmarx subsequently released clean versions, while the Jenkins plugin repository now lists newer releases.

Organizations that installed or executed the malicious build should not simply update the plugin and move on. They should rotate credentials accessible to affected pipelines, review Jenkins and cloud activity, investigate the published indicators and assess downstream systems for unauthorized activity.

Recommended action: Verify your Checkmarx AST Scanner version immediately. If the malicious build was executed in your environment, treat accessible credentials as potentially exposed and begin credential rotation and incident investigation.

Sources

  • Checkmarx: Ongoing Supply Chain Security Incident Update.
  • Jenkins: Checkmarx AST Scanner releases.
  • Snyk: Embedded Malicious Code in Checkmarx Jenkins AST Scanner.
  • The Hacker News: TeamPCP Compromises Checkmarx Jenkins AST Plugin.
  • SecurityWeek: Checkmarx Jenkins AST Plugin Supply Chain Attack.

Share post:

spot_imgspot_img

Popular

More like this
Related

Critical PHP Object Injection Vulnerability Found in GiveWP Plugin

A recently discovered vulnerability in the GiveWP plugin poses...

AI Advances Strengthen Cybersecurity: Wordfence Unveils Critical Vulnerability Discovery

Wordfence has revealed significant advancements in its incorporation of...

Critical Unauthenticated Account Takeover Vulnerability Found in TranslatePress Plugin

On August 11, 2026, a significant security vulnerability was...

Hackers Target WordPress Sites in miniOrange Authentication Bypass Attacks

In recent weeks, hackers have escalated their attacks on...