- Check Point Research found that a low-privileged LiteLLM user could change the gateway's settings, leading to file reads, admin takeover and code execution.
- Check Point says an admin takeover reaches any provider credentials the gateway holds, and code execution gives an attacker a foothold in the network around it.
- Check Point reports fixes as of version 1.83.9. Teams should confirm their version and who holds accounts.
The guard checked the badge, not the door
An AI gateway is a front desk for your models. Applications send requests to it, and it forwards them to the right model provider. It also holds the keys to those providers.
Check Point Research tested LiteLLM, a widely used open-source gateway, and found that its front desk checked whether you had a badge. It did not check which doors the badge should open. The lesson here is that the risk in AI infrastructure often sits in ordinary permission logic, not in the AI itself.
What Check Point found
Check Point reviewed LiteLLM version 1.77.7. It found multiple high-impact flaws, tracked as CVE-2026-35029 and CVE-2026-59823. The researchers say they are resolved as of version 1.83.9.
The main problem was an endpoint called /config/update. It lets an administrator change the gateway's settings while it runs. Check Point found that it never confirmed the caller was an administrator. Any signed-in user, including one with the basic "Internal User" role, could use it.
How one small rule opened the door
Other admin functions in LiteLLM, such as creating invitations, explicitly check for the admin role. The config update function did not. It relied only on a general check that the user was logged in.
A second design choice made it worse. When anyone logs into the LiteLLM dashboard, the gateway issues a session key tied to a special team called litellm-dashboard. The gateway treats every key from that team as a dashboard key. Dashboard keys face a looser route check.
That looser check works by matching the start of the address. The allowed list contains /config, which Check Point says was likely meant for reading settings. Because /config/update begins with /config, it passed. A rule written for reading became a rule for writing.
What an attacker could do with it
The endpoint lets a caller set environment variables, which are settings the gateway reads at runtime. Check Point showed three ways to abuse this.
First, file reading. One setting controls which file the gateway serves as its logo. Pointing it at a sensitive file made the gateway return that file. Check Point demonstrated this with /etc/passwd, a system user list.
Second, admin takeover. The dashboard login compares passwords against the UI_USERNAME and UI_PASSWORD settings. A low-privileged user could overwrite them and log in as the full Proxy Admin. Check Point says this gives total control of the gateway and access to any provider credentials it holds.
Third, code execution. The same endpoint can define pass-through endpoints whose target points to cloud storage, using s3:// or gcs:// addresses. Check Point says LiteLLM then downloads and runs the Python file there. That gives a low-privileged user a way to run commands on the gateway and a foothold in the network where it runs.
Check Point also reports a separate server-side request forgery flaw in the "Clientside LLM Credentials" feature. It allowed attackers to redirect API calls and steal provider keys.
Limits of the finding
The attacker needs a valid account first. Check Point's tests show that the basic "Internal User" role was enough. The summary available here does not describe attacks in the wild.
Check Point tested one version, 1.77.7, and reports the fix as of 1.83.9. The material reviewed does not say how many versions in between are affected.
Questions to put to your team
Ask which version of LiteLLM, or any LLM gateway, your organisation runs, and whether it is at or past 1.83.9. Ask who holds accounts on it, including contractors and test users.
Ask what the gateway can reach. If it stores provider keys, an admin takeover gives access to the credentials it holds. Ask whether those keys can be limited by spend or scope, and how fast your team could rotate them.
Ask whether the gateway's admin and configuration paths are reachable from the same network as ordinary users. And ask who reviews new AI infrastructure with the same rigour as a payment system.
A gateway concentrates trust. Treat it like a vault, and test the doors, not only the badges.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Check Point Research.
