Checkmarx Jenkins AST Plugin Compromise: IOCs, Malicious Artifacts, and Defender Response

Why This Matters

This incident abused the normal Jenkins plugin trust path rather than a suspicious sideloading flow. That matters because Jenkins plugins execute inside CI/CD infrastructure that already has access to source code, build secrets, and deployment material.

Affected Package Coordinates

Jenkins Plugin Manager
checkmarx-ast-scanner:2026.5.09

Known clean replacement coordinates
checkmarx-ast-scanner:2.0.13-848.v76e89de8a_053
checkmarx-ast-scanner:2.0.13-847.v08c0072b_2fd5

Verified Claims

Claim 1: A malicious Jenkins plugin release was distributed under the expected Checkmarx plugin identity

Verified.

• The Kodem reporting ties the malicious release to the broader TeamPCP campaign.
• The structured artifact set for this slug includes the exact plugin coordinate and hashes for the .hpi, .jar, and .pom artifacts associated with the compromised release.

Why this matters: The attack did not need a separate loader path if administrators or automation already trusted the plugin update channel.

Claim 2: The compromise exposed Jenkins environments to the same campaign infrastructure seen elsewhere in TeamPCP activity

Verified with high confidence.

• The slug data includes repeated TeamPCP-associated infrastructure such as checkmarx.zone, checkmarx.cx, audit.checkmarx.cx, and updates.checkmarx.cx.
• Kodem links the Checkmarx wave to the same campaign family observed in adjacent CI/CD compromises.

Why this matters: Analysts can treat the Jenkins plugin incident as part of a broader infrastructure cluster instead of a fully isolated event.

Claim 3: The operational risk comes from plugin lifecycle execution inside CI/CD, not just from a malicious file sitting in storage

Verified by architecture and source context.

• Jenkins plugins normally execute with controller-side privileges and can influence pipelines, agent behavior, and credentialed jobs.
• The incident reporting and dataset focus on controller logs, runner logs, and artifact provenance because execution happens in a trusted automation plane.

Why this matters: Even short-lived installation or upgrade events can expose high-value secrets if the plugin executes before containment.

Attack Chain

1. A malicious checkmarx-ast-scanner release was made available through the expected plugin distribution path.
2. Jenkins administrators or automated plugin-management processes resolved the compromised release.
3. Plugin lifecycle execution occurred inside Jenkins infrastructure.
4. Follow-on activity aligned with known TeamPCP infrastructure and artifact names such as tpcp.tar.gz and setup.sh.
5. Controllers, workspaces, and agents became retro-hunt targets for credential exposure or follow-on staging.

Technical Mechanics

Execution Surface

The important execution point here is the plugin lifecycle itself. A Jenkins plugin does not need to masquerade as an application dependency post-install; it already lands in a location where Jenkins loads trusted code.

Artifact Evidence

checkmarx-ast-scanner-2026.5.09.hpi
01ff1e56fd59a8fa525d97e670f7f297a1a204331b89b2cd4e36a9abc6419203

checkmarx-ast-scanner-2026.5.09.jar
f50a96d26a5b0beb29de4127e82b2bf350c21511e5a43d286e43f798dc6cd53f

checkmarx-ast-scanner-2026.5.09.pom
3ddb8967919a801b3c383e58cddceab21138134c6a26560d99e2672e86f36f2a

Infrastructure

checkmarx.zone
checkmarx.cx
91.195.240.123
audit.checkmarx.cx
94.154.172.43
updates.checkmarx.cx
94.154.172.183

The combination of plugin artifacts plus campaign domains is the strongest way to anchor historical exposure.

Detection Opportunities

rg -n "checkmarx-ast-scanner:2026.5.09|checkmarx.zone|checkmarx.cx|audit.checkmarx.cx|updates.checkmarx.cx|tpcp.tar.gz|setup.sh" /var/lib/jenkins "$WORKSPACE"

Analyst focus:

• plugin inventory and update logs
• controller outbound network connections
• workspaces containing tpcp.tar.gz or setup.sh
• secret material available to jobs that ran after the plugin change

Open Questions And Confidence Notes

• The linkage to TeamPCP is strongly supported by the cited reporting, but the exact code path inside the malicious plugin is less directly documented than the artifact and infrastructure evidence.
• The dataset is strongest on compromised artifact identification and follow-on network indicators.
• If additional reverse-engineering of the plugin internals becomes available, that should be merged into this slug as a later refinement.

Sources

• Kodem TeamPCP Checkmarx Jenkins research
• Halting Problems structured artifact and IOC dataset