LiteLLM CVE-2026-59822: Update to 1.84.0 — Exploited MCP Auth Bypass

On September 2, 2026, CISA added vulnerabilities in the AI gateway LiteLLM and the Python ASGI framework Starlette to its Known Exploited Vulnerabilities (KEV) catalog.

The short version: update LiteLLM to 1.84.0 or later and Starlette to 1.0.1 or later. If your LiteLLM is reachable from the internet, blocking `/mcp/` buys you time before the upgrade — that is the vendor's own documented workaround.

This article covers only what could be confirmed on September 3, 2026 against CISA KEV, NVD, and the vendors' GitHub security advisories.

Do this now

• ✓Update LiteLLM to 1.84.0 or later. That single upgrade closes both CVE-2026-59822 and CVE-2026-42271
• ✓If you cannot upgrade immediately, disable the MCP routes or block `/mcp/` and related MCP endpoints at your reverse proxy or API gateway. This is the workaround stated in the vendor advisory
• ✓Update Starlette to 1.0.1 or later. Everything 1.0.0 and below is affected
• ✓Check this even if you never installed Starlette directly — FastAPI and other frameworks pull it in as a dependency
• ✓Look for middleware in your own code that makes authorization decisions from `request.url` or `request.url.path`. If you have any, switch it to the raw `scope` path
• ✓If LiteLLM is exposed to the internet, reconsider whether it needs to be

All three scores above are NIST's (NVD's) Primary CVSS v3.1 ratings, quoted on one ruler for comparability. GitHub's advisories rate some of them under CVSS v4.0, where the numbers differ.

• ▸CVE-2026-59822: NIST v3.1 8.2 / HIGH, GitHub v4.0 8.8 / HIGH
• ▸CVE-2026-42271: NIST v3.1 8.8 / HIGH, GitHub v4.0 8.7 / HIGH
• ▸CVE-2026-48710: v3.1 6.5 / MEDIUM from both NIST and GitHub

Different versions produce different numbers, so do not be thrown when NVD shows something else. In this case the scores barely matter anyway — all three are classified as actively exploited.

A CVSS 6.5 that landed on the exploited list

This is the most useful part of the story. Starlette's CVE-2026-48710 is a 6.5 / MEDIUM, sitting squarely in the band most teams defer.

It made KEV anyway. KEV is a catalogue of vulnerabilities CISA has evidence are being actively exploited. A middling score and whether something gets used in attacks are simply two different questions, and this is what that looks like.

Nor is the standalone impact merely "a bit of information leaks." Per the vendor, it lets an attacker bypass the authorization check itself wherever that check relies on `request.url.path`, so code behind it runs for requests that should never have reached it.

Here is what each of the three actually does.

• ▸CVE-2026-59822 (LiteLLM, unauthenticated): a fabricated `Authorization` header triggers an OAuth2 passthrough fallback that replaces failed key validation with an empty `UserAPIKeyAuth()` object. Requests reach MCP tooling without a valid LiteLLM key
• ▸CVE-2026-48710 (Starlette, auth bypass): a crafted Host header slips past middleware that decides permissions from `request.url`. Path-based authorization stops working
• ▸CVE-2026-42271 (LiteLLM, code execution): MCP server preview endpoints accept a full configuration including `command`, `args` and `env`, and spawn that command as a subprocess on the proxy host. They are gated only by a valid proxy API key, with no role check

CISA's KEV entry explicitly states that CVE-2026-48710 can be chained with CVE-2026-42271 — bypass path-based authorization with 48710, then reach command execution on the host with 42271.

Neither CISA nor the vendor advisory says anything about chaining CVE-2026-59822 into 42271. What 59822 gives you is the ability to list and call configured MCP tools without a valid LiteLLM key; it is not documented as yielding the proxy API key that 42271 requires. This article does not assume a chain it cannot source.

CVE-2026-42271 has been on KEV since June 8, 2026. All three are independently classified as exploited — fixing one of them is not a substitute for the others.

Inside the Starlette bug: a Host header that shifts request.url.path

The vendor advisory's own example explains it best.

Affected versions rebuilt the URL by concatenating `http://{host}{path}` and re-parsing the result. But per RFC 9112 §3.2 and RFC 3986 §3.2.2, a `Host` header may only contain `uri-host [ ":" port ]`. Slip in a `/`, `?` or `#` and the path and query boundaries move during that re-parse.

GET /foo HTTP/1.1
Host: example.com/abc?bar=

# reconstructed URL: http://example.com/abc?bar=/foo
# request.url.path becomes /abc
# but routing still dispatches on the real path /foo

The router dispatches to the real `/foo` and runs the endpoint, while middleware reading `request.url.path` sees `/abc`. If you implemented "only admins below `/admin`" as middleware, that check is what gets bypassed.

Version 1.0.1 fixes it by validating the `Host` header against the grammar in those RFCs when constructing the URL.

What makes this one awkward is that exposure has nothing to do with whether you think of yourself as a Starlette user. Plenty of frameworks — FastAPI among them — are built on it and carry it deep in the dependency tree. LiteLLM is one of them.

Checking whether you are affected

# check the installed versions
pip show starlette litellm

# find what pulled Starlette in
pip install pipdeptree
pipdeptree --reverse --packages starlette

# upgrade
pip install --upgrade 'starlette>=1.0.1'
pip install --upgrade 'litellm>=1.84.0'

• ▸Starlette: `1.0.0` and below affected, fixed in `1.0.1`
• ▸LiteLLM (CVE-2026-59822): everything before `1.84.0` affected, fixed in `1.84.0`
• ▸LiteLLM (CVE-2026-42271): `1.74.2` up to but not including `1.83.7` affected. Moving to `1.84.0` covers both

CISA's remediation deadlines were September 16, 2026 for the two added on September 2, and June 22, 2026 for CVE-2026-42271. Those bind US federal agencies rather than private companies elsewhere, but they are a perfectly good yardstick for how urgent "soon" should mean.

What to take away from this

Prioritising purely by CVSS score would have missed this chain. A 6.5 did not mean "handle it later." What CISA tracks is not the number but whether the flaw is actually being exploited. If your process filters by score, add KEV membership as a second, independent axis.

And do not assume the framework is handling authentication for you. The Starlette issue is a case of a value that looks trustworthy — `request.url` — being rewritten by a header the client controls. It is worth tracing how much of the data behind your authorization decisions originates outside your system.

Finally, AI infrastructure is ordinary attack surface. An AI gateway like LiteLLM is a new kind of component, but underneath it is a Python web application, and it grows authentication holes and command execution holes exactly like anything else. Do not file it separately — put it in the same inventory as every other internet-facing server you run.