Two flaws in LiteLLM, the open-source gateway that many organisations put between their applications and AI providers, could let any logged-in user take over the gateway and walk off with every provider API key it holds. Fixes are available, and anyone running a self-hosted instance older than 1.83.9 should treat this as a priority patch and a prompt to review who can log in.
What happened
On 13 October 2026 Check Point Research published the results of a security review of the LiteLLM proxy, a popular open-source project that lets developers reach OpenAI, Anthropic, Google and many other model providers through a single interface. The researchers tested version 1.77.7 and reported two issues to the maintainers through coordinated disclosure. The authorisation bug is CVE-2026-35029; the SSRF is CVE-2026-59823.
The first is a broken access control problem on the endpoint used to change the gateway’s configuration while it is running. The second is a server-side request forgery (SSRF) weakness in a feature that lets callers supply their own model routing settings. Check Point says both are resolved in LiteLLM 1.83.9. According to the project’s own advisories, as summarised by Let’s Data Science, the authorisation flaw was actually patched earlier in 1.83.0 and the SSRF in 1.83.9, so 1.83.9 or later is the version to confirm across every deployment.
No exploitation in the wild has been publicly reported.
The technical picture
The more serious bug, CVE-2026-35029, comes down to a missing role check. Other administrative routes, such as invitation creation, confirm the caller holds the proxy admin role before acting. The configuration update route did not. On top of that, sessions created through the web dashboard were matched against a list of permitted “UI” routes using simple prefix matching, and because that list included a path intended for reading configuration, the write path slipped through as well. The upshot is that a user with the most basic internal role could rewrite the gateway’s runtime settings.
Check Point showed three ways to turn that into serious harm:
- Arbitrary file read: by changing an environment variable that controls where the dashboard logo is loaded from, an attacker could make the server return any file the LiteLLM process can read, including secrets and configuration.
- Admin takeover: the built-in dashboard login checks credentials held in environment variables, so overwriting those values let a low-privilege user sign in as the default administrator.
- Remote code execution: LiteLLM can load custom adapter modules for pass-through endpoints from Amazon S3 or Google Cloud Storage. Pointing a new endpoint at attacker-controlled storage caused the gateway to download and execute Python code.
The second bug, CVE-2026-59823, abuses a documented feature called Clientside LLM Credentials. Any authenticated caller could pass routing settings in a chat request, including a custom destination for the upstream API call. Point that at a server you control and the gateway obligingly forwards the request there, along with the provider key configured in its default headers. This route bypassed LiteLLM’s existing limits on client-supplied API addresses. The researchers also flagged unsalted, single-iteration password hashes that low-privilege users could read, an issue LiteLLM was already tracking.
Why it matters for UK organisations
LLM gateways have quietly become one of the most sensitive components in a modern AI stack. They centralise provider credentials, routing, spend tracking and logging, which means a single compromised gateway can hand over keys for every model provider a business pays for, plus visibility of the prompts and responses flowing through it.
Across the UK, a lot of internal AI tooling has been built quickly by small engineering or data teams, often in containers on a cloud account, and frequently outside the normal change and security review process. Boris Cipot of Black Duck warned Hackread that LiteLLM is often embedded in other AI platforms, so some organisations will not know they run it. That kind of hidden dependency breaks asset inventories.
Stolen AI provider keys are not a theoretical loss either. They carry a direct financial cost, because the victim pays for whatever an attacker runs, and they can expose sensitive business data sent to models. For organisations handling personal data, a gateway compromise that exposes prompts or logs could also become a reportable incident under UK GDPR, with the ICO expecting evidence of appropriate technical controls.
Expert view
Nothing here is a new class of attack. Missing function-level authorisation, overly generous allowlists, SSRF and dynamic code loading from remote storage are textbook web application issues that we have been finding for two decades. What has changed is where they live. In my experience, AI infrastructure is treated as an experiment until it quietly becomes production, and the security review never catches up.
Plenty of teams will have set up LiteLLM with sensible roles, given most staff a basic account and assumed that was enough. These flaws show why role design means little unless someone has tested that a low-privilege account really cannot reach admin functions. When we test web applications, horizontal and vertical privilege checks across every route are routine; the same discipline needs to reach AI gateways, model routers and agent platforms.
I would also be wary of how many people hold accounts on these gateways. Because the exploits only need a valid login, every contractor, former employee or shared service account left active becomes a potential route to the master keys. Christopher Jess of Black Duck described the bugs to Infosecurity Magazine as “familiar application security failures”, and that is the right framing: familiar problems with an unusually valuable prize.
What to do now
- Find every instance. Search container registries, Kubernetes manifests, Python dependency files and cloud workloads for LiteLLM, including copies embedded in other AI tools.
- Upgrade to 1.83.9 or later. This maps directly to the Cyber Essentials security update management control, and given the impact it deserves the same urgency as a critical fix.
- Prune and review accounts. Remove dormant users, contractors and shared logins, and enforce MFA through SSO where possible. This is the user access control requirement of Cyber Essentials applied to AI tooling.
- Restrict network exposure. Keep the admin dashboard and API off the public internet, and limit outbound traffic from the gateway to the provider endpoints it genuinely needs. Egress filtering blunts both the SSRF and the remote module loading path.
- Check for tampering and rotate keys if in doubt. Review configuration history, environment variables, pass-through endpoint definitions and admin logins for changes you cannot explain. If anything looks wrong, rotate every provider key stored in the gateway and check provider billing for unusual usage.
- Bring AI tooling into scope. Add LLM gateways and similar components to your penetration tests, and test enforced permissions for each role, not just the configured ones.
Bottom line
LiteLLM’s flaws are a reminder that the riskiest part of an AI deployment is often not the model but the plumbing around it. A gateway that holds every provider key deserves the protection you would give a password vault or a cloud admin console. Patch, cut back who can log in, restrict what the gateway can reach, and make sure your next security assessment covers the AI stack as well as the web front end.
Sources
- Check Point Research: When LLM Gateways Go Wrong: Findings from LiteLLM
- Infosecurity Magazine: Warning Over High-Risk Vulnerabilities in Widely Used LLM Gateway Tool
- Hackread: Check Point Reports LiteLLM Flaws Enabling Admin Takeover and API Key Theft
- Let’s Data Science: Check Point Details LiteLLM Gateway and Key-Theft Flaws
