EUVD-2026-31346
GHSA-qrc4-49gv-mv9m
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as internal_user
-
DeliveryCall /key/generate with admin allowed_routes
-
ExploitServer stores key without permission check
-
ExecutionUse new key against admin endpoints
-
PersistCreate persistent proxy_admin key
-
ImpactFull proxy takeover and tenant data access
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Attacker must hold valid credentials for a LiteLLM account with the internal_user role (or any non-admin role permitted to call the key generation endpoint) and network reachability to the proxy's management API on the /key/generate, /key/update, or /key/regenerate paths. No user interaction, no MFA bypass, and no non-default configuration is required - the vulnerable allowed_routes handling is the default behavior in every LiteLLM version prior to 1.83.14. Exploitation is limited to deployments that actually provision non-admin accounts and expose the key management endpoints to those users; single-admin or single-tenant deployments where only proxy_admin can call key generation are not exposed, and deployments that front the management API with an external authorization layer that strips allowed_routes are also protected. |
| Impact | The CVSS 4.0 vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H scores 8.7 (High) and accurately reflects a low-complexity network-reachable attack that requires only low privileges (an existing internal_user account) and produces full confidentiality, integrity, and availability impact on the proxy. EPSS and CISA KEV data are not provided, so there is no quantitative exploitation probability and no evidence of in-the-wild exploitation at time of analysis; however, publicly available exploit code exists (the linked gist plus a Huntr bounty writeup and the VulnCheck advisory) and the root cause is trivially reproducible from the public diff, so weaponization risk is high for any deployment that hands out internal_user accounts. This should be treated as a real priority for any organization running LiteLLM as a multi-tenant proxy: the privilege boundary the product advertises (internal_user vs proxy_admin) is fully collapsible until patched. |
| Exploit ScenarioDerived | An attacker who already holds an internal_user account (for example a member of a tenant team given a low-privilege login on a shared LiteLLM gateway) calls POST /key/generate with allowed_routes set to an admin-only bucket such as management_routes. The proxy stores the key without validating those routes against the caller's role, and the attacker then uses the newly issued key to invoke admin endpoints, creating new admin keys, viewing or modifying every tenant's configuration, and effectively taking over the proxy. Publicly available exploit code exists in the linked gist and Huntr disclosure, lowering the skill bar to a single HTTP request. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – May 21, 2026
Privilege escalation in LiteLLM proxy versions prior to 1.83.14 allows an authenticated internal_user to elevate to proxy_admin by generating an API key with an attacker-controlled allowed_routes field that grants access to admin-only endpoints. Because the key-generation handler did not verify that the requested routes fell within the caller's own role permissions, the resulting key successfully reaches admin routes and bypasses role-based access control. Publicly available exploit code exists via a Huntr bounty disclosure and gist, and the upstream commits are merged in the v1.83.14-stable release.
RemediationAI
Vendor-released patch: upgrade LiteLLM to 1.83.14-stable or later (https://github.com/BerriAI/litellm/releases/tag/v1.83.14-stable), which adds caller-permission checks for allowed_routes and allowed_passthrough_routes in generate_key_fn, the update path, and regenerate_key_fn (commits 2220f3076ac89bd2a2e3439acf57dcfbec2434c9, 5190bd07eb23a037745d86328096f54378f1614a, d910a95661fce3cdd36f3b06c03ecf9c46c6457c). Until the upgrade can be rolled out, restrict the /key/generate, /key/update, and /key/regenerate management endpoints so they are reachable only by proxy_admin accounts (for example via an upstream reverse proxy ACL or network policy), revoke or rotate any keys created by internal_user accounts since deployment, and audit existing keys for unexpected allowed_routes or metadata.allowed_passthrough_routes values; the trade-off is that legitimate internal_user self-service key issuance will be blocked until the patch is applied. Avoid disabling key management entirely if downstream integrations rely on it - prefer the proxy-level allow-list above.
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 LLM proxy/gateway (BerriAI/litellm) that brokers requests to multiple model providers and ships a management API for keys, users, and routes. The flaw is a CWE-863 Incorrect Authorization in litellm/proxy/management_endpoints/key_management_endpoints.py: the generate-key and regenerate-key flows accepted an allowed_routes parameter on the request body without checking that those routes were a subset of the caller's role. Because RouteChecks.non_proxy_admin_allowed_routes_check treats an explicit allowed_routes value as an override of the standard role gate, an internal_user could embed admin-only route buckets (e.g. management_routes) and the proxy would later honor them. The patch introduces _check_allowed_routes_caller_permission and _check_passthrough_routes_caller_permission, restricts the override to a safe preset list (llm_api_routes, info_routes), and re-checks after handle_key_type so derived buckets cannot smuggle elevated access.
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
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
Lifecycle Timeline
1DescriptionCVE.org
LiteLLM prior to 1.83.14 allows an authenticated internal_user to create API keys with access to routes that their role does not permit. When generating a key, the allowed_routes field is stored without verifying that the specified routes fall within the user's own permissions. A key created with access to admin-only routes can then be used to reach those routes successfully, bypassing the role-based access controls that would otherwise block the request, enabling full privilege escalation from internal_user to proxy_admin.
Blast Radius
ecosystem impact- 16 pypi packages depend on litellm (15 direct, 1 indirect)
Ecosystem-wide dependent count for version 1.83.14.
Executive ViewAI
LiteLLM proxy versions before 1.83.14 contain a privilege escalation flaw allowing authenticated internal users to bypass role-based access controls and assume admin privileges via crafted API keys. Publicly available exploit code exists, creating immediate risk of unauthorized administrative access. Organizations using affected versions must upgrade to prevent credential theft and unauthorized system configuration.
Vendor-released patch: LiteLLM v1.83.14-stable. If upgrade cannot be completed immediately, restrict network access to the proxy to authorized internal systems only and implement enhanced logging and alerting on all API key generation and admin endpoint access attempts.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
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
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.
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
Exploit-DB