LLM Gateways: LiteLLM CVE-2026-59822 in KEV, LightLLM CVE-2026-90919 a 9.8 RCE

Two vulnerabilities targeting the infrastructure that serves language models, published or confirmed exploited a few days apart:

Fixes: LiteLLM 1.84.0. For LightLLM, all versions through 1.2.0 are affected; NVD exposes no fixed version — check the project repository.

This is the second LiteLLM CVE added to KEV in four months, after May's SQL injection. And each of these two flaws illustrates a design error typical of infrastructure built very fast.

CVE-2026-59822 — LiteLLM: authentication that fails open

Prior to 1.84.0, LiteLLM's MCP Streamable HTTP endpoint allowed an unauthenticated attacker to use a fabricated Authorization header to trigger an OAuth2 passthrough fallback path that replaced failed LiteLLM key validation with an empty UserAPIKeyAuth() object, allowing requests to reach MCP tooling without a valid LiteLLM key.

Read that last sentence slowly, because it describes an error found everywhere.

1. The request arrives with a made-up Authorization header.
2. LiteLLM key validation fails — as it should.
3. Instead of rejecting the request, the code falls into an OAuth2 fallback path.
4. That fallback path produces an empty authentication object.
5. An empty object is treated as successful authentication.

This is fail-open: when the control doesn't know what to decide, it lets the request through. The opposite design rule — anything not explicitly allowed is denied — is the oldest in security, and the first to give way when authentication modes are added in a hurry.

Why "MCP" makes it worse

MCP (Model Context Protocol) is how a model calls tools: read files, query a database, call an API, send a message. Reaching MCP tooling without a key isn't just consuming model credit: it's being able to trigger the actions those tools allow, with the credentials the gateway holds to run them.

The vector's C:H confirms it: data access is at stake, not just the bill.

CVE-2026-90919 — LightLLM: pickle over the network

LightLLM through 1.2.0 contains a remote code execution vulnerability in the Config Server's unauthenticated /visual_register WebSocket endpoint that passes the first client frame directly to pickle.loads().

There isn't much to analyse, and that's exactly the point: deserialising pickle received from the network is code execution by definition. Python's pickle format lets an object specify, via __reduce__, which function to call on reconstruction. An attacker supplies an object that says "call os.system with this command". That isn't a bug in pickle, it's its specification — the Python documentation warns about it at the top of the page.

The error is an architectural assumption: the Config Server was designed for a trusted network, between components of the same deployment. The moment the port is reachable by anything else, the assumption collapses.

What an inference server holds

• GPUs — a resource attackers monetise directly (mining, resold capacity)
• Model weights, sometimes proprietary and expensive to produce
• User prompts, which often contain sensitive data
• Network access to the systems feeding the model

The Common Thread

LiteLLM and LightLLM share neither code nor maintainers. They share a context: AI-ecosystem projects adopted massively in production before maturing on security. They exhibit the mistakes the rest of the industry learned to avoid fifteen years ago — permissive authentication fallback, deserialising arbitrary objects, internal services assumed unreachable.

That isn't a criticism of these projects: it's a property of adoption speed. But it has an operational consequence — these components deserve the same update discipline as any exposed service, and they almost never get it.

Identifying Your Exposure

# LiteLLM
pip show litellm | grep -i version
docker ps --format '{{.Image}}' | grep -i litellm

# LightLLM
pip show lightllm | grep -i version
# Ports opened by the deployment — the Config Server must not be reachable outside the cluster
ss -tlnp | grep -i python

Detection

LiteLLM

• Requests to MCP endpoints carrying an Authorization header matching no issued key
• MCP tool calls not attributable to a known key in the gateway logs
• Model consumption or tool calls outside the usual profile

LightLLM

• WebSocket connections to /visual_register from addresses outside the deployment
• Unexpected child processes of the Config Server process
• GPU usage unrelated to observed inference load

Mitigation

1. LiteLLM: move to 1.84.0 or later

It's in KEV: the CISA deadline was September 16.

2. LightLLM: isolate the Config Server immediately

Pending a fixed release, the Config Server port must only be reachable by the deployment's other components. Firewall rule, Kubernetes NetworkPolicy, or binding to an internal interface — it's the only effective measure while pickle.loads() stays in the path.

3. Across AI infrastructure

• No gateway or inference server internet-exposed without authentication in front (reverse proxy, VPN)
• Minimally scoped keys: a key without MCP tool access can't be used to call them
• MCP tool credentials treated as production secrets, with rotation

4. If you suspect a compromise

• LiteLLM: rotate every gateway API key and the model-provider and MCP-tool credentials it holds
• LightLLM: treat the host as compromised at system level; rebuild rather than clean

Why Continuous Monitoring of AI Infrastructure Matters

LLM-ecosystem components are deployed by product and data teams, often outside IT processes, and evolve at a release pace nobody tracks manually. Two CVEs in a few days, one already exploited, on building blocks most organisations have entered in no inventory at all.

With cveo.tech, inventory your LLM gateways, inference servers and AI libraries with exact versions, and get automatic alerts whenever a critical CVE affects them.