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.
Timeline
Apr 23, 2026
LiteLLM releases fixed version 1.83.7-stable
Users were advised to upgrade LiteLLM Proxy to version 1.83.7-stable or later to address the newly disclosed vulnerabilities. The disclosure noted that official container images run the proxy as root, which can increase impact on vulnerable hosts.
Apr 23, 2026
LiteLLM discloses three proxy flaws enabling RCE chains
LiteLLM disclosed three GitHub Security Advisories covering an unauthenticated SQL injection, a server-side template injection, and an authenticated command-execution flaw in LiteLLM Proxy. The vulnerabilities affect versions 1.81.16 through 1.83.6 and can be chained to achieve remote code execution.
Apr 22, 2026
LMDeploy users advised to upgrade to version 0.12.3 or later
Following disclosure and observed exploitation, defenders were advised to remediate by upgrading LMDeploy to v0.12.3 or newer and to harden deployments with measures such as IMDSv2 enforcement, egress restrictions, credential rotation, and monitoring for suspicious internal URL access.
Apr 22, 2026
Attackers exploit LMDeploy flaw against Sysdig honeypot within hours
On April 22, 2026, Sysdig observed an attacker exploit the LMDeploy SSRF vulnerability against its honeypot about 12.5 hours after the advisory became public. The attacker probed AWS metadata, localhost services, an unauthenticated administrative endpoint, and an out-of-band callback domain during an eight-minute session.
Apr 21, 2026
GitHub publishes LMDeploy SSRF advisory GHSA-6w67-hwm5-92mq
GitHub published a security advisory on an SSRF flaw in LMDeploy affecting vision-language request handling, later tracked as CVE-2026-33626. The issue allows user-supplied image_url values to trigger requests to arbitrary internal or external URLs.
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
Organizations
Affected Products
Sources
Related Stories
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
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