Checkmarx Tackles Another TeamPCP Intrusion as Jenkins Plugin Sabotaged

Why It Matters

A backdoored CI plugin can silently infiltrate thousands of build pipelines, compromising proprietary code and credentials across enterprises. The repeat attacks highlight persistent weaknesses in software‑supply‑chain governance, urging firms to tighten verification and secret‑rotation practices.

Key Takeaways

• Malicious Checkmarx Jenkins AST plugin uploaded to Jenkins Marketplace
• Only version 2.0.13-829.vc72453fa_1c16 (Dec 2025) is trusted
• TeamPCP has breached Checkmarx three times in three months
• Compromise gives attackers access to source code, tokens, and secrets
• Users urged to verify plugin version and remove unauthorized releases

Pulse Analysis

Supply‑chain attacks have moved from rare headlines to a systemic threat, and the Checkmarx episode underscores how even security‑focused vendors can become vectors. The TeamPCP group, known for targeting development tools, has now struck three of Checkmarx’s products in as many months, exploiting the trust developers place in official plugins. By inserting malicious code into a Jenkins plugin—a cornerstone of many CI/CD pipelines—the attackers gain a foothold that can harvest source repositories, environment variables, and authentication tokens without raising immediate alarms.

Jenkins remains the most widely adopted automation server for building, testing, and deploying software, and its plugin ecosystem is a double‑edged sword. While plugins extend functionality, they also expand the attack surface, especially when the marketplace’s verification mechanisms rely on publisher reputation rather than rigorous code signing. The compromised AST scanner could silently exfiltrate secrets from any pipeline that trusts the plugin, potentially affecting hundreds of organizations that have already installed the rogue version. This incident illustrates the danger of a “trusted‑infrastructure” model where a single compromised component can cascade across an entire software supply chain.

For enterprises, the immediate response is clear: audit all Jenkins installations, confirm the running version matches the officially sanctioned 2.0.13‑829.vc72453fa_1c16 release, and remove any suspect builds. Longer‑term strategies include adopting signed plugins, implementing zero‑trust principles for CI tools, and rotating secrets frequently to limit exposure. Industry observers predict that regulators may soon mandate stricter supply‑chain attestations, pushing vendors toward transparent provenance and automated integrity checks. Organizations that proactively harden their CI pipelines will be better positioned to withstand the next wave of supply‑chain intrusions.