The Checkmarx Jenkins Supply Chain Incident
A security firm that helps organizations find vulnerabilities in their code found itself on the receiving end of a sophisticated attack. Over a recent weekend, Checkmarx alerted the public that a fraudulent version of its Jenkins Application Security Testing plugin had been uploaded to the official Jenkins Marketplace. The group calling itself TeamPCP claimed responsibility, marking yet another chapter in an ongoing series of supply chain intrusions targeting development tools.
Jenkins remains one of the most widely adopted platforms for continuous integration and continuous deployment. Teams rely on it to build, test, scan, and ship software automatically. When a plugin that performs security scanning becomes a vehicle for malware, the implications ripple across every organization using that tool. This incident did not happen in isolation. It followed earlier compromises involving the Trivy vulnerability scanner and the Shai-Hulud campaigns on npm, both attributed to the same threat actor.
Understanding what happened matters for anyone who manages a Jenkins pipeline. But knowing how to detect whether your environment has been affected is even more critical. Below are five specific signs that indicate your checkmarx jenkins compromised scenario may be real, along with the actions you should take immediately.
1. The Plugin Version Number Does Not Match the Official Naming Convention
The rogue version of the Checkmarx AST plugin carried the version string 2026.5.09. That alone raised red flags for observant users. The official plugin version that Checkmarx recommends is 2.0.13-829.vc72453fa_1c16, published on December 17, 2025. Any version that deviates from the established numbering pattern should trigger suspicion.
Version numbers in the Jenkins ecosystem follow a specific convention. When a plugin appears with a date-based scheme that does not align with the official release timeline, something is wrong. In this case, the malicious upload used a format that looked plausible at first glance but did not match the developer’s actual versioning system.
What to Check in Your Jenkins Instance
Navigate to the plugin management page in your Jenkins dashboard. Look at the installed version of the Checkmarx AST plugin. If it shows 2026.5.09 or any version that is not the recommended one, treat it as compromised. Cross-reference the version with the official release history available on the Jenkins plugin page or Checkmarx’s documentation.
This simple verification step takes less than two minutes. It is the fastest way to determine whether your environment may have received the backdoored package.
2. The Plugin Lacks a Git Tag or a Corresponding GitHub Release
Every legitimate release of the Checkmarx Jenkins plugin should have a corresponding git tag in the official repository and a release entry on GitHub. The malicious version uploaded on May 9 had neither. The absence of these markers signals that the package did not go through the normal build and publish workflow.
Development teams often assume that plugins available on the Jenkins Marketplace have undergone some level of validation. In practice, the marketplace relies heavily on trust in the publisher. When an attacker gains access to a publisher’s credentials, they can upload artifacts that appear authentic. The missing git tag becomes a subtle but powerful indicator that something is off.
How to Verify Git Tags
If you have access to the Checkmarx GitHub repository, you can compare the version installed in your Jenkins environment against the list of official releases. A version that does not have a corresponding tag is highly suspicious. Even if you do not have direct access to the repository, you can check public release notes or community forums for confirmation of legitimate versions.
Organizations that maintain internal mirrors of plugins should add this verification step to their update procedures. Automating the check against GitHub tags can prevent malicious versions from ever reaching production environments.
3. The Plugin Was Published Outside the Normal Release Pipeline
Checkmarx has a defined process for publishing updates to the Jenkins Marketplace. The rogue version bypassed that pipeline entirely. According to offensive security engineer Adnand Khan, the attackers used credentials stolen during the earlier Trivy compromise to access Checkmarx’s GitHub repositories. From there, they uploaded the backdoored plugin directly to the Jenkins repository.
This method of distribution means the plugin never underwent the usual quality checks, signing procedures, or internal reviews that legitimate releases go through. The attackers maintained access for at least a month after the Trivy incident, giving them ample time to study the publishing process and craft a plausible fake.
Why This Matters for Your Detection Strategy
Most organizations do not monitor the publishing pipeline of third-party plugins. After this incident, that should change. If your security team can set up alerts for plugins that appear without corresponding announcements or changelogs, you gain an early warning layer. The absence of a security advisory from the vendor before a new version appears is itself a red flag.
In this case, Checkmarx warned users after the fact. But the warning came only after the malicious plugin had been available for download. Proactive monitoring of your own environment remains the most reliable defense.
4. Unusual Behavior in Your Jenkins Environment
The purpose of the backdoored plugin was credential theft. According to reports, the malicious code harvested credentials from the environments where it ran. If you have been using the compromised version, you may observe unusual network connections, unexpected outbound traffic, or processes that attempt to read credential files.
Credential-stealing malware often operates quietly. It may not cause visible errors or performance degradation. The threat actors behind TeamPCP have demonstrated patience and precision in previous campaigns. They do not need to disrupt your operations. They only need to collect access tokens, API keys, and passwords that allow them to move laterally or compromise additional systems.
Signs That Credentials Have Been Stolen
Look for anomalies in your authentication logs. If you see login attempts from unfamiliar IP addresses using valid credentials, that could indicate stolen tokens in use. Check your CI/CD pipeline logs for commands that do not match your typical build steps. The malware may have injected additional steps that exfiltrate data.
Another indicator is unexpected changes to configuration files. If your Jenkins configuration or plugin settings have been modified without a corresponding change request or deployment, that warrants immediate investigation. The attackers may have added backdoor accounts or modified environment variables to capture secrets.
Checkmarx has published a set of indicators of compromise (IoCs) that defenders can use to scan their environments. These artifacts include file hashes, network signatures, and other forensic markers that can help confirm whether the malicious plugin executed on your systems.
5. The Plugin Metadata Shows Suspicious Authorship or Timestamps
The metadata embedded in the rogue plugin contained clues that pointed to its fraudulent origin. Apart from the version number discrepancy, the plugin lacked the usual author information and certification marks that legitimate Checkmarx releases include. The timestamps on the upload also did not align with normal business hours or release schedules.
Attackers often rush when publishing malicious artifacts. They may not replicate every detail of the official metadata. In this case, the plugin appeared on a Saturday, which is outside the typical release window for enterprise security tools. While weekend releases are not impossible, they are uncommon enough to warrant a second look.
How to Inspect Plugin Metadata
If you are comfortable working with Java archive files, you can examine the plugin’s manifest and metadata directly. Look for inconsistencies in the vendor name, the maintainer email address, or the signing certificate. A plugin that claims to be from Checkmarx but uses a different digital signature is a clear warning.
You may also enjoy reading: 5 AI-Powered Crypto Hacks: North Korea Drains $600M.
For teams that lack the expertise to perform this analysis manually, third-party security tools that scan Jenkins plugins for anomalies can help. These tools compare the metadata against known good versions and flag deviations automatically.
What to Do If You Detect Any of These Signs
If any of the five signs above match your environment, assume that your checkmarx jenkins compromised situation is real. The first step is to isolate the affected Jenkins instance from your network. Prevent the malware from communicating with command-and-control servers or exfiltrating additional data.
Next, rotate all secrets that may have been exposed. This includes API keys, database passwords, cloud provider credentials, and any tokens stored in the Jenkins environment. Do not assume that only the credentials directly used by the plugin are at risk. Once an attacker gains access to a CI/CD pipeline, they can pivot to other systems quickly.
Checkmarx recommends using version 2.0.13-829.vc72453fa_1c16 or an older known-good version of the plugin. After rotating secrets, replace the compromised plugin with the verified version. Ensure that you download it from the official source and verify its integrity using the published checksums.
Investigate for lateral movement. Review your network logs, authentication records, and system changes for signs that the attackers extended their access beyond the Jenkins server. The TeamPCP group has a history of maintaining persistence and expanding footholds across ecosystems.
The Repeated Nature of These Attacks
This incident marks the third supply chain attack Checkmarx has faced since late March. The earlier Trivy breach provided the attackers with credentials that they reused to access Checkmarx’s GitHub repositories. The hackers even left a taunting message in the plugin’s about section: “Checkmarx fails to rotate secrets again. With love – TeamPCP.”
The message underscores a critical lesson. Credential rotation is not optional. When a breach occurs, every credential that the compromised system could access must be changed immediately. Reusing old credentials after an incident creates a predictable path for attackers to return.
In late April, the LAPSUS$ threat group also leaked data stolen from Checkmarx’s private GitHub repository. The cumulative effect of these events raises questions about how security firms manage their own internal credential hygiene. If a company that sells application security testing tools can suffer repeated breaches through the same vector, every organization should examine its own practices.
Broader Implications for the Jenkins Ecosystem
Jenkins plugin marketplaces operate on a trust model. Plugin publishers are expected to secure their own infrastructure and signing keys. When that trust is broken, the entire ecosystem suffers. Users cannot easily distinguish between a legitimate update and a malicious one without external verification mechanisms.
This incident may accelerate the adoption of additional security layers for plugin distribution. Options include mandatory code signing with hardware security keys, automated integrity verification against source repositories, and community-driven monitoring of plugin behavior. Some of these measures already exist in other package ecosystems but have not been widely adopted in the Jenkins world.
For now, individual organizations must compensate with manual verification steps and diligent monitoring. The cost of a single undetected malicious plugin can be enormous, especially when it targets credential theft in a CI/CD pipeline that has access to production environments.
Protecting Your Pipeline Going Forward
The checkmarx jenkins compromised incident is not an isolated event. It fits a pattern of supply chain attacks targeting development tools and infrastructure. Threat actors understand that compromising a single plugin can give them access to hundreds or thousands of organizations simultaneously.
To protect your pipeline, adopt a principle of least privilege for your Jenkins environment. Limit what the Checkmarx plugin can access. Use dedicated service accounts with minimal permissions. Store secrets in a vault rather than in environment variables or configuration files. Monitor outbound network traffic from your CI/CD servers for unusual patterns.
Consider implementing a plugin approval workflow. Before any plugin update is applied to production Jenkins instances, have a security team member review the version, verify its source, and check for any published advisories. This adds friction to the update process, but the tradeoff is worth it when dealing with security-critical plugins.
Checkmarx has stated that its GitHub repositories are isolated from its customer production environment and that no customer data is stored there. That separation is a positive design choice, but it does not eliminate all risk. Credentials stolen from a pipeline can be used against other systems, and attackers may use the access gained through backdoored plugins to reach customer environments indirectly.
