Threat · curated 17 Jul 2026

Malicious LiteLLM Releases Tied to Trivy Hack May Have Exposed 2,100+ Organizations

Dossier

Coverage timeline

13 Jun 2026cloudsecurityalliance.o…beyondmachines.netogwilliam.comsecurelayer7.net 17 Jul 2026redhat.comthehackernews.comnist.gov 12 Aug 2026thehackernews.comarstechnica.comforkast.newsgbhackers.com+3 more

Why it matters

The LiteLLM supply-chain compromise shows how a centralized AI gateway concentrates every model-provider and cloud credential into a single high-value target, so a single poisoned release cascaded into thousands of organizations' CI/CD secrets being silently exfiltrated.

TeamPCP compromised the GitHub Actions pipeline of the Trivy scanner used in LiteLLM's CI/CD, stole LiteLLM's PyPI publishing tokens, and published malicious LiteLLM packages (versions 1.82.7 and 1.82.8) whose .pth startup-hook payload harvested AI provider credentials, cloud keys, and CI/CD secrets, attempted Kubernetes lateral movement, and installed a systemd backdoor. Hudson Rock obtained a 153GB exfiltration archive attributing 118,829 CI runner dumps to 2,488 corporate domains, and the campaign chains with additional critical LiteLLM CVEs (CVE-2026-33634, CVE-2026-42208, CVE-2026-42271, CVE-2026-48710, CVE-2026-59822), with CVE-2026-42271 added to CISA's KEV catalog.

campaign

Summary

LiteLLM, an open-source AI gateway proxy with roughly 95 million monthly PyPI downloads that centralizes credentials for 100+ LLM providers, was struck by a cascading series of critical 2026 vulnerabilities that collectively expose the enterprise API keys it is designed to manage. Because proxy-mode deployments concentrate every provider credential in one PostgreSQL-backed store, a single compromise yields the gateway's full credential inventory.[0][52]

The campaign includes a March 2026 supply chain compromise (CVE-2026-33634, CVSS 9.4) attributed to TeamPCP, who abused a poisoned Trivy scanner running in LiteLLM's CI/CD to steal PyPI publishing tokens and ship trojanized LiteLLM packages v1.82.7 and v1.82.8; a pre-authentication SQL injection (CVE-2026-42208, CVSS 9.3); and a command-injection flaw in LiteLLM's MCP test endpoints (CVE-2026-42271) that, chained with a Starlette host header bypass (CVE-2026-48710), achieves unauthenticated RCE assessed at CVSS 10.0. Palo Alto Unit 42 independently documents TeamPCP's multi-stage supply chain attack on security infrastructure.[0][51]

The scale of fallout is quantified: Hudson Rock independently obtained a 153GB archive of exfiltrated data comprising 433,909 files and attributed 118,829 CI runner dumps to 2,488 affected corporate domains, confirming credentials and configurations were harvested mid-execution from developer machines, production servers, and CI/CD pipelines worldwide.[39]

Multiple LiteLLM flaws are under active exploitation: CISA added CVE-2026-42271 to its Known Exploited Vulnerabilities catalog on June 8, 2026 with a federal remediation deadline of June 22, 2026; Sysdig observed in-the-wild SQL injection of CVE-2026-42208 within 36 hours of advisory indexing; and Wiz honeypots recorded sustained exploitation of the MCP command injection alongside a separate MCP Gateway authentication bypass (CVE-2026-59822). Organizations should upgrade to v1.83.10-stable, update Starlette, and treat credentials on affected hosts as potentially compromised.[0][52][56]

Attack chain

  1. Toolchain compromise: TeamPCP compromised the Trivy open-source vulnerability scanner on March 19, 2026 and hijacked the Checkmarx KICS GitHub Action on March 21, 2026 as part of a coordinated campaign against the developer toolchain and security infrastructure.[0][51]
  2. Credential theft: LiteLLM's CI/CD pipeline depended on Trivy; when the poisoned Trivy tooling ran in that pipeline it was granted legitimate read access to the runner environment and exfiltrated LiteLLM's PyPI publishing tokens to attacker infrastructure.[0][39]
  3. Malicious package publication: Using the stolen publishing credentials, TeamPCP published trojanized LiteLLM versions v1.82.7 and v1.82.8 to PyPI on March 24, 2026; the packages were downloaded tens of thousands of times before PyPI quarantined them within roughly three hours.[0][39]
  4. Stealthy payload execution: The malicious code used a .pth Python startup hook, executing the moment the interpreter initialized even without an explicit LiteLLM import. The multi-stage payload harvested environment variables and local configuration files such as .kube/config and .aws/credentials, along with AI provider API keys, AWS/GCP/Azure metadata credentials, SSH private keys, and CI/CD tokens.[0][39]
  5. Lateral movement and persistence: The payload attempted lateral movement into Kubernetes clusters by enumerating accessible service account tokens and installed a persistent systemd backdoor that polled for further payloads over an encrypted channel, ensuring persistence even if the malicious package was removed.[0][39]
  6. Direct exploitation of the credential store: Separately, attackers targeted LiteLLM's credential store through a pre-authentication SQL injection (CVE-2026-42208) that lets any client reaching the proxy port extract virtual keys, provider credentials, and config secrets from PostgreSQL without authenticating.[0]
  7. Unauthenticated RCE and MCP abuse: Attackers chained the MCP command-injection flaw CVE-2026-42271 with the Starlette host header bypass CVE-2026-48710 to bypass authentication entirely and achieve RCE on internet-exposed proxies; Wiz honeypots additionally observed exploitation of an MCP Gateway auth bypass (CVE-2026-59822) using single-character bearer tokens to enumerate models, enabling secret theft, direct database queries, backdoors, and pivoting to connected AI infrastructure.[0][52]

Disclosure timeline

DateEvent
2026-03-19TeamPCP compromised the Trivy open-source vulnerability scanner.[0]
2026-03-21TeamPCP hijacked the Checkmarx KICS GitHub Action.[0]
2026-03-24Malicious LiteLLM packages v1.82.7 and v1.82.8 published to PyPI (CVE-2026-33634); quarantined within roughly three hours after tens of thousands of downloads.[0][39]
2026-03-31Palo Alto Unit 42 published analysis of TeamPCP's multi-stage supply chain attack on security infrastructure.[51]
April 2026CVE-2026-42208 pre-authentication SQL injection disclosed; BerriAI patched it in v1.83.7-stable.[0]
2026-06-08CISA added CVE-2026-42271 to the Known Exploited Vulnerabilities catalog.[0][56]
2026-06-22Federal remediation deadline for CVE-2026-42271 under BOD 22-01.[0]
2026-08-12Hudson Rock disclosed it had independently obtained the raw 153GB exfiltrated dataset, attributing 118,829 CI runner dumps to 2,488 affected corporate domains.[39]

Actor profile

TeamPCP

Threat actor group conducting a coordinated cascading supply chain campaign against the developer-toolchain and security-infrastructure ecosystem in mid-to-late March 2026, compromising Trivy and Checkmarx KICS and leveraging LiteLLM's dependency on Trivy to steal PyPI publishing tokens and ship trojanized LiteLLM packages. Payloads focused on credential harvesting (AI provider keys, cloud credentials, SSH keys, CI/CD tokens) via a .pth Python startup hook, Kubernetes lateral movement, and systemd persistence, indicating a focus on the aggregated credential value concentrated in AI gateways. Attribution is independently documented by Palo Alto Unit 42, and Hudson Rock has recovered the raw exfiltrated corpus tying the operation to 2,488 corporate domains.[0][39][51]

How it works

CVE-2026-42208 (SQL injection): LiteLLM's authentication middleware passes the Authorization: Bearer token value directly into a SQL query without parameterization to look up the virtual key record. Because this lookup runs before the authorization decision, any client reaching the proxy port can inject arbitrary SQL and read high-value tables including LiteLLM_VerificationToken (virtual keys and master key), litellm_credentials (provider credentials), and litellm_config (environment variables and secrets).[0]

CVE-2026-42271 (command injection): The MCP preview endpoints POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list accept a full MCP server configuration object, including the command, args, and env fields used by the stdio transport, and pass them directly to a subprocess on the proxy host with no validation or sandboxing, running with the full privileges of the LiteLLM process.[0]

Chained exploitation: CVE-2026-42271 alone requires authentication (CVSS 8.7), but combining it with the Starlette host header validation bypass CVE-2026-48710 lets an attacker sidestep the authentication check entirely, yielding unauthenticated remote code execution assessed at CVSS 10.0 against any internet-exposed proxy.[0]

CVE-2026-59822 (MCP Gateway auth bypass): the OAuth2 header handling returns an empty, unrestricted UserAPIKeyAuth() object when token validation fails rather than rejecting the request, so any Bearer token—even a single character such as 'x'—grants full MCP access; Wiz observed probing of model enumeration endpoints using such tokens.[52]

Supply chain payload (CVE-2026-33634): the trojanized packages used a .pth Python startup hook that executes at interpreter initialization even without an explicit import, then ran a three-stage payload harvesting environment variables and local config files (.kube/config, .aws/credentials), attempting Kubernetes lateral movement, and installing a persistent systemd backdoor.[0][39]

Affected versions and patch status

ProductAffectedPatch status
LiteLLM (pre-auth SQL injection, CVE-2026-42208)Versions 1.81.16 through 1.83.6Fixed in v1.83.7-stable; full remediation of the vulnerability chain in v1.83.10-stable[0]
LiteLLM (MCP command injection / RCE chain, CVE-2026-42271 + CVE-2026-48710)Proxy versions exposing MCP test endpoints; unauthenticated when chained with the Starlette host header bypassFixed by upgrading to v1.83.10-stable and updating Starlette[0]
LiteLLM (MCP Gateway auth bypass, CVE-2026-59822)LiteLLM MCP Gateway OAuth2 header handlingAddressed by upgrading LiteLLM per vendor advisory; exploitation observed in the wild[52]
LiteLLM (supply chain compromise, CVE-2026-33634)Malicious PyPI packages v1.82.7 and v1.82.8Quarantined by PyPI; affected installs require credential rotation and host audit[0][39]

Indicators of Compromise

TypeIndicatorContext
otherlitellm 1.82.7Trojanized LiteLLM PyPI package published by TeamPCP on March 24, 2026 containing a multi-stage credential-harvesting and backdoor payload; presence indicates supply chain compromise.[0][39]
otherlitellm 1.82.8Second trojanized LiteLLM PyPI package published by TeamPCP on March 24, 2026 with the same malicious payload.[0][39]
cveCVE-2026-42271LiteLLM MCP command injection added to the CISA KEV catalog on June 8, 2026 as actively exploited and observed in Wiz honeypots.[0][52][56]
file-path/mcp-rest/test/MCP test endpoint path exploited by the command-injection RCE chain; anomalous requests warrant hunting and can be blocked as a compensating control.[0]
otherAuthorization: Bearer x (single-character bearer token) against GET /v1/modelsRequest pattern Wiz observed in honeypots exploiting the CVE-2026-59822 MCP Gateway auth bypass; single-character or otherwise invalid bearer tokens returning full access indicate exploitation attempts.[52]
file-path.pth Python startup hook in site-packagesThe supply chain payload used a .pth startup hook to execute at interpreter initialization; unexpected .pth entries on hosts that ran the trojanized versions are a compromise indicator.[39]

Key takeaways

  • A centralized AI gateway that aggregates credentials from dozens of providers is a concentrated high-value target whose compromise yields every provider key at once; its security posture should be treated as equivalent to the combined requirements of all accounts it manages.[0][52]
  • Security tooling with elevated CI/CD permissions is itself a high-value supply chain target: the poisoned Trivy scanner granted implicit downstream trust that let TeamPCP backdoor LiteLLM and harvest secrets from thousands of pipelines.[0][39]
  • The recovered 153GB dataset tying 118,829 CI runner dumps to 2,488 corporate domains demonstrates the real-world blast radius of a single trojanized package executed in CI/CD, underscoring the need to treat AI infrastructure as privileged and rotate potentially exposed credentials.[39]
  • Rapid, sustained exploitation—confirmed within 36 hours of advisory indexing, a CISA KEV listing, and ongoing honeypot activity—means AI gateway deployments must be explicitly included in threat models and patched with high priority.[0][52][56]

Defensive actions

  • Upgrade LiteLLM to v1.83.10-stable and update the underlying Starlette dependency.: This single upgrade closes CVE-2026-42208, CVE-2026-42271, and the CVE-2026-48710 host header bypass that enables the unauthenticated RCE chain.[0]
  • Block network access to the /mcp-rest/test/ endpoint path at an API gateway, reverse proxy, or perimeter firewall where an immediate upgrade is not possible.: Provides a partial compensating control for the RCE chain, though it does not address the SQL injection path.[0]
  • Rotate all credentials accessible to hosts that ran LiteLLM 1.82.7 or 1.82.8, including AI provider keys, cloud credentials, SSH private keys, and CI/CD tokens, and audit reachable Kubernetes service accounts.: The supply chain payload harvested these secrets and left minimal forensic trace; Hudson Rock's recovery of 118,829 CI runner dumps confirms mass exfiltration of live environment memory and configurations.[0][39]
  • Review PostgreSQL query logs for anomalous bearer token values in authentication queries on any proxy that ran versions 1.81.16 through 1.83.6 while reachable from an untrusted network.: This surfaces evidence of SQL injection exploitation of CVE-2026-42208.[0]
  • Never expose the LiteLLM proxy port directly to the internet; restrict it to authenticated internal clients and segment the host and its PostgreSQL instance from general corporate infrastructure.: Access-control hardening reduces exposure to the entire vulnerability class independent of any patch cycle and limits lateral movement from future compromises.[0][52]
  • Integrate dependency verification into pipelines, verify package hashes against known-good values, and treat security tooling running in CI/CD as potentially untrusted least-privilege input.: The supply chain attack succeeded because a poisoned security scanner running with elevated CI/CD permissions was granted legitimate read access to the runner and exfiltrated publishing tokens.[0][39]