Skip to main content
root@rebel:~$ cd /news/threats/checkmarx-jenkins-ast-plugin-compromised-in-teampcp-attack_
[TIMESTAMP: 2026-05-11 20:39 UTC] [AUTHOR: Runtime Rebel Intel] [SEVERITY: CRITICAL]

Checkmarx Jenkins AST Plugin Compromised in TeamPCP Attack

CRITICAL Supply Chain #Checkmarx#Jenkins#TeamPCP
AI-Assisted Analysis
READ_TIME: 3 min read
// executive briefing tl;dr
  • [01] Attackers compromised the Checkmarx Jenkins AST plugin on the official marketplace, potentially exposing build environments to unauthorized access or data exfiltration.
  • [02] This supply chain attack affects Checkmarx Jenkins AST plugin versions published after December 17, 2025, specifically those found in the Jenkins Marketplace.
  • [03] Organizations must immediately revert to or pin the Checkmarx Jenkins AST plugin version 2.0.13-829.vc72453fa_1c16 to ensure environment integrity.

Compromise Overview

According to The Hacker News, the security community has identified a significant breach involving the Checkmarx Jenkins AST plugin. This incident represents a sophisticated Supply Chain Attack orchestrated by an actor identified as TeamPCP. The attackers successfully uploaded a modified, malicious version of the plugin directly to the Jenkins Marketplace, bypassing standard validation procedures. This incident follows closely on the heels of a previous attack targeting the KICS platform, suggesting a persistent campaign against CI/CD infrastructure by this APT group.

Technical Analysis: How to Detect Checkmarx Jenkins AST Plugin Exploit

Security teams must understand that an AST (Application Security Testing) plugin operates within the heart of the development lifecycle. Because these tools are designed to analyze source code for vulnerabilities, they inherently require read access to repositories and often possess write access to reporting servers. In the context of this Supply Chain Attack, a compromised plugin could facilitate Lateral Movement or execute unauthorized RCE within the build runner environment.

To verify if your environment is impacted, SOC analysts should prioritize auditing the Jenkins plugin directory. The primary IoC is the presence of any version newer than the authenticated 2.0.13-829.vc72453fa_1c16 release published on December 17, 2025. Organizations utilizing automated update mechanisms for Jenkins plugins are at the highest risk, as the malicious version may have been silently pulled into the environment.

The TTP used by TeamPCP suggests an intimate knowledge of the Jenkins ecosystem. By compromising the marketplace entry, the actors ensured that their malicious code would carry a veneer of legitimacy, complicating standard EDR detection. Defenders should look for unusual outbound network connections originating from Jenkins build nodes, which may indicate a C2 callback or data exfiltration attempts.

Impact on CI/CD Pipelines

A malicious AST plugin does more than just compromise the current build; it poisons the trust in the entire security testing process. If the tool used to identify CVE entries in your code is itself compromised, it can be programmed to ignore specific backdoors or report false negatives, allowing further vulnerabilities to reach production. This underscores the need for a Zero Trust approach to DevOps security, where even security-focused tools are subjected to rigorous integrity checks and MITRE ATT&CK mapping for defensive coverage.

Mitigating the TeamPCP Jenkins Marketplace Compromise

The most effective response to the TeamPCP Jenkins marketplace compromise is the immediate pinning of plugin versions. Checkmarx has explicitly stated that version 2.0.13-829.vc72453fa_1c16 is the last known safe version and must be used for all active pipelines.

  • Inventory all Jenkins instances and check the Manage Plugins section for version numbers.
  • Disable the Update Center temporarily to prevent automatic ingestion of malicious versions until a verified update is released.
  • Validate the checksums of all installed .hpi files against known good hashes provided by official vendor channels.
  • Review SIEM logs for any administrative changes to the Jenkins configuration during the window of compromise.

Defenders should also consider using binary authorization or local plugin mirrors where updates are manually vetted before being promoted to production build servers. This incident highlights why relying solely on third-party marketplaces without independent verification remains a high-risk practice for modern software development environments.

Advertisement