AI News Security flaws found in top open source AI gateway — LiteLLM vulnerabilties could affect millions of users

Brownie2019

Level 23
Verified
Well-known
Forum Veteran
LiteLLM users told to patch immediately
  • Two LiteLLM flaws let low-privileged users gain administrative control and execute malicious code
  • Attackers could also steal AI provider API keys through a server-side request forgery bug
  • Organizations should upgrade to LiteLLM 1.83.9+ and rotate potentially exposed credentials
Security researchers recently discovered two vulnerabilities in a popular AI gateway that allowed threat actors to take complete control of the system, steal sensitive files and AI provider API keys, and execute malicious code remotely.
The AI gateway in question is called LiteLLM. It is an open source solution allowing users to connect their applications to large language models (LLM) from different providers, including the likes of OpenAI and Anthropic.
The connection goes through a single interface, where users can route requests, manage API keys, control user access, and monitor things like usage and costs.
Right now, LiteLLM supports some 140 AI providers and has become quite popular - it has more than 90 million monthly downloads on GitHub, and more than 61,000 stars.

LiteLLM
However, security experts from Check Point Research (CPR) recently found two bugs in LiteLLM.
The first one is an access control bug in the way LiteLLM enforces permissions. It is tracked as CVE-2026-35029 and was given a severity score of 8.7/10 (high). According to CPR, the bug allows users with minimal privileges to reach admin functions controlling the gateway’s core configuration which, in turn, allows them to read files stored on the server, overwrite admin credentials, download and run malware, and more.

The second one is a server side request forgery bug, allowing gateway users to direct LiteLLM to send API requests to third-party servers. In theory, threat actors could send API requests to servers under their own control, and since these carry AI provider authentication keys, this would deliver the credentials directly to the attackers. In turn, they could use the credentials to use other organizations’ AI accounts and rake up their bills. The bug is tracked as CVE-2026-59823 and was given a severity score of 5.3/10 (medium).
“The credentials a gateway holds provide direct, billable access to AI providers with no further authentication required,” CPR explained. “Given LiteLLM’s scale of adoption, a flaw in this component has the potential to affect a very large number of AI deployments at once.”

Vulnerable versions and patches
CPR says that all organizations running LiteLLM versions earlier than 1.83.9 are exposed to both vulnerabilities. Security teams should also check for LiteLLM instances running indirectly, since the gateway is embedded in many platforms and internal tools used to build AI applications. As such, it could be present in environments where it was never deployed as a standalone solution.

LiteLLM has released a fix for both bugs included in version 1.83.9, and users are advised to install this one as soon as possible. Besides that, CPR advises users review who has access to the gateway, since any account could be used to exploit these flaws. AI provider API keys stored in LiteLLM should be rotated if there is any indication the gateway way accessed by unauthorized users, and permissions should be verified in practice.

“Confirm that users with limited roles are actually limited, because the gap between configured and enforced permissions is where flaws like CVE-2026-35029 cause the most damage,” CPR warns.
“Include LLM gateways in security assessments by extending penetration tests and vulnerability assessments to cover AI tooling alongside web applications and cloud infrastructure.”
According to the researchers, both bugs are a “well understood class” of errors, meaning AI infrastructure suffers from the same risks as enterprise software. That means organizations need to approach AI gateway security “with the same rigor they apply to any other business critical system.”
 
Hi Brownie2019. These are serious flaws because an AI gateway is both a traffic hub and a credential store, but this was not unauthenticated, drive-by RCE. Both attacks required access to the LiteLLM Proxy: CVE-2026-35029 required an authenticated user, while CVE-2026-59823 required a valid virtual key. A supposedly low-privileged account was nevertheless enough, which rather defeats the purpose of calling it low-privileged.

One version detail in the report needs tightening:

  • CVE-2026-35029: affects versions before 1.83.0 and was fixed in 1.83.0, according to the LiteLLM advisory.
  • CVE-2026-59823: affects versions through 1.83.8 and was fixed in 1.83.9, according to its advisory.

Therefore, 1.83.9 is the minimum version covering both, but versions 1.83.0–1.83.8 were not vulnerable to both flaws. Administrators should preferably move to a current supported release rather than treating an old minimum patched version as the destination.

The scale claim also deserves context. The roughly 90 million figure is PyPI package downloads, not GitHub downloads or 90 million users; current PyPI statistics show about 92 million downloads in the last month. Automated builds, mirrors and repeated container installations greatly inflate that number. Also, these vulnerabilities concern the LiteLLM Proxy—a project merely importing the client library is not automatically exposing the vulnerable endpoints. The research demonstrates the impact in a controlled environment; it does not show that millions of installations were compromised.

For operators, I would prioritise:

  1. Inventory standalone and embedded LiteLLM Proxy deployments, including old containers and internal AI platforms.
  2. Upgrade every replica to a current version at or above 1.83.9.
  3. Review requests to /config/update, unexpected configuration/environment changes, pass-through handlers, image paths and outbound requests to unfamiliar hosts.
  4. Check which users and virtual keys could reach the proxy during the vulnerable period.
  5. Rotate provider API keys if untrusted users had access or logs show suspicious redirection. If configuration abuse, file access or code execution is suspected, treat the server as compromised and rotate all secrets accessible to that process after rebuilding it from a known-good image.
  6. Restrict management endpoints and use egress controls so the gateway can contact only approved AI-provider services.

As Check Point’s technical analysis illustrates, there is little uniquely “AI” about the underlying mistakes: missing authorization and SSRF are old acquaintances. The AI gateway simply gives them a much juicier set of keys to steal.

Sources
 

Recently browsing

Members who viewed this thread in the last 5 minutes

Back
Top