Inside the TeamPCP Supply Chain Campaign: From Trivy to LiteLLM to the Checkmarx Jenkins Plugin

TeamPCP, the threat actor behind a multi-month CI/CD supply chain campaign active since March 2026, published a malicious version of the Checkmarx Jenkins Application Security Testing (AST) plugin checkmarx-ast-scanner-2026.5.09 to the Jenkins Marketplace, with the compromise disclosed by Checkmarx on May 8, 2026.

The trojanized plugin allowed attacker-controlled code to execute inside Jenkins environments with the same privileges as legitimate CI security scan jobs, including access to cloud credentials, Kubernetes service account tokens, signing keys and deployment pipelines.

The Checkmarx Jenkins AST plugin compromise is part of the broader TeamPCP supply chain campaign tied to CI/CD ecosystem intrusions that first became public following the March 20, 2026 compromise of Aqua Security Trivy and associated GitHub Actions activity tracked as CVE-2026-33634 (CVSS 9.4). Subsequent activity attributed to TeamPCP included the compromise of Checkmarx KICS through a related GitHub Actions intrusion, followed by expansion into Docker Hub, PyPI, npm, OpenVSX and AI tooling ecosystems, including LiteLLM and downstream package distribution.

This blog covers the campaign timeline, the attack chain, the indicators to hunt for in Jenkins and Kubernetes environments, and the response runbook prioritized for the first hour after a confirmed install.

How the Attack Chain Executes Inside Jenkins

Once installed, the backdoored Checkmarx Jenkins AST plugin executes malicious code under the same privileges Jenkins already grants to legitimate scan jobs, which typically include cloud credentials, Kubernetes access, signing capabilities and production deployment authority. The chain runs in five stages, each visible in a different part of the environment: initialization, credential reads, outbound network, persistence and downstream artifact publishing.

Initial Execution

The malicious checkmarx-ast-scanner-2026.5.09.hpi loads inside Jenkins through normal plugin lifecycle hooks. No additional authentication is required, because the plugin arrived through the Jenkins Marketplace signed, versioned and registered as a trusted update. Jenkins administrators who installed or auto-updated the plugin after the malicious version landed in the Marketplace have already executed the attacker's code path, with no operator action required beyond the routine plugin update.

Credential Harvesting

The plugin enumerates the Jenkins environment for cloud credentials (AWS, GCP, Azure), Kubernetes service account tokens, signing keys, SSH keys, container and package registry credentials and environment variables a scan plugin has no legitimate reason to read. Filesystem reads consistent with this stage include ~/.aws/credentials, ~/.kube/config, ~/.docker/config.json and ~/.npmrc, alongside Jenkins-managed credential stores reachable from the plugin context. Researchers report identical credential targeting in the earlier Trivy, KICS and LiteLLM stages of the TeamPCP campaign, which means hunting signatures from those stages map directly here.

Exfiltration

Encrypted outbound traffic from Jenkins ships harvested credentials to attacker-controlled infrastructure. Egress runs over HTTPS and DNS during plugin execution windows in long-tail beacon patterns that blend with normal Jenkins update and telemetry flows, which is why static allowlists alone do not catch the activity at the perimeter. Arctic Wolf and Palo Alto Unit 42 have published behavioral hunting signatures across the earlier TeamPCP stages and are the authoritative sources for current C2 domains, beacon URLs and file hashes.

Persistence and Propagation

TeamPCP establishes persistence inside Jenkins through plugin reinstall hooks designed to re-execute the malicious code path on plugin update or reactivation events, so removing the plugin artifact alone isn’t sufficient to clear the foothold. From that foothold, the campaign pivots toward Kubernetes clusters reachable from harvested kubeconfig files, GitHub Actions workflows reachable through stolen tokens and downstream artifact registries, including npm packages, container images and signed-release pipelines. The LiteLLM stage of the campaign demonstrated explicit Kubernetes propagation behavior including multi-stage loaders, and the Jenkins compromise is structurally aligned with that pattern.

Downstream Supply Chain Impact

A compromised Jenkins instance typically holds publish-level credentials for npm packages, container registries, and signed release pipelines, which gives TeamPCP a direct path to poison downstream consumers of every artifact the victim ships. The propagation chain runs from Jenkins-held credentials to the registry of record to every consumer pulling the next tagged release, including transitive dependents one or more layers removed from the original victim. The downstream npm package compromises already attributed to TeamPCP in earlier stages of the campaign are operational proof this propagation path is in active use.

The TeamPCP Campaign Timeline: From Trivy to the Jenkins Marketplace

The Checkmarx Jenkins AST plugin compromise is the latest stage in a TeamPCP supply chain attack campaign that began surfacing in March 2026 and has consistently targeted security tooling and developer infrastructure rather than downstream applications. Each stage has expanded both the target set and the operational sophistication of the campaign.

The May 8 disclosure of the Jenkins Marketplace compromise is the public surface of a foothold that TeamPCP has held inside Checkmarx infrastructure since March 23, 2026 (Stage 2), with continued or renewed activity through the April 22 second wave (Stage 5) and the April 25 LAPSUS$ release of stolen data (Stage 6). Defenders sizing log retention and incident scope should treat March 23, 2026 as the effective start of TeamPCP exposure for any environment that pulled Checkmarx-distributed artifacts between March 23 and May 10, not the May 8 disclosure date.

Every TeamPCP intrusion in this timeline targets a security vendor or a developer-tooling vendor, never a downstream application. Stage 6, the LAPSUS$ release of data TeamPCP exfiltrated on March 30, extends the campaign's downstream reach through a second threat actor and a second distribution channel without breaking that pattern. The pattern itself is what separates the TeamPCP campaign from earlier software supply chain attacks: compromising security tooling provides faster access to production infrastructure than attacking applications directly, because security tooling already holds the credentials, the network reach and the deployment authority that an attacker would otherwise reach only through escalation

Trivy and KICS read across every repository they scan. LiteLLM centralizes API keys for multiple LLM providers (OpenAI, Anthropic, and others) in a single proxy. The Checkmarx Jenkins AST plugin runs inside the build process with publish authority over every artifact the pipeline ships. Each compromise reaches every downstream consumer of the affected tooling through a single supply chain attack on the vendor.

For defenders, the operational takeaway is that CI/CD security can’t stay separate from production security. Every stage of the campaign so far has used CI/CD as the access path to production, which makes the TeamPCP campaign a CI/CD supply chain attack against every organization that installs the affected tooling, not a vendor-specific incident contained at the vendor. A software supply chain attack on a security tool propagates by the same mechanics as a software supply chain attack on a build artifact: the trusted distribution channel is the propagation vector, and signature verification confirms provenance, not integrity.

Indicators of Compromise (IOCs) and Behavioral Signals

Hunting for TeamPCP activity in a Jenkins environment is primarily a behavioral exercise. The malicious plugin executes during normal Jenkins job lifecycle events, so the operational signals are anomalous credential access, unexpected outbound network activity, and lateral movement attempts toward Kubernetes and GitHub Actions.

Plugin versions to audit

Confirm every Checkmarx Jenkins AST plugin install against the tables below. Any host that pulled a 2026.5.09 build during the Marketplace window should be treated as a confirmed compromise.

Environments that also pulled Checkmarx OpenVSX extensions during the March 23 round should audit against the cross-stage VSIX hashes:

Jenkins behavioral indicators

Hunt the Jenkins controller and any connected build agent for the following during the plugin execution window:

• Plugin process reading environment variables a scan plugin does not require for legitimate operation: cloud secrets, GitHub tokens, registry credentials.
• Plugin process reading ~/.aws/credentials, ~/.kube/config, ~/.docker/config.json, or ~/.npmrc during scan operations.
• Plugin process spawning shell processes, including sh, bash during scan operations.
• Presence of an injected runner script named setup.sh on CI runners, derived from the same campaign pattern Checkmarx documented for the March 23 GitHub Actions stage.
• File or log strings matching tpcp.tar.gz, tpcp-docs, docs-tpcp, aquasecurity or checkmarx.zone in Jenkins workspaces, runner logs or GitHub Actions run output.

Network indicators

Block and hunt for the following infrastructure across Jenkins controllers, build agents, GitHub Actions runners and developer workstations:

Outbound HTTPS or DNS traffic from Jenkins runners to any of the destinations above during the plugin execution window should be treated as a confirmed compromise. More broadly, any outbound traffic from Jenkins runners to domains not on the application allowlist during the plugin execution window warrants investigation, especially long-tail beacon patterns originating from plugin process contexts.

Kubernetes and CI/CD lateral movement indicators

After credential harvest, TeamPCP's known behavior pivots into Kubernetes and adjacent CI/CD infrastructure. Hunt the following on any cluster reachable from a harvested kubeconfig and on any GitHub organization reachable from a stolen PAT or OIDC token:

• Service account token enumeration across namespaces, especially listing or reading secrets the affected workload does not normally touch.
• Unexpected privileged pod creation, including pods that mount host filesystems, request privileged security contexts, or attach to host networking.
• Discovery activity against in-cluster registries, secrets, and Git credentials, including unusual kubectl get secrets or kubectl get configmap patterns sourced from harvested credentials.
• GitHub Actions workflow modifications during or after the campaign exposure window, including repository renames, release artifact changes, or unexpected commits to .github/workflows that match the operational pattern documented in earlier stages.

Immediate Response: The First-Hour Runbook

The response priority for a TeamPCP Jenkins plugin compromise is to identify exposure, remove the malicious plugin, rotate every credential the Jenkins environment could have touched and audit downstream artifacts for poisoned releases. 

1. Identify every Jenkins instance running any version of the Checkmarx Jenkins AST plugin. Include shadow instances, archived environments, and developer-managed Jenkins controllers. Cross-check each install against the malicious 2026.5.09 build and flag any host that pulled from the Jenkins Marketplace between May 9 01:25 UTC and May 10 08:47 UTC.
2. Remove the compromised checkmarx-ast-scanner-2026.5.09 plugin immediately. Replace with a verified safe release: the pre-incident 2.0.13-829.vc72453fa_1c16 (Dec. 17, 2025) or the post-remediation 2.0.13-848.v76e89de8a_053 or 2.0.13-847.v08c0072b_2fd5 both released May 9, 2026, requiring Jenkins 2.452.4.
3. Treat every credential the affected Jenkins instance had access to as compromised. Rotate cloud credentials (AWS, GCP, Azure), Kubernetes service account tokens and kubeconfigs, GitHub tokens including Personal Access Tokens (PATs), signing keys, SSH keys, container and package registry credentials, Checkmarx API tokens and any Slack or Jira API tokens reachable from the plugin context.
4. Pull Jenkins controller logs, build agent logs, and outbound network logs from May 8, 2026 onward. Extend retention back to March 23, 2026 for environments that also consumed Checkmarx GitHub Actions or OpenVSX extensions during the broader campaign. Hunt for anomalous outbound traffic to checkmarx[.]zone and the three Checkmarx subdomains in the IOC table, credential reads against ~/.aws/credentials, ~/.kube/config, ~/.docker/config.json and ~/.npmrc and shell process spawning from the plugin context.
5. Audit GitHub Actions workflows, deployment pipelines and Kubernetes activity for unauthorized modifications during the exposure window. Look for repository renames, release artifact changes, unexpected commits to .github/workflows, privileged pod creation and service account token enumeration matching the TeamPCP pattern documented in earlier stages.
6. Inventory artifacts published by the affected Jenkins instances during the May 9 to May 10 Marketplace window. Validate signing chains and provenance for every container image, npm package and signed release. Hold or recall artifacts that cannot be verified.
7. Segment CI/CD infrastructure from sensitive production systems if segmentation is not already in place. Treat Jenkins as a production-adjacent system, not a lower-trust developer tool. The privileges the Checkmarx Jenkins AST plugin holds inside the build process are production privileges.
8. Notify downstream consumers of any artifacts that cannot be confirmed clean. The campaign has demonstrated downstream supply chain poisoning behavior and silence accelerates the blast radius. LAPSUS$ published TeamPCP-exfiltrated Checkmarx data on April 25, 2026, demonstrating that data taken in one campaign stage reappears in public channels through secondary threat actors.

Why Conventional Tooling Caught the Plugin Install But Missed the Compromise

Most security tools detected that the Checkmarx Jenkins AST plugin was installed and even logged the version. Few of them flagged the runtime behavior that turned a routine plugin install into a CI/CD compromise: credential enumeration, anomalous filesystem reads, and unexpected outbound network activity from the plugin context.

Static dependency scanning sees the package, not the behavior. A signed plugin from a trusted vendor distributed through the Jenkins Marketplace looks identical to a benign release in a software bill of materials. The compromise becomes visible only at runtime, when the plugin starts doing things a CI/CD scanner has no operational reason to do: reading ~/.aws/credentials, spawning shell processes during a scan and beaconing to checkmarx[.]zone.

Three Kodem capabilities cover the runtime gap this incident exposes:

• Kodem SCA can identify the affected com.checkmarx.jenkins:checkmarx-ast-scanner package and flag the malicious Jenkins AST plugin version when it appears in a scanned dependency graph, SBOM, image or artifact inventory.
• Kodem ADR (Application Detection and Response) is built to detect the runtime behaviors these compromises produce, including credential access, anomalous filesystem activity and unexpected outbound traffic from CI/CD execution paths. 
• Kodem Malicious Package Detection complements this by identifying known malicious packages and artifacts tied to the broader TeamPCP campaign when they appear in scanned software assets.

Hardening CI/CD Against the Next TeamPCP Stage

TeamPCP is unlikely to stop with the Checkmarx Jenkins plugin. The campaign has expanded consistently for three months and continues to target security tooling specifically because that tooling sits inside privileged execution paths. Operate on the assumption that the next stage is already in development.

1. Treat security tooling as production-adjacent. The privileges granted to Jenkins, Checkmarx, Trivy, KICS and similar tools are production privileges. Apply production-level access controls.
2. Eliminate long-lived secrets in CI/CD environments. Move to short-lived, scoped, federated credentials: OIDC to cloud providers, GitHub Actions OIDC, Vault dynamic secrets. A token that expires in 15 minutes cannot be exfiltrated as effectively as one that lives for months. The TeamPCP campaign harvested long-lived credentials from build environments at every stage, and short-lived federated tokens neutralize that path.
3. Segment CI/CD runners from production infrastructure. A compromised Jenkins job should not have network reach to production data planes, only to artifact registries and deployment APIs. Apply the same segmentation to GitHub Actions runners and any self-hosted runners reachable from a compromised plugin.
4. Validate plugin and tool integrity beyond signature checks. Signature checks confirm a vendor signed the artifact. Signature checks do not confirm the artifact is benign when the vendor has been compromised. Add runtime behavioral validation for new plugin installs, especially for plugins that hold cloud credentials, signing keys, or publish authority over downstream artifacts.
5. Monitor outbound network from CI/CD runners. Anomalous outbound activity from a build or scan job is one of the most reliable early signals of supply chain compromise. Pair egress monitoring with allowlist denial-by-default so beacons to non-allowlisted destinations surface during the plugin execution window, not after a downstream artifact ships.
6. Audit security tooling configurations for unnecessary privileges. A scanner does not need Kubernetes admin. A linter does not need cloud write access. Strip privileges to the minimum the tool actually requires, and review the privilege scope of every security plugin at install time.
7. Track the TeamPCP campaign feed. Build the assumption of frequent campaign expansion into your patch and rotation cadence.

What the TeamPCP Campaign Reveals About CI/CD Threat Trajectory

The TeamPCP campaign is the clearest signal yet that CI/CD infrastructure has become a primary attack surface, not a secondary one. The economics favor the attacker: compromising one Jenkins plugin gives access to credentials, signing keys and deployment authority across every organization that installs the plugin.

Three trends define the trajectory:

• Attackers are increasingly compromising security tooling specifically because it already possesses the privileges they want. Trivy, KICS, LiteLLM, and the Checkmarx Jenkins AST plugin all share this profile.
• CI/CD environments now function as identity hubs, cloud orchestration layers and deployment control planes simultaneously. The blast radius of a single compromise has expanded structurally over the last three years.
• Trusted release channels, including marketplaces, package registries and  plugin directories are themselves becoming attack vectors. Signature checks confirm provenance but don’t confirm integrity when the provenance source itself has been compromised.

By end of Q3 2026, expect TeamPCP or a closely related actor to publish a malicious artifact through a major language-package registry, such as npm, PyPI and RubyGems by leveraging credentials harvested from one of the security-tooling compromises. The propagation chain is already in place: the campaign has demonstrated worm-like propagation through npm packages and has already exfiltrated credentials with publish authority over multiple registries. The campaign timeline shows acceleration, not slowdown: seven distinct stages surfaced between March 20 and May 9, 2026.

Frequently Asked Questions

1. Who is TeamPCP? TeamPCP is the threat actor designation used by Palo Alto Unit 42, Arctic Wolf, Endor Labs and other research teams to track a multi-month CI/CD supply chain campaign that has compromised Aqua Security Trivy, the Checkmarx ast-github-action and kics-github-action repositories, the Checkmarx OpenVSX extensions, LiteLLM, downstream npm packages and most recently the Checkmarx Jenkins AST plugin in May 2026.
2. What is CVE-2026-33634? CVE-2026-33634 tracks the Aqua Security Trivy supply chain compromise announced on March 20, 2026 (Stage 1 of the TeamPCP campaign). The CVE covers the force-pushed Trivy v0.69.4 build and the poisoned aquasecurity/trivy-action and setup-trivy GitHub Actions, not the May 2026 Checkmarx Jenkins AST plugin compromise, which the Checkmarx incident update tracks without a separate CVE.
3. Which versions of the Checkmarx Jenkins AST plugin are compromised? The compromised release is checkmarx-ast-scanner-2026.5.09 (file checkmarx-ast-scanner-2026.5.09.hpi), which was live on the Jenkins Marketplace from May 9, 2026 at 01:25 UTC to May 10, 2026 at 08:47 UTC. The last clean release prior to that window is 2.0.13-829.vc72453fa_1c16 (published December 17, 2025). Checkmarx released two safe post-remediation versions on May 9, 2026: 2.0.13-848.v76e89de8a_053 and 2.0.13-847.v08c0072b_2fd5 both require Jenkins 2.452.4.
4. How do I know if my environment was affected by TeamPCP? Audit Jenkins instances for the checkmarx-ast-scanner-2026.5.09 plugin. Pull outbound network logs from May 8, 2026 onward and look for connections to checkmarx[.]zone, checkmarx.cx, audit.checkmarx.cx, updates.checkmarx.cx or any other non-allowlisted domains. Check Jenkins controllers and build agents for plugin reads against ~/.aws/credentials, ~/.kube/config, ~/.docker/config.json and ~/.npmrc, plus shell process spawning from the plugin context during scan operations.
5. What credentials does TeamPCP target? Cloud credentials (AWS, GCP, Azure), Kubernetes service account tokens and kubeconfigs, GitHub tokens including Personal Access Tokens (PATs), signing keys, SSH keys, container and package registry credentials, Checkmarx API tokens and environment variables. The campaign consistently targets the credentials that give attackers production deployment authority and downstream supply chain control.
6. How does this differ from earlier supply chain attacks like Codecov or SolarWinds? TeamPCP focuses specifically on security tooling and developer infrastructure rather than general software vendors. The targets (Trivy, KICS, LiteLLM, and the Checkmarx Jenkins AST plugin) all share the same operational profile: they sit inside CI/CD pipelines with elevated privileges. This makes them faster paths to production access than attacking shipping applications directly.
7. Can SCA tools detect TeamPCP compromises? SCA tools detect that the affected Checkmarx Jenkins AST plugin is installed and flag the version match. They don’t detect the runtime behavior the compromise produces, including credential enumeration, anomalous filesystem reads and outbound network beaconing. Runtime detection is required to close that gap.
8. What is the fastest way to stop downstream propagation from a compromised CI/CD environment? Rotate every credential the affected Jenkins instance could have accessed before doing anything else, then inventory and validate artifacts published between May 9 01:25 UTC and May 10 08:47 UTC. Credential rotation closes the propagation path. Artifact validation closes the downstream blast radius.

References

1. Arctic Wolf. March 25, 2026. TeamPCP Supply Chain Attack Campaign Targets Trivy, Checkmarx (KICS), and LiteLLM (Potential Downstream Impact to Additional Projects). Arctic Wolf. 
2. Checkmarx. May 12, 2026. Update: Ongoing Checkmarx Supply Chain Security Incident. Checkmarx.
3. Kodem Security. March 31, 2026. When the Supply Chain Becomes the Attack Surface: Inside the TeamPCP Campaign. Kodem Security.
4. Kodem Security. April 28, 2026. Bitwarden CLI Supply Chain Compromise: Trusted Secrets Tooling Becomes the Entry Point. Kodem Security.
5. Kodem Security. April 30, 2026. The Shai-Hulud Worm Returns: New npm Supply Chain Attack Compromises SAP Packages. Kodem Security.
6. Kodem Security. May 1, 2026. Mini Shai-Hulud Strikes PyTorch Lightning and intercom-client: Inside the Cross-Ecosystem Supply Chain Attack. Kodem Security.
7. NVD. March 23, 2026. CVE-2026-33634 Detail. NVD.
8. Palo Alto Networks Unit 42. March 31, 2026. Weaponizing the Protectors: TeamPCP’s Multi-Stage Supply Chain Attack on Security Infrastructure. Unit 42. 
9. The Hacker News. May 11, 2026. TeamPCP Compromises Checkmarx Jenkins AST Plugin Weeks After KICS Supply Chain Attack. The Hacker News.