Reachability Watch: An AI Cache Server That Runs Any Script It’s Sent, and Nearly 440 New CVEs

Most of what this column tracks lives in software security teams already know how to inventory: admin consoles, gateways, CMS plugins. This week’s biggest story sat one layer down, in the plumbing that keeps large language models fast and affordable to run.

LMCache and Mooncake are open-source projects that store and move a model’s KV cache between GPUs and servers. The KV cache is the short-term working memory a model builds while it processes a prompt, and reusing it cuts inference cost and latency. Between them, the two projects disclosed six vulnerabilities this week. Every one is reachable by an unauthenticated attacker over the network, and three describe a service that listens on every network interface by default. They weren’t the only AI workloads in this week’s feed, and the rest of the list followed a familiar shape.

CVEs by the Numbers

For October 2–8, 2026, nearly 440 new network-exploitable CVEs were published. 52 cleared our severity bar (CVSS 8.6+), including 2 rated a perfect 10.0. Here’s what stood out:

• CVE-2026-105135 (10.0, CRITICAL): InternLM’s MindSearch 0.1.0, an open-source AI search agent, contains a code injection flaw in its Planner Agent, reachable through the inputs argument of ExecutionAction.run. The planner decides what the agent does next, which makes it a high-value place for injected code. (The week’s other 10.0, CVE-2026-105134, affects the Replication Receiver API in the AhsayCBS backup server.)
• Seven CVEs in IBM Langflow OSS 1.0.0 through 1.12.2 (CVE-2026-93674, CVE-2026-104334, both 9.8; CVE-2026-93675, CVE-2026-97678, CVE-2026-97655, CVE-2026-97679, CVE-2026-97673, all 8.8): OS command injection, improper control of code generation, dependency confusion, and an incomplete blocklist in the platform’s code security scanner. IBM disclosed all seven on the same day, which lets Langflow teams assess them as one batch.
• Four CVEs in IBM DataPower Gateway (CVE-2026-15762, CVE-2026-14502, CVE-2026-14269, CVE-2026-14992, all 9.8): three buffer overflow flaws, one of which allows remote code execution, plus an authentication flaw where the gateway accepted empty passwords and granted administrative access.
• Three CVEs in UTMStack, fixed in 11.2.16 (CVE-2026-82042, 9.8; CVE-2026-82041, 9.9; CVE-2026-82039, 8.8): A shared internal key, sent in a Utm-Internal-Key header and checked against the INTERNAL_KEY environment variable, unlocks full administrative API access. The /command/{hostname} websocket handler runs commands with no role check or allowlist, and an asset search function accepts injected SQL.
• 15 WordPress plugin CVEs, including four in Super Forms (CVE-2026-15896, CVE-2026-15897, CVE-2026-17609, CVE-2026-17196) and an administrator account takeover in DevKit Pro (CVE-2026-14378) caused by a user-switching handler that trusts an attacker-controlled value.

Most of these flaws need nothing from an attacker beyond a network route to the vulnerable service.

No Login Required: The LMCache Remote Code Execution Flaw (CVE-2026-107204)

The standout is CVE-2026-107204 (9.8) in LMCache through version 0.5.5. LMCache exposes a /run_script endpoint that accepts Python scripts over HTTP and runs them, with no authentication. The advisory describes a way for attackers to recover Python’s real built-in functions from inside a submitted script, which removes whatever limits the endpoint placed on the code it runs. Anyone who can reach that endpoint can execute code on the host.

Two companion flaws widen the exposure. CVE-2026-107206 (9.4) covers the HTTP server LMCache runs in multiprocess mode, whose management endpoints listen on all network interfaces by default with no authentication. CVE-2026-107205 (8.6) covers the multiprocess coordinator’s fleet control API, which ships with the same default.

Mooncake’s three disclosures follow the same design. Its Store REST service binds to 0.0.0.0 with no authentication on any route (CVE-2026-106037, 9.8). Its HTTP metadata server lets unauthenticated callers read, overwrite, and delete transfer engine metadata (CVE-2026-103765, 9.4). Before version 0.3.13, its transfer engine’s TCP data port allowed unauthenticated reads and writes of process memory (CVE-2026-103764, 9.8).

An inference cache runs next to the GPUs, holds data derived from the prompts a model is serving, and shares a network with the model servers. Code execution there gives an attacker a foothold in the most expensive and most sensitive part of an AI deployment.

Open-source AI infrastructure tends to ship with defaults tuned for a single trusted cluster, where every machine belongs to the same team. In that setting, a management API on every interface saves setup time. On a shared production network, the same default makes the service reachable by anything that can route to it. Both projects disclosed these issues publicly, which gives the teams running them what they need to act.

How Vulnerability Cloaking Keeps AI Cache Servers Off the Network

Identity-First Reachability™ changes the order of operations. A service becomes reachable only after the caller proves its identity and a policy allows that specific connection. NetFoundry’s Vulnerability Cloaking applies that model to services that can’t be patched today: the service exposes no listening port to the network and accepts connections only from identities authorized to reach it.

Had LMCache’s /run_script endpoint been behind Vulnerability Cloaking, the exploit would have had nowhere to land. The flaw would still exist in the code until a fix shipped. An attacker scanning the network, though, would find no port to send a script to. The model servers that need the cache would reach it as individual non-human identities, each scoped by policy to the connections it actually needs. The same protection covers Mooncake’s metadata server and Store REST service, and every management API this week that defaulted to all interfaces.

How to Take AI Inference Infrastructure Off the Network Before the Next Disclosure

Patching remains the fix for every CVE on this list. Patching also runs on a schedule, and AI teams add new serving components every quarter, each with its own defaults. Nearly 440 new network-exploitable CVEs in one week is more than any team can patch through on time.

A service that no unauthorized identity can reach can wait for its patch without becoming an incident.

NetFoundry built that model on OpenZiti, the open-source Zero Trust networking platform our team created, to give machine workloads like model servers, caches, and AI agents identity-based connections with no open inbound ports.

See how NetFoundry Vulnerability Cloaking makes unpatched systems unreachable before a CVE ever becomes a KEV.

See How It Works →

---

Frequently Asked Questions

What is a KV cache, and why does an AI cache server need its own security?

A KV cache is the short-term memory a large language model builds while it processes a prompt. Caching layers store and reuse that memory across requests, which makes inference faster and cheaper. Because a cache server holds data derived from user prompts and sits on the same network as the model servers, an attacker who controls it gains access to sensitive data and a path into the rest of the AI deployment.

Why do AI infrastructure tools ship with services open to the whole network?

Many open-source AI tools are designed for a single trusted cluster, where every machine belongs to one team and convenience matters more than access control. Listening on all network interfaces makes setup easy in that environment. When the same tool moves into a shared production network, that default exposes management and data endpoints to anything that can route to them.

What does “network-exploitable” mean in a CVE listing?

A network-exploitable CVE is a vulnerability an attacker can trigger remotely, over a network connection, without physical access to the machine. In CVSS scoring, this shows up as an attack vector of “Network.” These flaws matter most because the only thing an attacker needs is a route to the vulnerable service.

What is Vulnerability Cloaking?

Vulnerability Cloaking is a security approach that hides a vulnerable service from the network so attackers can’t reach it, even before a patch is applied. NetFoundry delivers it by removing the service’s exposed listening ports and allowing connections only from verified identities with explicit policy permission. We built it for systems that can’t be patched immediately, including AI infrastructure that changes faster than patch cycles.

How does Identity-First Reachability prevent unauthenticated remote code execution?

Identity-First Reachability is a security model where every connection requires a verified identity and an explicit policy decision before a service becomes visible on the network. At NetFoundry, this means an unauthenticated attacker never gets a network path to the vulnerable endpoint at all. A flaw like an open script endpoint stays in the code, but no unauthorized caller can send it a request.