al-ice.ai

Your KV Cache Has a Shell: LMCache CVE-2026-107204 Turns a POST Into Root on the Inference Host

AI Vulnerabilities & CVEs by al-ice.ai Editorial

On 7 October 2026, NVD published CVE-2026-107204: LMCache through 0.5.5 — the open-source KV-cache layer that sits in front of vLLM in a large share of self-hosted inference stacks — contains an unauthenticated remote code execution vulnerability. Remote attackers can execute Python code by posting scripts to the /run_script endpoint, then escape the guarded import to run operating-system commands as the LMCache process. CVSS 3.1 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), CWE-306, missing authentication for critical function. The reporter credits go to Mingkai Yu and Jiajia Liu, via VulnCheck, against an inference ecosystem we already know ships fixes slowly.

The mechanism deserves attention because it is a designed code-execution endpoint with a sandbox that does not hold. The /run_script handler executes posted scripts with a guarded __import__ — and the injected FastAPI app object hands attackers a path back to the real builtins, bypassing the guard entirely. From there it is import os and arbitrary commands with the privileges of the LMCache process, which on GPU hosts typically means a service account with broad filesystem and device access. This is not deserialisation or a buffer overflow. It is a front door with a lock the door itself hands you the key to.

The sibling is arguably worse for operations

Published the same day, CVE-2026-107206 (CVSS 3.1 9.4) is a missing-authentication flaw in the multiprocess-mode HTTP server: management endpoints listen on all interfaces by default with no authentication, letting remote unauthenticated attackers read environment variables — read: credentials — and manipulate cache state including quotas. An unauthenticated RCE gets the CVE spotlight, but an unauthenticated environment read on inference infrastructure is a credential harvester that also tells the attacker exactly which models, backends, and keys the estate holds. Treat any internet-reachable LMCache multiprocess port as a secrets disclosure until proven otherwise, and rotate anything that lived in those environments.

No stable fix is published yet

As of writing, the NVD records reference the LMCache repository, the vulnerable source files at tag v0.5.5, and upstream issue #5510 — but no fixed release. The repository's newest tags are v0.5.6rc3 pre-releases cut on 6 October, before the CVE publication, and nothing in the public record confirms they contain the fix. Affected range per NVD is every version from 0 through 0.5.5 (pkg:pypi/lmcache). Do not read the release-candidate tags as remediation; verify against the upstream fix for issue #5510 before closing anything.

What to do

  • Assume exposure, then prove otherwise. Inventory every host running LMCache at or below 0.5.5, especially multiprocess deployments. Check whether the internal API server and multiprocess HTTP ports are reachable beyond localhost — the 107206 record states all-interfaces binding is the default.
  • Remove it from the network before patching it. With no confirmed stable fix, the immediate control is network posture: bind the internal API and multiprocess endpoints to loopback, firewall the ports, and never expose them through ingress alongside the OpenAI-compatible serving port. The serving port is the one your architecture diagrams show; these are the ones attackers will find.
  • Rotate credentials that lived in LMCache environments. CVE-2026-107206 exposes environment reads without authentication. API keys, backend credentials, and cloud tokens on affected hosts should be treated as disclosed.
  • Look for execution, not just access. Review logs for POSTs to /run_script and for unexpected child processes of the LMCache process. A successful exploit leaves a Python-level execution trail on a host whose normal behaviour is highly regular GPU serving — anomalies should stand out.
  • Track upstream issue #5510, not the release-candidate tags. Pin remediation to the confirmed fix commit, and re-check the NVD records — both are freshly published and the “Received/Awaiting Analysis” records routinely gain CPE, CWE, and reference updates in the first days.

Verification note: we read the NVD API records for CVE-2026-107204 (published 7 October 2026, CVSS 3.1 9.8 and CVSS 4.0 9.3, CWE-306, source disclosure@vulncheck.com, affected pkg:pypi/lmcache versions 0 through 0.5.5) and CVE-2026-107206 (published 7 October 2026, CVSS 3.1 9.4, unauthenticated multiprocess management-endpoint and environment access) directly, including their reference lists; the VulnCheck advisory for the /run_script description, researcher credits, and affected range; the LMCache GitHub issue #5510 page for the report title; and the LMCache GitHub releases API, which showed only v0.5.6rc3 pre-release tags dated 6 October and no stable fix release. We did not test any LMCache instance and did not attempt exploitation. A third related identifier, CVE-2026-107207, appeared in aggregator listings but had no NVD record we could verify, so we make no claims about it.

Sources: