Summary
LiteLLM: Password hash exposure and pass-the-hash authentication bypass
Impact
Three issues combine into a full authentication bypass chain:
- 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.
- 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.
- 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.
The application uses a cryptographic algorithm known to have weaknesses, such as MD5, SHA-1, or DES. Typical impact: compromised confidentiality or integrity of protected data.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Remediation advice
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.
Frequently Asked Questions
- What is GHSA-69X8-HRGQ-FJJ8? GHSA-69X8-HRGQ-FJJ8 is a high-severity use of a broken or risky cryptographic algorithm vulnerability in litellm (pip), affecting versions < 1.83.0. It is fixed in 1.83.0. The application uses a cryptographic algorithm known to have weaknesses, such as MD5, SHA-1, or DES.
- Which versions of litellm are affected by GHSA-69X8-HRGQ-FJJ8? litellm (pip) versions < 1.83.0 is affected.
- Is there a fix for GHSA-69X8-HRGQ-FJJ8? Yes. GHSA-69X8-HRGQ-FJJ8 is fixed in 1.83.0. Upgrade to this version or later.
- Is GHSA-69X8-HRGQ-FJJ8 exploitable, and should I be worried? Whether GHSA-69X8-HRGQ-FJJ8 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-69X8-HRGQ-FJJ8 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-69X8-HRGQ-FJJ8? Upgrade
litellmto 1.83.0 or later.