CVE-2026-47102: LiteLLM privilege escalation to

Q: Is CVE-2026-47102 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-47102, increasing the risk of exploitation.

Q: How to fix CVE-2026-47102?

1. Patch immediately to LiteLLM v1.83.10-stable (commit 128d32d or e6f18ce). 2. If patching is delayed, block external access to /user/update at the reverse proxy or WAF layer until the patch is applied. 3. Audit the database for unauthorized proxy_admin role assignments: SELECT * FROM litellm_usertable WHERE user_role = 'proxy_admin' and cross-reference against expected admin accounts. 4. Rotate all LLM provider API keys managed through any potentially compromised LiteLLM instance. 5. Review audit logs for anomalous /user/update calls, particularly any request that succeeded and modified user_role. 6. Enable field-level mutation logging on the user table if operating a custom deployment. 7. Apply principle of least privilege — remove org_admin role from users who do not require it, as org_admins have legitimate endpoint access per the advisory.

Q: What systems are affected by CVE-2026-47102?

This vulnerability affects the following AI/ML architecture patterns: LLM gateway and proxy deployments, Multi-tenant AI platform infrastructure, Agent frameworks routing through LiteLLM, RAG pipelines with centralized LLM proxy, LLMOps and model serving stacks.

Q: What is the CVSS score for CVE-2026-47102?

CVE-2026-47102 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.65%.

CISO Take

Any authenticated LiteLLM user — including those with the lowest-privilege org_admin role — can promote themselves to full proxy_admin by sending a single API call to /user/update with a modified user_role field, because the endpoint enforces identity scoping but not field-level authorization. For organizations using LiteLLM as their central AI gateway, this is a complete perimeter collapse: proxy_admin exposes every LLM provider API key, full prompt history, all teams and users, and model routing configurations across the entire deployment. The CVSS 8.8 score reflects the real blast radius — network-reachable, low complexity, no user interaction required, meaning any disgruntled insider or compromised account can escalate in seconds. Patch to v1.83.10 immediately; if patching is not immediately possible, restrict /user/update access at the network layer and audit all user_role assignments in your database for unexpected proxy_admin entries.

Sources: NVD GitHub Advisory ATLAS huntr.com

What is the risk?

HIGH. The exploit requires only a valid user account and a single authenticated HTTP request — no special tools, no AI/ML knowledge, no chaining of additional vulnerabilities. The authorization control failure (CWE-863) is a classic mass-assignment pattern applied to a privileged field. LiteLLM's role as an LLM proxy aggregator amplifies impact: compromise of proxy_admin is effectively compromise of every downstream LLM API credential managed through the instance. Multi-tenant deployments serving multiple teams or customers face the highest risk, as a single malicious user can pivot to access all organizational LLM configurations and sensitive prompt data.

How does the attack unfold?

Initial Access

Attacker obtains a valid LiteLLM user account — via self-registration, phishing, or credential compromise — requiring only low-privilege authenticated access.

AML.T0012

Privilege Escalation

Attacker sends a single POST to /user/update with their own user_id and user_role set to 'proxy_admin'; the endpoint accepts the field with no authorization check.

AML.T0049

Credential Harvesting

With proxy_admin access, attacker enumerates and exfiltrates all LLM provider API keys, virtual keys, and team configurations managed by the LiteLLM instance.

AML.T0106

Impact

Attacker achieves full control over the AI inference layer: rerouting model traffic, exfiltrating prompt history, creating persistent admin keys, and potentially compromising every downstream AI workload.

AML.T0085

Initial Access

Attacker obtains a valid LiteLLM user account — via self-registration, phishing, or credential compromise — requiring only low-privilege authenticated access.

AML.T0012

Privilege Escalation

Attacker sends a single POST to /user/update with their own user_id and user_role set to 'proxy_admin'; the endpoint accepts the field with no authorization check.

AML.T0049

Credential Harvesting

With proxy_admin access, attacker enumerates and exfiltrates all LLM provider API keys, virtual keys, and team configurations managed by the LiteLLM instance.

AML.T0106

Impact

Attacker achieves full control over the AI inference layer: rerouting model traffic, exfiltrating prompt history, creating persistent admin keys, and potentially compromising every downstream AI workload.

AML.T0085

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LiteLLM	pip	< 1.83.10	`1.83.10`
52.6K OpenSSF 6.0 6 dependents Pushed 5d ago 43% patched ~49d to patch Full package profile →

Do you use LiteLLM? You're affected.

How severe is it?

CVSS 3.1

8.8 / 10

EPSS

0.7%

chance of exploitation in 30 days

Higher than 47% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C High

I High

A High

What should I do?

7 steps

Patch immediately to LiteLLM v1.83.10-stable (commit 128d32d or e6f18ce).
If patching is delayed, block external access to /user/update at the reverse proxy or WAF layer until the patch is applied.
Audit the database for unauthorized proxy_admin role assignments: SELECT * FROM litellm_usertable WHERE user_role = 'proxy_admin' and cross-reference against expected admin accounts.
Rotate all LLM provider API keys managed through any potentially compromised LiteLLM instance.
Review audit logs for anomalous /user/update calls, particularly any request that succeeded and modified user_role.
Enable field-level mutation logging on the user table if operating a custom deployment.
Apply principle of least privilege — remove org_admin role from users who do not require it, as org_admins have legitimate endpoint access per the advisory.

What does CISA's SSVC say?

Decision Attend

Exploitation poc

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Data Extraction Inference API AML.T0012 - Valid Accounts AML.T0040 - AI Model Inference API Access AML.T0049 - Exploit Public-Facing Application AML.T0085 - Data from AI Services AML.T0106 - Exploitation for Credential Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity Article 9 - Risk management system

ISO 42001

6.1.2 - AI risk assessment A.8.2 - Access control to AI system resources

NIST AI RMF

GOVERN 1.7 - Processes for AI risk management MANAGE 2.4 - Mechanisms to sustain AI risk management

OWASP LLM Top 10

LLM06:2025 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-47102?

Any authenticated LiteLLM user — including those with the lowest-privilege org_admin role — can promote themselves to full proxy_admin by sending a single API call to /user/update with a modified user_role field, because the endpoint enforces identity scoping but not field-level authorization. For organizations using LiteLLM as their central AI gateway, this is a complete perimeter collapse: proxy_admin exposes every LLM provider API key, full prompt history, all teams and users, and model routing configurations across the entire deployment. The CVSS 8.8 score reflects the real blast radius — network-reachable, low complexity, no user interaction required, meaning any disgruntled insider or compromised account can escalate in seconds. Patch to v1.83.10 immediately; if patching is not immediately possible, restrict /user/update access at the network layer and audit all user_role assignments in your database for unexpected proxy_admin entries.

Is CVE-2026-47102 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-47102, increasing the risk of exploitation.

How to fix CVE-2026-47102?

1. Patch immediately to LiteLLM v1.83.10-stable (commit 128d32d or e6f18ce). 2. If patching is delayed, block external access to /user/update at the reverse proxy or WAF layer until the patch is applied. 3. Audit the database for unauthorized proxy_admin role assignments: SELECT * FROM litellm_usertable WHERE user_role = 'proxy_admin' and cross-reference against expected admin accounts. 4. Rotate all LLM provider API keys managed through any potentially compromised LiteLLM instance. 5. Review audit logs for anomalous /user/update calls, particularly any request that succeeded and modified user_role. 6. Enable field-level mutation logging on the user table if operating a custom deployment. 7. Apply principle of least privilege — remove org_admin role from users who do not require it, as org_admins have legitimate endpoint access per the advisory.

What systems are affected by CVE-2026-47102?

This vulnerability affects the following AI/ML architecture patterns: LLM gateway and proxy deployments, Multi-tenant AI platform infrastructure, Agent frameworks routing through LiteLLM, RAG pipelines with centralized LLM proxy, LLMOps and model serving stacks.

What is the CVSS score for CVE-2026-47102?

CVE-2026-47102 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.65%.

What is the AI security impact?

Affected AI Architectures

LLM gateway and proxy deploymentsMulti-tenant AI platform infrastructureAgent frameworks routing through LiteLLMRAG pipelines with centralized LLM proxyLLMOps and model serving stacks

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0040 AI Model Inference API Access

AML.T0049 Exploit Public-Facing Application

AML.T0085 Data from AI Services

AML.T0106 Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Article 15, Article 9

ISO 42001: 6.1.2, A.8.2

NIST AI RMF: GOVERN 1.7, MANAGE 2.4

OWASP LLM Top 10: LLM06:2025

What are the technical details?

Original Advisory

LiteLLM prior to 1.83.10 allows a user to modify their own user_role via the /user/update endpoint. While the endpoint correctly restricts users to updating only their own account, it does not restrict which fields may be changed. A user who can reach this endpoint can set their role to proxy_admin, gaining full administrative access to LiteLLM including all users, teams, keys, models, and prompt history. Users with the org_admin role have legitimate access to this endpoint and can exploit this vulnerability without chaining any additional flaw.

Exploitation Scenario

An attacker with a standard LiteLLM user account — obtained through normal registration, a phishing campaign, or by compromising a low-value credential — sends a POST to /user/update with their own user_id and the additional field user_role set to proxy_admin. The endpoint validates that the user_id matches the authenticated caller (preventing horizontal privilege abuse) but performs no field-level validation, so the role field is accepted and persisted. The attacker's session now carries proxy_admin privileges, granting access to the /admin endpoints, all virtual key management APIs, the full user roster, team configurations, model provider credentials, and prompt history. In a multi-tenant AI platform, the attacker can then create new admin API keys to maintain persistent access, enumerate all stored LLM provider credentials, and silently redirect or log all inference traffic through a controlled model endpoint.

Weaknesses (CWE)

CWE-863 Incorrect Authorization Primary CWE-863 Incorrect Authorization Primary CWE-863 Incorrect Authorization

CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.