Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
8.6
LiteLLM Password Exposure Allows Unauthorized Login
GHSA-69x8-hrgq-fjj8
Summary
A security patch fixed a way for an authenticated user to steal another user's password and log in as them. This happened because passwords were stored in an easily guessable format and shared in API responses. To fix, passwords are now stored in a safer way and no longer shared in responses, and users with old passwords will have them updated automatically when they log in.
What to do
- Update litellm to version 1.83.0.
Affected software
| Vendor | Product | Affected versions | Fix available |
|---|---|---|---|
| – | litellm | <= 1.83.0 | 1.83.0 |
Original title
LiteLLM: Password hash exposure and pass-the-hash authentication bypass
Original 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.
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.
ghsa CVSS4.0
8.6
Vulnerability type
CWE-200
Information Exposure
CWE-327
Use of a Broken Cryptographic Algorithm
CWE-916
Published: 8 Apr 2026 · Updated: 8 Apr 2026 · First seen: 8 Apr 2026