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.
Timeline
Apr 28, 2026
Further reporting confirms active exploitation and urges secret rotation
Subsequent reporting highlighted that the vulnerability was being actively exploited in the wild, linked the observed activity to two IP addresses in the same autonomous system, and reiterated guidance to patch, rotate exposed secrets, and review logs and billing accounts. This reinforced the incident as an active credential-theft risk for vulnerable LiteLLM deployments.
Apr 25, 2026
First in-the-wild exploitation attempt targets LiteLLM credential tables
Sysdig observed the first exploitation attempt 36 hours and seven minutes after the advisory was indexed, indicating attackers moved quickly to abuse the flaw. The activity focused on enumerating high-value PostgreSQL tables containing virtual API keys, provider credentials, verification tokens, and environment-variable configuration.
Apr 24, 2026
LiteLLM releases v1.83.7 to fix SQL injection flaw
LiteLLM fixed CVE-2026-42208 in version 1.83.7 by replacing string interpolation with a parameterized query in the authentication path. The patch addressed exposure of PostgreSQL-stored secrets such as API keys, provider credentials, and configuration data.
Apr 24, 2026
GitHub Advisory Database indexes CVE-2026-42208
The critical pre-authentication SQL injection flaw in LiteLLM, tracked as CVE-2026-42208 / GHSA-r75f-5x8p-qvmc, was indexed in the GitHub Advisory Database. The vulnerability affects LiteLLM versions 1.81.16 through 1.83.6 and allows arbitrary SELECT queries via the Authorization Bearer header.
Apr 20, 2026
Sysdig publishes research on targeted exploitation of CVE-2026-42208
Sysdig publicly reported that attackers were deliberately exploiting the LiteLLM SQL injection vulnerability and described the observed tradecraft, including UNION-based column discovery and knowledge of Prisma-generated PostgreSQL table names. The company said it had not confirmed follow-on abuse such as authenticated use of stolen keys, but warned exposed internet-facing instances should be treated as potentially compromised.
Apr 20, 2026
LiteLLM publishes vendor advisory for CVE-2026-42208
BerriAI published a GitHub security advisory for CVE-2026-42208 affecting LiteLLM versions 1.81.16 through 1.83.6, describing unauthenticated SQL injection via the proxy API key verification path. The advisory credited Tencent YunDing Security Lab, noted the fix in version 1.83.7, and provided a workaround to set `disable_error_logs: true` for users unable to upgrade immediately.
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
Malware
Organizations
Affected Products
Sources
4 more from sources like bleeping computer, sysdig blog and github advisories github link
Related Stories
LMDeploy SSRF Was Exploited Within Hours as LiteLLM Proxy Disclosed RCE Chain
Attackers began exploiting **CVE-2026-33626** in LMDeploy less than 13 hours after public disclosure, using a server-side request forgery flaw in vision-language request handling to make inference servers fetch attacker-controlled and internal URLs. Sysdig said the bug affects LMDeploy `0.12.0` and earlier with vision-language support, where `image_url` input is not properly restricted, and observed an eight-minute attack against its honeypot that probed AWS instance metadata, localhost services, an unauthenticated administrative endpoint, and an out-of-band callback domain. The activity included scans of loopback ports associated with **Redis**, **MySQL**, and HTTP services, underscoring the risk of exposing AI inference infrastructure to internal network discovery and cloud credential theft. The disclosures also highlighted broader weaknesses in LLM-serving platforms. LiteLLM published three advisories for LiteLLM Proxy that researchers said can be chained to achieve **remote code execution**, including an unauthenticated SQL injection (`GHSA-r75f-5x8p-qvmc`), a server-side template injection flaw, and an authenticated command-execution issue in MCP stdio test endpoints. The affected LiteLLM range is `1.81.16` through `1.83.6`, with fixes available in `1.83.7-stable` and later, while LMDeploy users were urged to upgrade to `v0.12.3+`, enforce **IMDSv2**, restrict egress, rotate IAM credentials, and monitor inference hosts for requests to metadata, loopback, and private-network addresses.
1 weeks 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
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.
1 weeks ago