SearchSubscribe

P.K. SHARMA

Cyber security intelligence, AI governance, practitioner analysis

AI Security

LMCache's 9.8 flaw has no fixed release, and the project's own Kubernetes example listens on every interface

The decode path JFrog calls exploitable has shipped in LMCache since 29 October 2025, 343 days (derived), and no fixed release exists at about 18:00 BST on 7 October. The 9.8 applies only where the server is reachable from other machines, a case the project's own Kubernetes example sets up.

By Parminder Kumar Sharma · · 20 min read

A dark server room with one equipment rack holding four black GPU servers under a flat network switch. One orange cable runs from a single switch port down the front of the rack and into a server, and a grey flight case stands beside the rack. There is no lettering and nobody in the room.

343 days of releases, no fixed one, and a 9.8 that turns on one setting

The code path that JFrog calls exploitable has shipped in LMCache since version 0.3.9 on 29 October 2025, which is 343 days before 7 October 2026 (derived). The CVE record lists every version from 0.3.9 onward as affected, and PyPI lists 24 final and post releases between 0.3.9 and 0.5.5 (derived count). The newest, 0.5.5 of 12 September, is 25 days old (derived). At about 18:00 BST on 7 October no release without the flaw exists: JFrog's advisory says the 0.5.6 release candidates through rc3 and the dev branch still carry it, and the file on dev had not changed since 28 August when we read it. The flaw is CVE-2026-105192. JFrog, which found it, is also the CVE's assigner and scored it 9.8 out of 10.

What that does not establish. It does not say an attacker can reach your LMCache. JFrog states that the 9.8 is for the case where the multi-process server is bound to a routable address, and that a stock single-host install on the default bind is not reachable from other machines. The CVE record's own score scenario says the same. It does not say anyone is exploiting it: CISA's Known Exploited Vulnerabilities (KEV) catalogue, version 2026.10.04 with 1,734 entries, does not list it, and we found no report of exploitation. It does not say the maintainers have refused a fix: no public reply exists either way, and JFrog's page gives no report date, so how long they have known is not stated. And "unpatched" is a statement about a clock. The project is active, with changes merged on 6 October and nightly builds published on 7 October, so a fix could land at any hour.

Why it still matters. The default bind keeps the port off the network, and the project's own Kubernetes example is not the default. That example starts the server bound to every network interface on the host network, and the project's Kubernetes guidance describes that arrangement. The Hacker News said so on 7 October; we read the manifest ourselves. The same afternoon, four more LMCache CVEs were published for other network services in the same project. This briefing is about the gap between a score that depends on one setting and a reference deployment that sets it.

The flaw in one sentence, and where it applies

In multi-process mode LMCache accepts messages from the network with no authentication and passes part of one message type to Python's pickle, a format that runs code as it is read, so anyone who can send it a message can run code as the user of the LMCache process. The CVE record classes this as deserialisation of untrusted data (CWE-502) and missing authentication (CWE-306). We print no payload, no message layout and no code, and the saved copy of JFrog's page in our files has its reproduction steps removed.

Multi-process mode, which JFrog also calls distributed mode, runs LMCache as a standalone service that vLLM reaches over the network. The project's docs describe one server per node serving several vLLM pods, with ZeroMQ as the default transport and a gRPC option, and two entry points, the recommended lmcache server command and a legacy module, which share one core. In the dev branch's configuration code the request server's default host is localhost, its default port is 5555 and its default transport is ZeroMQ. JFrog says LMCache used only inside a vLLM process does not open this port. So the exposed population is every deployment that runs the standalone server with a bind address other than localhost, and nobody else.

Position at about 18:00 BST on 7 October 2026. Stated: the JFrog advisory, the CVE record, NVD, the LMCache repository and docs. Not stated: what those sources do not say, which we checked for.

  1. Item
    Affected versions
    Stated
    CVE record: 0.3.9 onward. JFrog: still present in the latest PyPI release 0.5.5, in 0.5.6 release candidates through rc3, and on dev as of 7 October.
    Not stated
    Whether the gRPC transport avoids the flaw. JFrog's title and the record name the ZeroMQ transport only.
  2. Item
    Fix
    Stated
    JFrog: "No fixed release is available as of 2026-10-07." We found no release, advisory, issue or pull request about it at about 17:50 BST.
    Not stated
    A fix date, a plan, or any maintainer statement.
  3. Item
    Severity
    Stated
    9.8, CVSS 3.1, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, assigned by JFrog as the CNA, for a multi-process server bound to a routable address, which is the scenario the record states. NVD: Deferred, JFrog's score listed as Secondary.
    Not stated
    A vendor rating, an NVD score, or a score for a localhost-only deployment.
  4. Item
    Default exposure
    Stated
    JFrog and the code: bind defaults to localhost. In-process LMCache opens no port.
    Not stated
    How many deployments set a routable bind. No source counts them.
  5. Item
    Exploitation
    Stated
    Not in KEV (2026.10.04). No report found. JFrog's page carries reproduction steps, so assume the knowledge is public.
    Not stated
    Whether anyone is scanning for the port. The advisory lists no indicators of compromise.
  6. Item
    Timeline
    Stated
    CVE reserved 4 October 11:50 UTC, published 7 October 09:40 UTC, 3 days (derived). JFrog's page is dated 7 October.
    Not stated
    When JFrog reported it, when LMCache replied, whether a disclosure period was agreed.

The mistake is not new. Oligo Security's ShadowMQ research, published on 13 November 2025, described the same pattern, pickle over an unauthenticated ZeroMQ socket, in other inference servers and said the code had been copied between projects. The Hacker News notes that whether LMCache's code shares a source with them has not been established, and we found nothing that establishes it either.

The default keeps the port off the network. The reference deployment does not use it.

The repository's example DaemonSet, which the project's deployment guide tells Kubernetes users to apply, starts the multi-process server with the host set to every interface, on port 6555 rather than the 5555 default, on the host network, from a floating "nightly" image tag, with the node's shared-memory directory mounted from the host. It was added on 19 December 2025 and last changed on 4 February 2026 (292 days since it was added, derived). The guide says the DaemonSet uses host networking so that vLLM pods find the server through the node's address, and the example vLLM deployment connects to the server at the node's address on that port. The configuration reference's full example also sets the host to every interface. Its Docker example uses host networking and leaves the host at its default.

Our inference, not a source's statement. In the guide's Kubernetes pattern the vLLM pods sit on the pod network and reach the server through the node's address, which a localhost bind could not serve. An operator who follows that pattern is therefore likely to be in the routable-bind case that JFrog scores 9.8. The configuration reference's entry for the HTTP admin port warns that it has no authentication and should only be bound beyond loopback on a trusted network. Its entry for the request server's host, which is the vulnerable port, carries no such warning in the text we read. We did not run the example, and we did not test whether the legacy entry point it names opens the same transport; by the docs all entry points share one core with ZeroMQ as the default.

A vertical flow in five steps. Any host that can open a connection reaches the transport port, 5555 by default or 6555 in the project's examples. The one control is who can connect: the default localhost bind cuts the path, while a routable bind, as in the Kubernetes example, lets any host through. Then an unauthenticated ZeroMQ socket, unsafe deserialisation, and code running as the LMCache user, root on official images per JFrog. What an attacker could reach next is not stated.
Drawn from the JFrog advisory, the CVE record and the LMCache example manifest and docs, read 7 October 2026. No payload or message structure is shown.

The friendly name. "Default bind: localhost" reads like a control. It is a default, and a default describes the install nobody has changed. It also still lets any process on the same machine connect (our inference), so it is a reduction, not a boundary. The risk sits with the operator who needed two machines to talk to each other, and the project's own guide shows how that is done. JFrog also says a firewall limits who can reach the port but removes nothing: any host that can still open a connection can run code.

What the repository shows about a fix

Method and interest. JFrog sells a software supply-chain platform with security scanning for software and AI artifacts (its own homepage), found this flaw, is the CVE's assigner and scored it. That is how CNA scoring works and not a reason to doubt the finding, but it means the 9.8 and its stated scenario come from the finder and not from the vendor or NVD. NVD had not scored it when we read it.

Read 7 October 2026 between about 17:46 and 17:55 BST from the GitHub API and web pages, PyPI's JSON feed and the JFrog advisory.

  1. Where
    Latest release
    What we read
    v0.5.5, GitHub 12 September 21:07 UTC, PyPI 23:27 UTC. Marked latest on GitHub; PyPI's current version.
    What it does not show
    A fix. The CVE record lists it as affected.
  2. Where
    Release candidates
    What we read
    v0.5.6rc1 (26 September), rc2 (28 September), rc3 (6 October), marked pre-release on GitHub.
    What it does not show
    A fix. JFrog says rc3 still carries the call.
  3. Where
    Dev branch
    What we read
    The file JFrog names last changed on 28 August 2026. Newest commits are dated 6 October. No pull request or issue we could find mentions the CVE or JFrog.
    What it does not show
    Anything not yet public. A private fix is possible and would not show.
  4. Where
    Security advisories page
    What we read
    The repository's advisories page lists none published (about 17:48 BST).
    What it does not show
    Whether the maintainers have been told.
  5. Where
    Security policy
    What we read
    SECURITY.md asks reporters to email the team.
    What it does not show
    Whether JFrog did, when, or what came back.

One security change is on record, and it is not a response to JFrog. On 23 September a contributor's pull request (#5129) was merged: it turns the script-execution endpoint off by default and binds the admin HTTP servers to localhost by default, because, its text says, neither server authenticates requests. It is in the 0.5.6 release candidates and not in 0.5.5. It pre-dates the six GitHub reports of 6 October by 13 days (derived) and does not touch the ZeroMQ transport. The project merges security hardening, then. Whether it will do so for this flaw, and how soon, is not stated.

One CVE in the headline, five LMCache CVEs by the afternoon

The Hacker News reported that a single GitHub account opened six more LMCache security reports on 6 October, with no CVE and no maintainer confirmation. We read the six. At 15:24 UTC on 7 October (16:24 BST) VulnCheck, a CNA that sells vulnerability intelligence, published four CVEs whose records each cite one of those issues, so that description is out of date for four of them. The other two, a standalone TCP cache server (issue 5507) and a prefill-decode transfer backend (issue 5509), had no CVE in NVD's keyword search at 17:49 BST. All six issues are open with no labels and no assignee. The only replies are three comments from one contributor asking to be assigned; none is from a maintainer.

CVE records read through the CVE Services API at about 17:49 BST on 7 October 2026, assigner VulnCheck for all four. Issue numbers are those each record cites. Scores are VulnCheck's.

  1. CVE and issue
    CVE-2026-107204, issue 5510
    What the record says
    Code execution through a script endpoint on the HTTP admin surface, up to 0.5.5. The reporter says it needs the internal API server enabled, which is off by default. The CVE text omits the condition.
    CVSS 3.1 and 4.0
    9.8 critical; 9.3
  2. CVE and issue
    CVE-2026-107205, issue 5508
    What the record says
    No authentication on the multi-process coordinator's fleet control API, listening on all interfaces by default. Can disrupt caching and disclose placement metadata.
    CVSS 3.1 and 4.0
    8.6 high; 8.8
  3. CVE and issue
    CVE-2026-107206, issue 5511
    What the record says
    No authentication on the multi-process HTTP server's management API. Can read environment credentials and configuration, clear caches, change tenant quotas.
    CVSS 3.1 and 4.0
    9.4 critical; 8.8
  4. CVE and issue
    CVE-2026-107207, issue 5512
    What the record says
    Frontend monitoring service lets an unauthenticated caller register hosts and reach internal ones, a server-side request forgery.
    CVSS 3.1 and 4.0
    7.2 high; 6.9

Three points. First, VulnCheck's own advisory page rates the third entry high at 8.8, its version 4 score, while its CVE record carries 9.4 critical under version 3.1: one assigner, one flaw, two labels (our earlier briefing on two official scores covers why this happens). Second, CISA's enrichment on the third entry, added at 16:12 UTC, records exploitation as poc, meaning a public proof of concept, with automatable marked yes. That is not a report of attacks. Third, all four say "through 0.5.5". The 0.5.6 release candidates change two defaults on these surfaces, per the 23 September commit, and add no authentication. Whether a release candidate counts as fixed is not stated by any record, and no stable release carries the change.

For an operator, the point is practical. Anyone who ran 0.5.5 or earlier in multi-process mode has at least two kinds of port to find: the ZeroMQ transport, and HTTP surfaces that in 0.5.5 bound all interfaces by default. We confirmed that default in the 0.5.5 code. The first needs a routable bind to be reachable, the second, in 0.5.5, did not.

The vLLM advisory is a different flaw

The vLLM advisory the pointer mentions, GHSA-2823-qmq8-rwvj, is CVE-2026-105756. It is a denial of service in vLLM: before version 0.30.0, a single request with a malformed cache-salt value could crash the engine on deployments that use vLLM's built-in LMCache multi-process connector. GitHub scores it 6.5 medium (availability only). vLLM 0.30.0 was released on 22 September, the advisory was published on 23 September and the CVE on 5 October. It is fixed in vLLM, and it does not touch the LMCache flaw, which vLLM's release cannot fix. What it does show is that vLLM ships a connector for LMCache's multi-process mode (the advisory gives lmcache 0.4.4 or later), so the integration is real and the two projects' fixes are separate jobs.

Who runs it, and what can be counted

LMCache describes itself as a KV cache layer for LLM inference, licensed Apache-2.0. Its README says its development is supported in part by Tensormesh, its news items mention vLLM and NVIDIA Dynamo integrations, and it says it is becoming the de-facto standard for KV cache management, which is the project's own claim, not a measurement. What we could count, read on 7 October: the repository showed 11,970 GitHub stars and 1,987 forks (17:47 BST), and pypistats.org showed 53,581 PyPI downloads in the last month and 12,782 in the last week (17:51 BST). Downloads include automated builds and are not deployments, and stars are not either. No source we found counts how many deployments run multi-process mode, or how many set a routable bind.

UK reading, as inference. LMCache matters to organisations that run their own GPU inference: AI start-ups and labs, university research computing, and public bodies and NHS or council teams piloting self-hosted models, plus any managed AI platform that bundles it. We found no UK-specific figure. The shared-cluster case deserves a thought: JFrog's advice is to keep the port on localhost or on a trusted cluster network, and on a university or multi-tenant research cluster every other user's job may be a peer on that network.

The UK reading: the 14-day clock has not started, but the firewall and configuration controls apply

Cyber Essentials. Requirements for IT Infrastructure v3.3 (April 2026), page 17, requires in-scope software to be updated within 14 days of release where the update fixes critical or high flaws, addresses a CVSS v3 base score of 7 or more, or comes with no detail of severity. Its stated aim, on page 16, is that software is not vulnerable to known issues for which fixes are available. With no fixed release, there is nothing to install, so on our reading the 14 days has not started. It starts on the day a fixed release ships, and a release fixing a 9.8 flaw would fall under the second condition. The same page requires software to be licensed and supported. Whether a community open-source project counts as supported is not defined in the text we read, so ask your certification body. That is our reading, not an assessor's ruling.

What Cyber Essentials does ask now, whether or not a patch exists: the firewall control (page 14) says to block unauthenticated inbound connections by default and to have each inbound rule approved and documented with its business need. The secure configuration control (page 15) says to remove or disable unnecessary software, including network services, and to ensure users are authenticated before they reach organisational data or services. And cloud services holding your services cannot be excluded from scope (page 7), so rented GPU instances count. An unauthenticated port open to a flat network is a firewall and configuration finding today.

The NCSC. Its update-by-default guidance (version 2.1, reviewed 1 May 2026) gives five days for internet-facing software once an update exists. Its triage guidance covers exactly this case, where no update exists yet: sort each finding into fix, acknowledge or investigate, record a date, and treat any temporary mitigation as time-bounded and tracked until the full remediation is applied. Its principle on owning the risk says the decision not to update is a senior-level risk decision, to be recorded with its reasons, and that decisions should not rest on a single severity score such as CVSS. That fits here, where the same flaw is 9.8 on a routable bind and not reachable on the default.

The DSIT Code of Practice for the Cyber Security of AI (published 31 January 2025, voluntary) asks developers and system operators to keep an inventory that includes connectivity (provision 5.1), to evaluate access control for the infrastructure (6.1), and, for developers, to have contingency plans where updates cannot be provided (11.1.1). It says it is not designed for academics testing AI systems purely for research, so a research cluster may fall outside the Code and still inside Cyber Essentials. An operator running a service on LMCache is, on our reading, a system operator. The ICO expects a notifiable personal data breach to be reported within 72 hours of becoming aware of it, where feasible. An inference host handles prompts, which can contain personal data. If a reachable LMCache host may have been compromised, the clock runs from when you become aware, not from the CVE date.

We have written about the same shape before: a self-hosted AI gateway where only self-hosted users must patch, and an exploited flaw with no fixed build in any branch, where the work was also to restrict reach while waiting. On the same day, a botnet report showed exposed AI services being taken over for mining: PoeLLM hides its address in a poem, but the LiteLLM flaw Lumen names was fixed 177 days before its report.

What to do, in the order worth doing it

Our judgement on the order, not a standard. The first three steps establish whether you are exposed at all, which is what the 9.8 turns on.

Take this with you

If your organisation runs LMCache, or an AI platform that might include it

  • Find every LMCache deployment, including ones inside vendor stacks. Look for the lmcache package in Python environments and container images, the lmcache/standalone and lmcache/vllm-openai images, DaemonSets that run an LMCache server, and vLLM start-up settings that name an LMCache connector. Record an owner for each.
  • For each, find out whether multi-process mode is on. LMCache running only inside a vLLM process opens no transport port, per JFrog. A standalone LMCache server, a per-node DaemonSet or the lmcache server command means the port exists. Record the transport (ZeroMQ is the default) and the bind address it was given.
  • Test reachability from the other side. From a host that should not be a peer, such as an ordinary workstation, another team's node or a different namespace, check whether a TCP connection to the LMCache port is accepted (5555 by default, 6555 in the project's examples). A refused or timed-out connection is the result you want. Send nothing to the port and test only hosts you own.
  • Cut the path. Allow connections only from the serving hosts that need them, and keep the port off the internet and out of shared cluster namespaces. If the server is on the host network, as in the project's example, do not rely on a pod-level network policy alone: Kubernetes documents policy behaviour for host-network pods as undefined, and the common result is that they are treated as traffic to the node. Add a node firewall, a cloud security group, or a rule on the serving nodes' address range. Where you control the bind address, give it a specific private interface address, not every interface.
  • If one host serves everything, leave the bind at localhost, or run LMCache inside the vLLM process, which JFrog says opens no port. The trade is that you lose the sharing and process isolation that multi-process mode exists for.
  • Shrink what a compromise could reach. JFrog says the official images run LMCache as root, and the project's Dockerfiles we read carry no USER instruction. In images you build, run as a non-root user, drop capabilities, mount no credentials into the pod, and restrict outbound connections. The project's example also mounts the node's shared-memory directory from the host, so check what that exposes.
  • Find the other ports. Four CVEs published on 7 October concern HTTP surfaces: the admin server, the coordinator and a frontend. In 0.5.5 and earlier the admin server bound all interfaces by default. Confirm each is on loopback or behind an allow-list, and that the internal API server and the script endpoint are not enabled.
  • Look for evidence the advisory does not give. JFrog lists no indicators of compromise. For any host whose port was reachable, review unexpected child processes of the LMCache process, unexpected outbound connections, and flow-log connections to its port from hosts that are not serving nodes, back to when the bind was opened.
  • Name one person to watch for the fix, and write down what they watch: the project's releases page, its security advisories page, PyPI, and the five CVE records. Check daily until a fixed release appears. Agree in advance who tests and who deploys, so the NCSC's five days for internet-facing software and Cyber Essentials' 14 days can be met once a release exists.
  • Record the decision. Until a fix exists the control is the network restriction. Write down the mitigation, its owner and a review date, make it time-bounded, and have a senior owner accept the remaining risk, as the NCSC's triage and risk-ownership guidance asks.
  • If a host that held prompts may have been reached, treat it as a possible personal data breach until shown otherwise, and note when you became aware. The ICO's 72 hours runs from then.

The question that exposes the gap

Your platform team says the cache sits on an internal network. Has anyone tried to open a connection to its port from a machine that is not a serving node, and written down what happened?

Key facts

Sources

  1. PrimaryJFSA-2026-001694382, published 7 October 2026, read in full at about 17:47 BST: affected versions, the 9.8 and the routable-bind scenario, no fixed release as of 2026-10-07, the default bind, the in-process exception, the root user on official images, and the mitigation advice. Its reproduction steps were read and are not reproduced anywhere in this briefing. JFrog sells a software supply-chain platform and is the CNA that scored its own finding.JFrog Security Researchaccessed 2026-10-07
  2. PrimaryCVE record for CVE-2026-105192 read through the CVE Services API at 17:46 BST on 7 October 2026: assigner JFrog, reserved 4 October 11:50 UTC, published 7 October 09:40 UTC, affected 0.3.9 onward, CVSS 3.1 9.8 with the routable-bind scenario, CWE-502 and CWE-306, timeline entry for 0.3.9 on 29 October 2025.CVE Programaccessed 2026-10-07
  3. PrimaryNVD record for CVE-2026-105192 read at 17:46 BST on 7 October 2026: status Deferred, JFrog's 9.8 listed as Secondary, no NVD score. A keyword search for LMCache at 17:49 BST returned seven records.NIST NVDaccessed 2026-10-07
  4. PrimaryKnown Exploited Vulnerabilities catalogue, version 2026.10.04, released 4 October 2026 at 18:52 UTC, 1,734 entries, read at 17:46 BST on 7 October 2026. None of the five LMCache CVEs is listed.CISAaccessed 2026-10-07
  5. PrimaryLMCache repository security advisories page, read at about 17:48 BST on 7 October 2026: no published security advisories.GitHub (LMCache)accessed 2026-10-07
  6. PrimaryLMCache releases, read through the GitHub API at 17:47 BST: v0.5.5 marked latest, published 12 September 2026 21:07 UTC; v0.5.6rc1 to rc3 marked pre-release (26 September, 28 September, 6 October); nightly builds on 7 October.GitHub (LMCache)accessed 2026-10-07
  7. Primarylmcache on PyPI, read through the JSON feed at 17:47 BST: current version 0.5.5 (12 September 2026), 24 final and post releases from 0.3.9 (29 October 2025) to 0.5.5, 0.5.6rc3 uploaded 6 October 23:33 UTC.PyPIaccessed 2026-10-07
  8. PrimaryRecent PyPI downloads for lmcache read through the API at 17:51 BST on 7 October 2026: 53,581 in the last month, 12,782 in the last week. Downloads are not deployments.pypistats.orgaccessed 2026-10-07
  9. PrimaryLMCache repository and README, read at 17:47 BST on 7 October 2026: Apache-2.0, 11,970 stars, 1,987 forks, support from Tensormesh, the project's own description as a vendor-neutral KV cache layer, and SECURITY.md asking reporters to email the team.GitHub (LMCache)accessed 2026-10-07
  10. PrimaryThe project's example DaemonSet for multi-process mode, read on dev at 17:48 BST: server host 0.0.0.0, port 6555, host network, floating nightly image tag, node shared-memory directory mounted. Added 19 December 2025, last changed 4 February 2026.GitHub (LMCache)accessed 2026-10-07
  11. PrimaryMulti-process deployment guide, read on dev: the DaemonSet and Deployment pattern, host networking so vLLM pods find the server through the node's address, and the Docker example with host networking.LMCache project docsaccessed 2026-10-07
  12. PrimaryMulti-process configuration reference, read on dev: the request server host defaults to localhost and port to 5555, the HTTP admin host warning about no authentication, and a full example with host 0.0.0.0 and port 6555.LMCache project docsaccessed 2026-10-07
  13. PrimaryMulti-process mode overview, read at 17:48 BST: one server per node serving several vLLM pods, ZeroMQ by default or gRPC, the recommended and legacy entry points sharing one core.LMCache project docsaccessed 2026-10-07
  14. PrimaryMulti-process configuration code read at v0.5.5, v0.5.6rc3 and dev: transport zmq, host localhost and port 5555 by default; the HTTP admin host default was 0.0.0.0 in 0.5.5 and 127.0.0.1 in 0.5.6rc3 and dev.GitHub (LMCache)accessed 2026-10-07
  15. PrimaryPull request 5129, merged 23 September 2026 (commit 449b94c17f): disable the script endpoint and bind the admin HTTP servers to localhost by default. Not a response to JFrog.GitHub (LMCache)accessed 2026-10-07
  16. PrimaryIssue 5507, opened 6 October 2026 by a single account: unauthenticated access to a standalone TCP cache server. Open, no labels, no assignee, no comments. No CVE found. Proof-of-concept material in the issue was not reproduced.GitHub (LMCache)accessed 2026-10-07
  17. PrimaryIssue 5508, opened 6 October 2026: unauthenticated coordinator control plane. Cited by CVE-2026-107205. Open, no labels, no assignee, no comments.GitHub (LMCache)accessed 2026-10-07
  18. PrimaryIssue 5510, opened 6 October 2026: script endpoint escape. The reporter says it needs the internal API server enabled, which is off by default. Cited by CVE-2026-107204. One comment, from a contributor asking to be assigned.GitHub (LMCache)accessed 2026-10-07
  19. PrimaryCVE-2026-107204, assigner VulnCheck, published 7 October 2026 15:24 UTC; CVSS 3.1 9.8 and 4.0 9.3. The records for CVE-2026-107205 (8.6; 8.8), CVE-2026-107206 (9.4; 8.8, with a CISA-ADP entry recording exploitation as poc at 16:12 UTC) and CVE-2026-107207 (7.2; 6.9) were read the same way at about 17:49 BST.CVE Programaccessed 2026-10-07
  20. PrimaryVulnCheck advisory for CVE-2026-107206, 7 October 2026, rated high at 8.8 on its page (CVSS 4.0) against 9.4 in the CVE record (CVSS 3.1). The other three VulnCheck advisories for CVE-2026-107204, 107205 and 107207 were read as well. VulnCheck sells vulnerability intelligence.VulnCheckaccessed 2026-10-07
  21. PrimaryGHSA-2823-qmq8-rwvj, CVE-2026-105756: a denial of service in vLLM before 0.30.0 on deployments using the built-in LMCache multi-process connector; 6.5 medium; published 23 September 2026, CVE published 5 October. A different flaw from CVE-2026-105192.vLLM project (GitHub)accessed 2026-10-07
  22. PrimaryvLLM releases read through the GitHub API: v0.30.0 published 22 September 2026.vLLM project (GitHub)accessed 2026-10-07
  23. PrimaryShadowMQ: How Code Reuse Spread Critical Vulnerabilities Across the AI Ecosystem, 13 November 2025: pickle over unauthenticated ZeroMQ sockets in other inference servers. Used only to show the class is not new.Oligo Securityaccessed 2026-10-07
  24. PrimaryJFrog homepage, read at about 18:00 BST on 7 October 2026, for the description of its software supply-chain platform and its scanning of software and AI artifacts. Used only for the note on commercial interest.JFrogaccessed 2026-10-07
  25. PrimaryCyber Essentials: Requirements for IT Infrastructure v3.3, April 2026, read in full: security update management (printed pages 16 and 17), firewalls (page 14), secure configuration (page 15) and cloud scope (page 7).NCSCaccessed 2026-10-07
  26. PrimaryVulnerability management, 1. Put in place a policy to update by default, version 2.1, reviewed 1 May 2026: five days for internet-facing software, seven for operating systems and applications, 14 for internal.NCSCaccessed 2026-10-07
  27. PrimaryVulnerability management, 4. Carry out assessments by triaging and prioritising: the triage process where no update exists yet, fix, acknowledge and investigate, and time-bounded mitigations.NCSCaccessed 2026-10-07
  28. PrimaryVulnerability management, 5. The organisation must own the risks of not updating: a senior-level risk decision, recorded, and not based on a single severity score.NCSCaccessed 2026-10-07
  29. PrimaryCode of Practice for the Cyber Security of AI, published 31 January 2025, voluntary: provisions 5.1, 6.1 and 11.1.1 and the scope note on research use.DSITaccessed 2026-10-07
  30. PrimaryPersonal data breaches: a guide, read on 7 October 2026: report within 72 hours of becoming aware, where feasible.ICOaccessed 2026-10-07
  31. PrimaryNetwork Policies, read on 7 October 2026: NetworkPolicy behaviour for hostNetwork pods is undefined, most often treated as node traffic, and an ipBlock rule can allow it.Kubernetesaccessed 2026-10-07
  32. Reported byUnpatched Critical LMCache Flaw Lets Unauthenticated Attackers Run Code Remotely, 7 October 2026. The news pointer. It says the project's Kubernetes example binds every interface and describes six unconfirmed GitHub reports with no CVE; we read the manifest ourselves, and four of the six had CVEs by the afternoon.The Hacker Newsaccessed 2026-10-07

Share this briefing

Know someone who owns this problem? Send it to them.

LinkedInXWhatsAppEmail

Related briefings

The briefing, in your inbox

Practitioner analysis of cyber and AI security news. No vendor noise.

How often

Every new briefing in one email, at 7am, or at 7am, 12:30pm and 6pm. Nothing is sent when nothing is new. Unsubscribe any time.