GHSA-69x8-hrgq-fjj8: LiteLLM: auth bypass chain enables full privilege escalation

Published April 8, 2026

CISO Take

LiteLLM contains a three-step authentication bypass chain requiring only a valid low-privilege account: unsalted SHA-256 password hashes are exposed directly in API responses from /user/info, /user/update, and /spend/users, and the /v2/login endpoint accepts those raw hashes as valid credentials — allowing any authenticated user to hijack any account, including admin, in three HTTP requests. With 2,002 downstream dependents, a package risk score of 79/100, and 12 prior CVEs in the same package, LiteLLM is a high-value target in enterprise AI stacks where it proxies credentials for OpenAI, Anthropic, Azure OpenAI, and other LLM providers. Exploitation requires no specialized skill beyond basic API knowledge and valid credentials at any privilege level. Upgrade to v1.83.0 immediately, then rotate all LiteLLM admin passwords and any LLM provider API keys configured in the instance.

Sources: GitHub Advisory OpenSSF ATLAS

Risk Assessment

High. The attack requires only authenticated access at any privilege level — a common starting point for insider threats, compromised developer accounts, or attackers who phished a low-privilege user. The exploitation chain is trivially mechanical: three sequential HTTP requests with no AI/ML expertise required. The blast radius is severe for organizations using LiteLLM as their LLM gateway, since admin access exposes all configured provider API keys, spending controls, and model routing. No public exploit confirmed and not in CISA KEV, but the technique is simple enough to rediscover independently. OpenSSF score of 5.9/10 and 12 prior CVEs suggest a pattern of insufficient security investment in this package.

Affected Systems

Package	Ecosystem	Vulnerable Range	Patched
litellm	pip	< 1.83.0	`1.83.0`
42.2K OpenSSF 5.9 2.0K dependents Pushed 3d ago 54% patched ~61d to patch Full package profile →

Do you use litellm? You're affected.

Severity & Risk

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

Recommended Action

Upgrade LiteLLM to v1.83.0 immediately — scrypt migration is transparent on next login.
Force-reset all user passwords post-upgrade to invalidate any previously exposed SHA-256 hashes.
Rotate all LLM provider API keys (OpenAI, Anthropic, Azure, etc.) configured in LiteLLM as a precaution.
Review access logs for calls to /user/info, /user/update, and /spend/users from non-admin accounts prior to patching — these are the hash exfiltration vectors.
If immediate upgrade is blocked, restrict those three endpoints at the reverse proxy or WAF level to admin-source IPs only.
Enable alerting on cross-user authentication patterns (user A authenticating after querying user B's profile).

Classification

Auth Bypass Data Extraction Privacy Violation API Inference Framework AML.T0012 - Valid Accounts AML.T0040 - AI Model Inference API Access AML.T0049 - Exploit Public-Facing Application AML.T0055 - Unsecured Credentials AML.T0091 - Use Alternate Authentication Material

Compliance Impact

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6 - Access control for AI systems

NIST AI RMF

MANAGE 2.2 - Mechanisms are in place and applied to sustain risk-mitigating actions

OWASP LLM Top 10

LLM06 - Sensitive Information Disclosure

Technical Details

NVD Description

### Impact Three issues combine into a full authentication bypass chain: 1. Weak hashing: User passwords are stored as unsalted SHA-256 hashes, making them vulnerable to rainbow table attacks and trivially identifying users with identical passwords. 2. Hash exposure: Multiple API endpoints (/user/info, /user/update, /spend/users) return the password hash field in responses to any authenticated user regardless of role. Plaintext passwords could also potentially be exposed in certain scenarios. 4. Pass-the-hash: The /v2/login endpoint accepts the raw SHA-256 hash as a valid password without re-hashing, allowing direct login with a stolen An already authenticated user can retrieve another user's password hash from the API and use it to log in as that user. This enables full privilege escalation in three HTTP requests. ### Patches Fixed in v1.83.0. Passwords are now hashed with scrypt (random 16-byte salt, n=16384, r=8, p=1). Password hashes are stripped from all API responses. Existing SHA-256 hashes are transparently migrated on next login.

Exploitation Scenario

An attacker with any valid LiteLLM account — e.g., a developer added to the instance — calls GET /spend/users or GET /user/info, which return the SHA-256 password hash for all users including admins in the JSON response. The attacker extracts the admin hash and POSTs it directly to /v2/login as the password field, receiving a valid admin session token. With admin access they dump all configured LLM provider API keys, redirect model routing to log all inference traffic to an external server, or create backdoor admin accounts. Total time from low-priv access to full compromise: under 60 seconds with a basic HTTP client.