📢 New post: When the KEV Item Is the Gateway In Front of Your Models: CVE-2026-42271 and LiteLLM · 📝 Also fresh: From Authorized to Certified: Reading the CR26 Relabel for What It Is · 🚦 Beacon — the FedRAMP 20x KSI emitter — design partners open ✨ · 🆕 20x Hub: program reference, kept current · 🧪 Free tool: KSI Quick Check — paste, run, get the verdict
← Blog
AI SecurityFedRAMPConMonCISA

When the KEV Item Is the Gateway In Front of Your Models: CVE-2026-42271 and LiteLLM

A couple of weeks ago we wrote about the KEV item being your agent platform — Langflow, the visual builder where teams wire up their workflows. The lesson there was that orchestration tools accumulate credentials by design, so arbitrary code execution on one is really code execution on everything it holds keys to.

This time the vulnerable thing sits one layer over: the gateway in front of the models.

On June 8, CISA added CVE-2026-42271 to the Known Exploited Vulnerabilities catalog. It's a command-injection flaw (CVSS 8.7) in LiteLLM — the widely-used open-source proxy that exposes a fleet of model providers behind a single OpenAI-compatible API. The federal remediation deadline under BOD 22-01 is June 22, two weeks out, and it's on the catalog because it's being exploited in the wild, not as a precaution.

We've written about this layer in the abstract before — making the AI gateway a compliance control, the MCP threat surface. This is the concrete version of both at once, and the specifics are worth slowing down on, because they're the lesson.

The mechanism

LiteLLM ships two preview endpoints for testing Model Context Protocol servers: /mcp-rest/test/connection and /mcp-rest/test/tools/list. They accept a full MCP server configuration in the request body — and for a stdio-transport server, that configuration includes command, args, and env fields, because that's literally how you describe a local process to launch.

You can see where this goes. An attacker posts a JSON body describing a stdio MCP server whose command is an arbitrary binary on the host. The proxy does what it was told and spawns the process. That's command execution with the privileges of the proxy process — not a bug in the exotic sense, but a test feature that trusts its caller far more than it should.

The part that turns a bad day into a fire drill is the chaining. On its own, those endpoints sit behind authentication. But researchers paired this with CVE-2026-48710, a host-header validation bypass ("BadHost") in Starlette, the ASGI framework underneath LiteLLM. The Starlette bug lets an attacker slip past the auth check; the LiteLLM bug then hands them a shell. Together they're unauthenticated remote code execution against an exposed LiteLLM deployment.

Affected versions run from 1.74.2 up to — but not including — 1.83.7. The fix is LiteLLM 1.83.7 or later, and you want Starlette on 1.0.1 or later to close the other half of the chain. "We're on a fairly recent version" isn't the reassurance it sounds like here: the vulnerable range is recent.

Why a gateway is the worst place for this

The reason mirrors the Langflow argument, but the gateway makes it sharper. A model proxy exists to be the single front door — every team's traffic to every model provider flows through it, which means it holds every provider key. That's the whole value proposition: one place to manage routing, rate limits, spend, and credentials. It's also, from an attacker's view, one place to find all of them.

So unauthenticated RCE on the gateway isn't "a box got popped." It's potential disclosure of the API keys to every model your organization uses, plus whatever the proxy could reach on the network behind it. The blast radius is the gateway's entire reason to exist.

And there's a quieter point in how it broke. The injection rode in through MCP plumbing — the same connective tissue we flagged in the MCP threat surface. MCP is becoming the default way agents reach tools, and config-as-input is baked into how it describes a server. An endpoint that accepts an MCP server definition is, unless it's very careful, an endpoint that accepts a command to run. That pattern is going to keep showing up, so it's worth recognizing the shape now rather than per-CVE.

If you're inside a FedRAMP boundary

The KEV-clock mechanics are the same ones we walked through with Cisco: a KEV listing inherits its federal due date as your remediation deadline, overriding the usual 30/90/180-day ConMon windows. June 22 is the date. What changes per incident is the question the clock asks first, and for a gateway it's a pointed one:

  • Is it in your inventory, at what version, owned by whom? A model proxy is exactly the kind of thing a platform team stands up to "centralize our LLM access" and never re-classifies from convenience to critical infrastructure. If finding your LiteLLM version means asking around in Slack, the two weeks are already shrinking.
  • Is it reachable from where it shouldn't be? The unauthenticated-RCE chain matters most when the gateway is exposed beyond the boundary it was meant to serve. Where it sits in the network — and what its host header validation and ingress actually allow — is the difference between exposure and a non-event.
  • What keys did it hold? Treat every provider credential the proxy stored as potentially disclosed and rotate it. RCE on the front door means the keys behind the door are suspect, not just the host.
  • What's the evidence trail? Scan output before and after, the version bump, the rotation tickets, a POA&M entry if you opened one. As always, the artifact that survives the next assessment is the trail, not the outcome.

What we keep coming back to

The same unglamorous capability makes this survivable that made Langflow survivable: an inventory query that answers in seconds, a CVE feed wired to the asset list, evidence that collects itself. None of it is specific to LiteLLM — in another couple of weeks the actively-exploited thing will be something else on the same layer.

The piece this one adds is a question worth asking before the next gateway CVE lands: everything your models sit behind — the proxy, the router, the MCP endpoints in between — is it classified and watched like the credential-holding infrastructure it is, or is it still filed under "internal tooling"? That honest answer is the difference between June 22 being a routine patch window and June 22 being a scramble.

It's the shape of work we've been building the Novaprospect audit engine toward — infrastructure-native discovery that finds the proxy nobody wrote down, evidence collected as a normal byproduct, KEV feeds landing in the same triage queue as everything else. A gateway that fronts every model and holds every key is precisely the thing that should never be able to hide from your own inventory.

Reference