LiteLLM flaw lets any logged-in user take over the gateway

Published

Anyone with even a basic login to a LiteLLM gateway could rewrite its configuration, read files off the server, seize the built-in admin account and run their own code on it, according to new research from Check Point Research. The flaws are fixed in LiteLLM 1.83.9, and anyone running an older proxy should upgrade.

LiteLLM is an open-source gateway that sits between applications and AI model providers, handling routing, rate limits, usage tracking and, crucially, the provider API keys. That position is what makes these bugs serious: a compromised gateway can hand over every credential it holds plus a foothold inside the network it runs on. The project has made our pages before, last month when a single-letter authentication bypass unlocked hundreds of AI gateways.

One missing role check opened the admin panel

Check Point tested version 1.77.7. The core issue, tracked as CVE-2026-35029, is that the administrative POST /config/update endpoint, which changes the proxy's runtime settings, only checked that a caller was logged in, not that they held the Proxy Admin role. Other admin endpoints in the same code do perform that check.

A second weakness made it reachable. Every user who signs in to the LiteLLM web interface receives a temporary token tied to a special dashboard team, and those tokens are checked against a looser list of allowed routes. That list includes /config, which the researchers believe was meant for reading settings, and the match is a simple prefix test. Because "/config/update" starts with "/config", the request is waved through for any interface user, including the baseline Internal User role.

From a settings change to a shell

The endpoint accepts environment variables, and the researchers showed three ways to turn that into a full compromise:

A documented feature that leaks provider keys

The second bug, CVE-2026-59823, is a server-side request forgery (SSRF, where an attacker makes the server send requests to an address of their choosing) in the "Clientside LLM Credentials" feature. Any authenticated user can pass a user_config parameter that builds a fresh router with an attacker-chosen API address. The gateway then sends the model request, including provider API keys the user should never see, to the attacker's server. Check Point says this path sidesteps the restrictions LiteLLM places on the more direct api_base and api_key parameters.

The team also reported that password hashes were exposed to low-privilege users and were generated with a single unsalted hash, issues LiteLLM was already tracking as duplicates under an existing GitHub advisory. Check Point has not published CVSS scores for either CVE.

Upgrade to LiteLLM 1.83.9 and rotate keys

Both CVEs are resolved in version 1.83.9. Operators on earlier releases should upgrade, review who holds interface accounts, and treat provider API keys and admin credentials on any instance that untrusted users could log in to as potentially exposed. Check Point's report does not mention exploitation in the wild. Gateways holding model-provider keys have already drawn attackers this year, as the case of hackers pulling AI proxy keys straight out of memory showed.

None of this is an exotic AI attack. It is a missing authorization check, a loose prefix match and unchecked module loading, the same mistakes web applications have made for decades, now sitting in front of an organization's entire supply of model credentials.

This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.

Read the full analysis on IntelFusions