LiteLLM Hit by PyPI Supply-Chain Compromise and Guardrail Sandbox Escape
Datadog Security Labs reported that the TeamPCP supply-chain campaign compromised the legitimate PyPI package LiteLLM, publishing malicious versions 1.82.7 and 1.82.8 that stole credentials, exfiltrated data, established persistence, and in some cases attempted to spread into Kubernetes environments. The campaign also hit Telnyx on PyPI and was linked to earlier compromises involving Trivy, npm packages, Aqua Security repositories, and Checkmarx tooling, with researchers concluding that stolen CI/CD and publishing credentials were reused across ecosystems. Datadog warned that LiteLLM 1.82.8 was especially dangerous because a malicious .pth file triggered payload execution when the Python interpreter started, while the Telnyx package executed code at import time and retrieved a second-stage payload hidden in a WAV file.
Separately, X41 disclosed a high-severity sandbox escape in BerriAI LiteLLM affecting the main-latest Docker image, where authenticated users could reach arbitrary code execution through the /guardrails/test_custom_code API endpoint. The flaw relied on bypassing regex-based restrictions on custom Python guardrail code using string concatenation and CPython bytecode rewriting to recover unrestricted builtins and call __import__, allowing commands to run as the LiteLLM process user, which is root in the default Docker deployment. X41 assigned the issue CWE-94 and a CVSS 4.0 score of 8.7, and Datadog advised organizations that installed the malicious LiteLLM releases to treat affected hosts and CI jobs as full credential-exposure events, rotate secrets, hunt for persistence and outbound traffic, and rebuild critical systems from known-good images rather than relying only on package rollback.
Timeline
Apr 15, 2026
Gurucul identifies Mercor as downstream victim of LiteLLM compromise
Gurucul reported that the malicious LiteLLM supply-chain compromise impacted downstream users, including Mercor, where the compromised dependency enabled unauthorized data access and possible command execution. The report framed Mercor as a case study of the breach's downstream effects.
Mar 27, 2026
Malicious Telnyx releases 4.87.1 and 4.87.2 published to PyPI
Attackers also compromised the legitimate Telnyx Python package on PyPI, publishing malicious versions 4.87.1 and 4.87.2. The package executed malicious code at import time and retrieved a second-stage payload concealed in a WAV file.
Mar 24, 2026
Datadog links LiteLLM and Telnyx compromises to TeamPCP campaign
Datadog Security Research reported that the PyPI compromises of LiteLLM and Telnyx were part of the broader TeamPCP supply-chain campaign, which had previously affected Trivy, npm packages, Aqua Security repositories, and Checkmarx tooling. The report said stolen CI/CD and publishing credentials were reused across ecosystems to expand the campaign.
Mar 24, 2026
Malicious LiteLLM releases 1.82.7 and 1.82.8 published to PyPI
As part of the TeamPCP supply-chain campaign, attackers compromised the legitimate LiteLLM package on PyPI and published malicious versions 1.82.7 and 1.82.8. Datadog assessed version 1.82.8 as especially dangerous because a malicious .pth file triggered payload execution at Python interpreter startup.
Feb 13, 2026
X41 publicly discloses unpatched LiteLLM RCE vulnerability
X41 D-Sec published advisory X41-2026-001 describing a LiteLLM sandbox escape that could lead to arbitrary code execution as the LiteLLM process user, which is root by default in the affected Docker image. At publication, no patch was available.
Feb 3, 2026
X41 reports LiteLLM guardrail sandbox escape to vendor
According to the advisory's disclosure timeline, X41 D-Sec privately reported a high-severity sandbox escape in LiteLLM's /guardrails/test_custom_code endpoint in February 2026. The flaw allowed authenticated users to bypass source filtering and achieve arbitrary code execution in the default Docker deployment.
See the full picture in Mallory
Mallory subscribers get deeper analysis on every story, including:
Who’s affected and how
Deep-dive technical analysis
Actionable next steps for your team
IPs, domains, hashes, and more
Ask questions and take action on every story
Filter by topic, classification, timeframe
Get matching stories delivered automatically
Related Entities
Threat Actors
Organizations
Affected Products
Sources
Related Stories
Backdoored LiteLLM PyPI Releases Stole Secrets and Planted Kubernetes-Aware Malware
Attackers published malicious `litellm` versions `1.82.7` and `1.82.8` to PyPI after compromising the project’s release pipeline, turning a widely used AI gateway library into a credential-stealing malware delivery vehicle. Multiple reports link the intrusion to the broader **TeamPCP** supply-chain campaign and assess that stolen credentials from the earlier Trivy compromise were likely used to obtain LiteLLM publishing access. The tainted releases were available for roughly two to three hours before PyPI quarantined or yanked them, but researchers warned the exposure could be widespread because LiteLLM is heavily deployed across cloud and AI environments and was observed in about **36% of cloud environments** in Wiz telemetry. The malware harvested environment variables, cloud credentials, SSH keys, `.env` files, CI/CD secrets, Kubernetes tokens, database settings, Docker and Git credentials, AI provider API keys, and cryptocurrency wallet data, then encrypted and exfiltrated the data to `models.litellm[.]cloud`. It also established persistence through a disguised `systemd` service such as `sysmon.service` and polled `checkmarx[.]zone` for follow-on payloads; in Kubernetes environments, it attempted lateral movement by creating privileged pods and seeking node-level persistence. Version `1.82.8` posed the highest risk because a malicious Python `.pth` file executed automatically whenever the Python interpreter started, even if LiteLLM was never imported. Defenders were urged to treat any installation of either version as a full compromise, isolate affected hosts and CI jobs, remove persistence, inspect clusters and build artifacts, block attacker infrastructure, and rotate all reachable credentials immediately.
Today
Critical LiteLLM SQL Injection Exploited to Target Stored API Keys and Credentials
Attackers began exploiting **CVE-2026-42208** in LiteLLM shortly after public disclosure, using a pre-authentication SQL injection flaw in the product’s `Authorization: Bearer` verification path to query the backend PostgreSQL database without logging in. The vulnerability, also tracked as `GHSA-r75f-5x8p-qvmc`, affects LiteLLM versions **1.81.16 through 1.83.6** and was fixed in **v1.83.7** after the project replaced vulnerable string interpolation with a parameterized query. Sysdig said the first observed exploitation attempt arrived **36 hours and seven minutes** after the advisory was indexed, with activity focused on enumerating high-value tables holding virtual API keys, provider credentials, verification tokens, and environment-based configuration. Researchers described the intrusion attempts as targeted rather than opportunistic, citing knowledge of Prisma-generated PostgreSQL table names and `UNION`-based column discovery; while no confirmed follow-on abuse was observed, defenders are being urged to patch exposed instances immediately, rotate all stored secrets, and review logs and billing accounts for signs of compromise.
3 days ago
LiteLLM Flaws Enable Privilege Escalation and OIDC Authentication Bypass
LiteLLM fixed two high-severity vulnerabilities in version `1.83.0` that could allow attackers to gain elevated access in AI gateway deployments. **CVE-2026-35029** stems from missing admin authorization on the `/config/update` endpoint, allowing an authenticated low-privilege user to change proxy settings and environment variables. The flaw could be abused to register attacker-controlled Python handlers for remote code execution, read arbitrary server files, and overwrite UI credentials to seize privileged accounts, creating broad confidentiality, integrity, and availability risk. The same release also addressed **CVE-2026-35030**, an authentication bypass affecting LiteLLM deployments that enabled JWT-based authentication. In vulnerable versions, the platform used the first 20 characters of a token as the OIDC userinfo cache key, allowing a crafted token with a matching prefix to collide with a legitimate cached session and inherit that user’s identity and permissions. The issue is not enabled by default, limiting exposure to specific configurations, but together the flaws highlight significant access-control weaknesses in LiteLLM versions prior to `1.83.0`.
3 days ago