The images in this article were generated with artificial intelligence. How we publish
The publication of a manipulated version of the Jenkins AST plugin associated with Checkmark once again puts on the table the most dangerous threat of the moment: the abuse of confidence in the software supply chain. According to information issued by the company itself, there was a malicious version and Checkmark has indicated that users should make sure that they are in the secure version. 2.0.13-829.vc72453fa _ 1c16(published on December 17, 2025) or in the later release of the company officially published; when writing this text the firm has already started to distribute an additional corrected version ( 2.0.13-848.v76e89de8a _ 053) in both its repository and the Jenkins Marketplace. To review and download plugins from the official channel you should use the Jenkins ecosystem website: https: / / plugins.jenkins.io /.
The actor attributed to the attack, known as TeamPCP, has demonstrated a consistent pattern of operations: unauthorized access to repositories, manipulated publications and temporary replacement of legitimate components by malware designed to steal credentials and secrets from developers. The same group was noted weeks ago in incidents against Docker images, VS Code extensions and GitHub Actions workflows, and these intrusions resulted in consumer package commitments as a npm package used by Bitwarden's CLI. Repeating the intrusion suggests continued or failed mediation- either because critical credentials were not rotated or because a hidden access was maintained, and it forces organizations and developers to assume that any element of the supply chain could be affected.

If your organization uses the affected plugin, the first step is immediately update to the latest verified version published by Checkmarx in official sources and not rely on updates that can be reached by unverified channels. After the update, it assumes that the secrets accessible to the plugin may have been compromised: rotate tokens, keys and credentials that the plugin could use (including CI / CD credentials, repository tokens and API keys), check the logs and deployment tracks for unusual activity and auditing images and artifacts generated by the pipelines during the exposure period.

In order to reduce the risk in the future, it is essential to add technical and governance controls: limitation of privileges of plugins and service accounts, use of ephemeral tokens in pipelines, restrictions of egress / networking from CI to unauthorized destinations, review and signature of artifacts before publishing them and strict policies of access to repositories with Multifactor authentication and credentials rotation. Good security practices in the supply chain and GitHub's guide on the subject can be a good starting point for designing controls: https: / / docs.github.com / en / code-security / supply-chain-security.
In addition to technical measures, there are concrete operational steps that should be taken: validating the integrity of the binaries or downloaded packages (checksums / signatures), checking the history and branches of the plugin repository in search of suspicious commitments and tags, and coordinating with the supplier to obtain commitment indicators (IOCs) and a detailed report. If you detect signs of the exfiltration or execution of unauthorized payloads, it acts as if the infrastructure had been compromised and activates the incident response processes, including reporting to affected parties and mitigation services.
Finally, project maintainers and security equipment must review their internal procedures: to restrict who can publish releases, to require automated reviews and checks before publishing artifacts, to enable alerts to sudden changes in repository metadata and to educate developers on the risk of installing unvalidated third party extensions. The community can also contribute by reviewing and monitoring critical plugins; supply chain security is a collective problem and information shared by independent specialists and firms helps to detect and contain campaigns such as that attributed to TeamPCP. To expand the information about Checkmarx and follow your official communications visit https: / / checkmarci.com / and keep an eye on the information from the Jenkins supplier and ecosystem.
Related
More news on the same subject.

Four Plex2Shell CVE allows remote execution and mining and proxy backdoor deployment
In recent days, an increase in attacks has been confirmed that take advantage of a chain of failures in Plex Media Server - nicknamed "Plex2Shell" by researchers - to run code r...

GhostAction Expands Attack: phishing to steal credentials and persistence in VS Code
A group behind the GhostAction campaign - already known for infiltrating GitHub Actions workflows into open source projects - has expanded its arsenal: in addition to installing...

OpenCode: possible exposure of AI suppliers in Console affects 1.4% of users
On the night of October 16 there was an unauthorized access to a system inherited from OpenCode which, according to the company, could have exposed keys from IA suppliers that u...

ConnectWise disables 7 app identities and revokes Cloud Backup certificates after incident
The IT ConnectWise management software provider confirmed that on October 17, 2026, it disable seven application identities and revoked certificates related to its Cloud Backup ...

Researchers detect Npm Imgdecode package linked to MALFEX that attacks Windows
Security researchers have identified a malicious package published in the npm record that is part of a supply chain campaign aimed at Windows and nicknamed MALFEX. The package, ...

OpenBSD 7.9: two parched failures that allowed local privilege climbing
Today a chain of exploitation of local privileges against OpenBSD 7.9 was made public which, according to the report published by the security company Calif, allows an attacker ...