Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain valid LiteLLM proxy credential
-
DeliveryCraft request with attacker-controlled api_base or bracket-notation equivalent
-
ExploitBypass incomplete banned-parameter validation
-
ExecutionProxy forwards request with operator provider API key
-
PersistAttacker server captures upstream LLM credential
-
ImpactAbuse stolen key for unbounded API spend or further lateral movement
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V4 - API and Web Service URL allowlisting, SSRF prevention
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Credential Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires a valid LiteLLM proxy account at any privilege level (PR:L - standard user, not administrator). The attacker must supply one of the vulnerable routing or credential parameters (api_base, base_url, model_list, fallbacks, litellm_credential_name) in the request body, including via bracket-notation form data or the model field in chat or image endpoints, all of which bypassed the pre-patch validation. No special server-side configuration is required beyond default LiteLLM proxy deployment - the flaw exists in the core request processing pipeline active in all standard deployments. Unauthenticated exploitation is not possible. Impact is bounded to credentials stored in the proxy and internal network services reachable from the proxy host. |
| Impact | The CVSS 6.5 score (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) correctly reflects network-accessible exploitation requiring only standard authenticated access, with high confidentiality impact from provider credential theft. The unchanged scope (S:U) is conservative given documented SSRF pivot capability to internal services reachable by the proxy host, but the primary confirmed impact is credential exfiltration. No EPSS data was provided; the vulnerability is not listed in CISA KEV; no public PoC has been identified beyond fix-confirming upstream commits. The practical risk is elevated in multi-tenant LiteLLM deployments where untrusted authenticated users exist - stolen upstream LLM provider API keys can be exploited for financial abuse (unbounded API spend) and data exfiltration independent of the proxy. Single-tenant, fully-trusted-user deployments face materially lower risk. The CVSS score may understate the business impact in SaaS or shared-proxy configurations. |
| Exploit ScenarioDerived | An attacker with a standard LiteLLM proxy account crafts a chat completion or image generation request that includes api_base (or its bracket-notation equivalent metadata[api_base]) pointing to an attacker-controlled HTTPS server. The proxy, failing to strip the operator's stored upstream provider credential before forwarding, sends the full request - including the Authorization header containing the OpenAI or Anthropic API key - to the attacker's server. The attacker captures the credential and begins making direct API calls billed to the victim operator, or leverages the SSRF vector to probe internal services reachable from the proxy host. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 02, 2026
Credential exfiltration via SSRF in LiteLLM proxy (AI Gateway) prior to versions 1.88.6 and 1.96.2 allows any authenticated proxy user to redirect outbound LLM provider calls to an attacker-controlled endpoint, causing the proxy to transmit its operator-configured API keys and other secrets to that destination. Vulnerable routing parameters - api_base, base_url, model_list, fallbacks, and litellm_credential_name - could be injected through nested request fields, path values, and bracket-notation form data that incomplete validation across five proxy modules failed to intercept. No public exploit code has been identified at time of analysis; vendor-released patches are confirmed at versions 1.88.6 and 1.96.2.
RemediationAI
Upgrade LiteLLM to version 1.88.6 or 1.96.2; both fix versions are confirmed by GitHub release tags at https://github.com/BerriAI/litellm/releases/tag/v1.88.6 and https://github.com/BerriAI/litellm/releases/tag/v1.96.2, and the fix is distributed across three merged PRs (#36011, #36314, #36494). If immediate upgrade is not feasible, restrict LiteLLM proxy access to fully trusted authenticated users only, as any valid proxy credential is sufficient to exploit this; consider blocking or auditing inbound requests containing api_base, base_url, model_list, fallbacks, or litellm_credential_name parameters at an upstream WAF or API gateway layer. Do not enable the general_settings.allow_client_side_credentials proxy option in multi-tenant or untrusted-user environments, as the patch intentionally preserves that opt-in path for administrators who need it.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
LiteLLM is an open-source AI gateway (CPE: cpe:2.3:a:berriai:litellm) that proxies requests to upstream LLM provider APIs (OpenAI, Anthropic, etc.) while storing operator-level provider credentials server-side. CWE-918 (Server-Side Request Forgery) applies because incomplete input validation across auth_utils.py, common_request_processing.py, health_endpoints/_health_endpoints.py, image_endpoints/endpoints.py, and litellm_pre_call_utils.py allowed user-controlled routing parameters to override the operator-configured provider endpoint without clearing the stored credentials. The bypass was specifically achievable through bracket-notation form data (e.g., metadata[api_base]) and nested fields that the banned-parameter checks did not inspect, and through the model parameter in the main call and image generation paths which lacked url-destination rejection entirely.
Know when Litellm gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Network-accessible SSRF requiring only standard user authentication; high confidentiality impact from provider credential theft; scope unchanged as primary impact targets proxy's own stored secrets.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
1DescriptionCVE.org
LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to versions 1.88.6 and 1.96.2, any authenticated LiteLLM proxy user could redirect an outbound provider call to a destination the user controls and cause the proxy to send its configured provider credentials to that destination. Request validation in litellm/proxy/auth/auth_utils.py, litellm/proxy/common_request_processing.py, litellm/proxy/health_endpoints/_health_endpoints.py, litellm/proxy/image_endpoints/endpoints.py, and litellm/proxy/litellm_pre_call_utils.py used incomplete checks that did not cover every sensitive parameter or inspect equivalent values across nested request fields, path values, and bracket-notation form data. Routing and credential parameters including api_base, base_url, model_list, fallbacks, and litellm_credential_name could therefore be applied without clearing the operator's stored key, exposing upstream provider credentials and other configured secrets and permitting server-side requests to internal services reachable by the proxy. This issue is fixed in versions 1.88.6 and 1.96.2.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Server-Side Request Forgery exploits applications that fetch remote resources based on user-supplied URLs.
Remote command execution in LiteLLM proxy server versions 1.74.2 through 1.83.6 allows any authenticated user to execute
SQL injection in LiteLLM proxy server versions 1.81.16 through 1.83.6 allows unauthenticated remote attackers to read an
Authentication bypass in LiteLLM (BerriAI) proxy/AI Gateway before 1.84.0 lets a remote unauthenticated attacker reach M
BerriAI/litellm is vulnerable to Server-Side Template Injection (SSTI) via the `/completions` endpoint. Rated critical s
Remote code execution in BerriAI LiteLLM (all versions through 2026-04-08) enables authenticated attackers to execute ar
BerriAI's litellm, in its latest version, is vulnerable to arbitrary file deletion due to improper input validation on t
Authentication bypass in the LiteLLM proxy lets any party who already holds a valid JWT issued by the configured externa
In berriai/litellm version v1.52.1, an issue in proxy_server.py causes the leakage of Langfuse API keys when an error oc
In berriai/litellm before version 1.44.12, the `litellm/litellm_core_utils/litellm_logging.py` file contains a vulnerabi
A Server-Side Request Forgery (SSRF) vulnerability exists in berriai/litellm version 1.38.10. Rated high severity (CVSS
An SQL Injection vulnerability exists in the berriai/litellm repository, specifically within the `/global/spend/logs` en
A code injection vulnerability exists in the berriai/litellm application, version 1.34.6, due to the use of unvalidated
EUVD-2026-70236
GHSA-3cv6-jpf6-8222
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB