Six CVEs landed against vLLM overnight, all in the prefill/decode disaggregated KV-transfer path, five of them at 8.7 on CVSS v4. v0.30.0 shipped five hours later and closes none of them — the code the advisories point at is still there, at new line numbers. If you serve vLLM single-node with no KV connector configured, none of this reaches a request path; if you run disaggregated P/D over NIXL, Mooncake or P2P offloading, the whole batch is live.

Worth your morning

vLLM — six CVEs, and a release that does not clear them. VulnCheck filed the batch at 00:30 UTC: CVE-2026-94622 and CVE-2026-94623 in the NIXL connector, CVE-2026-94624 in P2P KV offloading, CVE-2026-94625 and CVE-2026-94627 in the Mooncake connector, and CVE-2026-94626 on an unbounded tp_size. Five score 8.7 under CVSS v4 and 7.5 under v3.1; the Mooncake placeholder leak scores 6.9 and 5.3. All six are availability-only — the failure mode is a decode worker that dies or starves, not disclosure.

Every record says "through 0.29.0". v0.30.0 published at 05:20 UTC this morning, and its own Security section lists four ROCm dependency bumps. The six remediation PRs — 51137, 49796, 51236, 51504, 51505 and 54807, opened between July 25 and September 1 — are all still open. Checked at the source rather than inferred: in v0.30.0, nixl/metadata.py still pulls remote_block_ids, remote_engine_id, remote_host and remote_port out of kv_transfer_params with bracket access and no guard, and tp_size still arrives via .get("tp_size", 1) with no upper bound. Upgrade to 0.30.0 for everything else in it — 772 commits' worth — but do not read the version range as a fix.

Scope is what to check first. All six sit in the disaggregated prefill/decode path, so a single-process server with no KV connector does not expose them. And none carries a package mapping — the vulnerabilities array is empty on all six records — so nothing in the PyPI feed will raise these against your lockfile. You will find them only by reading the CVEs.

FalkorDB — the fix exists, is verified, and lives in an engine you cannot install. Seven CVEs against the GraphRAG store (6.2k stars, GraphBLAS underneath): CVE-2026-88409 at 8.8 in the GraphBLAS container decode, 88406, 88407 and 88411 at 7.5, 88410 at 7.1, 88408 at 6.5, 88412 at 5.3. All seven are availability or integrity problems reachable through a GRAPH.* command. The underlying reports date from early August.

Five of the seven were closed on August 17 with the same sentence — fixed in the Rust engine — and the maintainer's own closing comments record that the C engine still reproduced. Issue #2326 is still open, carrying an August 22 triage that says the same thing. The seventh, the GRAPH.EFFECT error-handling flaw at 7.5, references no tracking issue at all, so there is nothing public to read its status from. The Rust engine is main and the edge image. The newest tag is v4.20.6, which is two commits and thirteen files off v4.20.4, and whose release notes cover a count(*) miscount and an index-population hang. The advisories bound the range at 4.20.4 because that was current when the reports were tested, not because 4.20.5 fixed anything — so a scanner comparing the range against an installed 4.20.6 will report you clear.

Until the rewrite ships, the control is the network. FalkorDB is a Redis module: keep the port off anything untrusted, and keep graph.UDF to callers you have a reason to trust.

gray-matter — 7.1 million downloads a week, no patch, no maintainer. CVE-2026-78847 is unscored and lands against all versions of the front-matter parser. The optional JavaScript engine evaluates js and javascript front matter, and the document names which engine parses it — options.language only sets the default. If your pipeline reads markdown you wrote, this is nothing. If it ingests markdown from a docs crawl, a RAG corpus or user uploads, the input chooses the parser.

No patch is coming. 4.0.3 has been current since 2019, the last commit to the repo was June 2025, #112 has been open since 2020, and #182 — titled, plainly, Remove RCE-vulnerable JavaScript engine — since March. The fix is at your call site: pass an engines object that overrides the js and javascript keys, since options.engines merges over the defaults.

Collection notes. GitHub's reviewed feed restarted on Sunday afternoon after sixty-one hours dark, and published five Go-ecosystem advisories — three against nginx-ignition, one Falco rules gap, one Hatchet OAuth flaw. None touches this stack; the newest reviewed npm advisory is still September 18 and the newest reviewed PyPI and NuGet advisories are September 18 and 17. A repository sweep across 38 tracked AI projects returned nothing published since September 19 — not from Ollama, llama.cpp, LangChain, LangGraph, LlamaIndex, Haystack, LiteLLM, Dify, Langflow, Flowise, Open WebUI, n8n, CrewAI, ComfyUI, LMDeploy, SGLang, Triton, Jupyter Server, wandb, transformers, Gradio, AutoGen, Semantic Kernel, the MCP reference servers, the Python, TypeScript or Rust MCP SDKs, the Anthropic or OpenAI SDKs, or any tracked vector database. vLLM's own advisory list carries none of this morning's six.

On the Venicecom side there is nothing to apply. Microsoft revised the September document overnight at 01:01 UTC — now 346 products and 1,996 vulnerabilities, 272 of them touching entries revised since Friday — and an anchored filter across .NET, ASP.NET Core, Visual Studio and the Azure AI services matches none of them. The revisions are Azure Linux 3.0 package mirrors, 188 of the 272 against a single kernel build. The August document was also revised, at Sunday 07:00 UTC, and there the anchored filter does hit once: CVE-2026-62871, a 7.8 .NET elevation of privilege on .NET 8.0 and 9.0 on Windows plus Visual Studio 2022 17.14 and 2026 18.8. Revision 2.1 reads "Updated an acknowledgement. This is an informational change only." It was published on August 11 with an official fix, is not publicly disclosed and is not exploited. If it shows up in a feed this morning, it is a credit change on a six-week-old item.

Angular is unchanged at 22.1.7 since September 16, with no repository advisory newer than the September 16 DevTools local DoS. PrimeNG is unchanged at 22.1.1 since September 9. One dead endpoint worth recording: the oterm/oterm repository now 404s on the advisory API, so it has been dropped from the sweep list.