LiteLLM Flaws Let a Basic User Account Take Over the AI Gateway

In LiteLLM, the open-source gateway for language models, a low-level authenticated account could rewrite the proxy's runtime configuration. The attacker didn't need any admin role or any access to the machine running the proxy.

Check Point Research published its findings on October 13, 2026, in an analysis of version 1.77.7^[1]. The flaws are tracked as CVE-2026-35029 and CVE-2026-59823. Version 1.83.9 fixes them.

The report describes a security review and mentions no cases of active exploitation. IT Security Guru^[2] also covered the story.

A missing check on /config/update

LiteLLM is an open-source project that came out of Y Combinator. It offers an SDK and a gateway that sends calls to multiple model providers.

The gateway sits between applications and providers. It stores the API keys, decides where each request goes, and keeps logs and usage limits.

According to Check Point, the /config/update endpoint did not check permissions. Any authenticated user could change the proxy's active configuration. The researchers say this change could lead to three outcomes.

• Reading arbitrary files on the server.
• Taking over the admin account.
• Running code remotely through malicious Python modules loaded from cloud storage.

The second flaw is in the "Clientside LLM Credentials" feature. Check Point classifies it as SSRF (server-side request forgery), where the server sends a request on the attacker's behalf. This flaw sent API calls, along with the provider keys, to a destination the attacker chose.

The configuration decides which code runs

Both flaws have the same root cause.

LiteLLM treated its configuration as data to be managed. But in the proxy, the configuration also says which Python modules to load.

That means a field pointing to a module works as permission to run code. Anyone who can write to that field can run code on the proxy.

The gateway makes the damage worse. The keys for every provider, the routing rules and the user accounts all live in the same process. So one missing permission check on one endpoint gives access to every model the company uses.

Check Point ends its summary by pointing to two security basics: access control and input validation. It's the same mistake web apps made in the early 2000s, now inside the component that holds all the keys.

Three questions if you run LiteLLM in production

1. Which version are you running today? Versions before 1.83.9 are still exposed to both flaws.
2. Who has an account on the proxy? Every authenticated user could have become an admin, so your account list is also a list of people who could reach the keys.
3. Did you rotate the provider keys after upgrading? The patch fixes the flaw, but any keys read before then stay valid until you revoke them.

The gateway is now part of identity security

An LLM gateway is production-grade when it separates roles. Reading logs, using a model and changing the configuration are three different permissions.

Version 1.83.9 fixes both CVEs. The architectural risk remains, because every gateway keeps the same keys in the same place.

This case calls for six practical steps.

• Upgrade LiteLLM to 1.83.9 or later.
• Rotate every provider API key stored in the proxy.
• Review the proxy's accounts and close any that are inactive.
• Allow access to the /config/update endpoint only from the admin network.
• Limit the network destinations the proxy can call to reduce SSRF exposure.
• Ask commercial gateway vendors how they keep configuration permissions separate from usage permissions, and put it in the contract.

Security budget owners have a new line item. The gateway should get the same audits as the company's identity system.