Which versions of LiteLLM are affected by CVE-2026-47101?

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.. A patch is available.

How to fix or mitigate CVE-2026-47101?

Within 24 hours: Identify and inventory all LiteLLM proxy deployments and running versions; determine network exposure and authentication requirements. Within 7 days: Upgrade all instances to LiteLLM v1.83.14-stable or later; verify successful deployment across all environments. Within 30 days: Audit API key creation logs and admin endpoint access from the past 90 days for unauthorized activity; review and enforce least-privilege role assignments.

LiteLLM CVE-2026-47101

Q: What is the CVSS score of CVE-2026-47101?

CVE-2026-47101 has a CVSS 4.0 base score of 8.7 (High). CVSS vector: 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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.1%.

EUVD-2026-31346 HIGH

Incorrect Authorization (CWE-863)

2026-05-21 disclosure@vulncheck.com

GHSA-qrc4-49gv-mv9m

Authentication Bypass Privilege Escalation Litellm

8.7

CVSS 4.0 · Vendor: vulncheck

Severity by source

Vendor (vulncheck) PRIMARY

8.7 HIGH

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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Red Hat

8.8 HIGH

qualitative

Primary rating from Vendor (vulncheck).

CVSS VectorVendor: vulncheck

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Patch available

May 21, 2026 - 22:02 EUVD

Source Code Evidence Fetched

May 21, 2026 - 21:30 vuln.today

Analysis Generated

May 21, 2026 - 21:30 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

15 pypi packages depend on litellm (15 direct, 0 indirect)

Ecosystem-wide dependent count for version 1.83.14.

DescriptionCVE.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.

AnalysisAI

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.

Technical ContextAI

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.

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.