The CVSS 9.8 in your inference stack isn't a model — it's the cache connector
Today's most urgent item sits below the models: an unpatched remote-code-execution flaw in the vLLM KV-cache layer, part of a vulnerability cluster in the glue code ML teams harden last.
The dangerous property of LMCache is where it sits. It is the KV-cache connector that lets a vLLM deployment reuse and share computed attention state across requests — infrastructure you bolt on precisely because it speeds up long-context serving. A remote-code-execution flaw there, rated CVSS 9.8 and unpatched, means an attacker reaches your serving host through the component you added for performance, not through anything in the model.
The pattern repeats across the stack. Pwn2Own paid out on two LiteLLM exploits ($55,000 combined) against the proxy many teams use as their LLM gateway. It also paid $40,000 on a Codex argument-injection bug that bites CI automation feeding untrusted repos or issues to the agent. Ox Security rated a DeepSeek Harness sandbox escape CVSS 9.4 — directly relevant if any agent-eval or code-execution pipeline runs on it. Every one of these lives in cache connectors, proxies, runtimes, and argument parsing: the parts of an ML serving stack that get adopted fastest and reviewed least.
Why this is your problem specifically
A self-hosted vLLM stack is now standard for teams that want cost control and data residency. That same choice makes you the operator responsible for the serving layer's security, and the LMCache flaw turns an inference optimization into an unauthenticated entry point. The same reasoning applies to the gateway: a compromised LiteLLM admin endpoint hands over provider API keys, which an attacker can then bill against or use to pivot.
The second-order risk is that these components hold credentials and data, not just compute. A proxy stores provider keys. A harness that executes model-written code has whatever scope you granted it. Patching the hole does not un-leak a key that was already reachable, so remediation is a two-step move: close the exposure, then rotate everything the exposed component could touch.
The smart move
Treat this as a this-week containment problem, not a monitoring item. Disable or network-isolate LMCache until a patched release ships; the connector is an accelerator, so a stack runs correctly without it. Then audit the gateway and the harness as separate blast radii. Anthropic's new free open-source vulnerability scanner is a reasonable secondary sweep across your serving repos, but it is not a substitute for isolation. No precision figure has been published for that scanner, so gate anything it surfaces on sandboxed reproduction before you act on it.
What to do
Inventory every vLLM deployment using LMCache today and disable the connector or restrict it to a private subnet until a patched release ships.
Audit LiteLLM gateway versions this sprint: lock admin endpoints, rotate provider API keys, and sandbox any Codex automation that touches untrusted repos or issues.