anyio took four advisories yesterday, one of them 9.3, and it is the row that reaches furthest: the Anthropic SDK, the OpenAI SDK, the MCP Python SDK, httpx and Starlette all declare it as a direct dependency, and none of them pin above the vulnerable range. The fix shipped on July 12. The second story is the MCP control plane — Obot took three and ToolHive took one, both projects whose whole job is to sit between your agents and everything else.

Worth your morning

anyio — the one to check before coffee. CVE-2026-63374 (9.3 on v4) has TLSStream encoding host names with IDNA 2003 rather than IDNA 2008, which for a handful of internationalised domains produces a different ASCII label than the modern standard does. A certificate issued for the IDNA 2003 form then validates cleanly against a connection the client believes is aimed at the IDNA 2008 name. It needs an already-hijacked connection to matter, which is what keeps this from being the morning's emergency, but the reach is the point: anthropic declares anyio<5,>=4.1.0, openai declares anyio<5,>=4.10.0, the mcp Python SDK declares anyio>=4.9, and httpx and Starlette both take it too. Every one of those ranges admits 4.14.0 and 4.14.1. The package moves about 815 million downloads a month, and nothing in your dependency tree will nudge you off a vulnerable pin.

The fix is 4.14.2, released July 12 — two months before the advisories went up — and 4.15.1 has been current since September 5. Two others came in the same batch: CVE-2026-63349 (7.0) has open_process() forwarding the wrong variable when extra_groups is set, so a call meant to drop supplementary groups from a child process silently keeps the parent's — a privilege-dropping helper that returns without dropping anything. CVE-2026-64847 (6.8) has process-pool workers connected to an undrained stderr pipe, so a worker that writes enough to stderr fills the pipe and wedges the call awaiting it. All of them close at 4.14.2.

The MCP control plane took four. CVE-2026-58197 (8.8) has ToolHive — a platform for running MCP servers in containers — leaving host.docker.internal reachable from inside a container running the default insecure_allow_all network profile. A compromised MCP server can therefore reach the ToolHive API, the proxies for every other MCP server it manages, and anything else listening on the host's loopback. It is a container escape that does not require a container escape. Fixed in 0.30.1; current is 0.50.0, so roughly twenty releases sit between the fix and the disclosure.

Obot published three the same evening, all closing at 0.23.0. GHSA-xwmw-prc4-v3cr (8.8) is the one to read: OAuth dynamic client registration accepted an arbitrary external redirect URI from an unauthenticated caller and the authorization flow auto-completed with no consent screen, so a logged-in user who followed one crafted link handed over a token minted with their full group set — usable against the whole Obot API rather than scoped to the MCP server the flow claimed to be for. GHSA-jgh3-fggc-mcpm (7.6) has the remote MCP server URL fetched server-side during reconciliation with no destination filtering — loopback, RFC1918 and 169.254.169.254 all reachable — and GHSA-pr6h-vr44-xq8j (5.3) has OBOT_SERVER_ENABLE_REGISTRY_AUTH=true failing to protect the registry endpoints it names, because the authorizer checked a fixed list of protected prefixes and default-allowed everything else. Obot ships parallel lines — 0.26.0 landed September 17 and 0.25.6 the following evening — so take the newest release on whichever line you track. The fourth is CVE-2026-77339 (5.1 on v4), where process-compose's MCP SSE listener starts outside the REST API's token middleware and validates neither Host nor Origin, which puts a developer's local orchestrator within reach of a web page. Fixed in 1.120.0 back in July; only bites if you turned MCP SSE on.

LightLLM and SGLang — two criticals, neither with a release behind it. CVE-2026-93839 (9.8) has LightLLM's /pd_register WebSocket endpoint accepting node registrations from anyone who can reach it, with no peer address validation. Register a node and prompts routed to it arrive at your socket. The report has been open since September 16, 1.2.0 is the newest tag, and the lightllm name on PyPI is an unrelated stub last touched in 2024 — the real thing installs from source, so no lockfile scan will ever raise this. Until there is a fix, the prefill/decode control plane needs to sit on a network only your own nodes can reach. CVE-2026-93838 (5.9 on v3, 8.2 on v4) is the same shape in SGLang: an unvalidated chunk_idx in a ZMQ staging frame on the decode engine's internal rank port, allocating until the scheduler dies. Its issue has also been open since the 16th, and 0.5.20 — the affected ceiling — shipped yesterday morning. Both are disaggregated-serving features; a single-node deployment does not expose either port.

vLLM, and a change in the pattern. Three records, and for the first time this week two of them have a fixed version that holds up. CVE-2026-93592 (7.5 on v3, 8.7 on v4) is the one worth the row: the /v1/embeddings and /pooling endpoints checked the upper bound of submitted token IDs and not the lower, so a negative id reached CUDA and tripped a device-side assertion that poisons the GPU context — every subsequent request fails until the process restarts. Unauthenticated, one request, fixed in 0.28.0. CVE-2026-93840 (6.3 on v4) claims "before 0.29.0" and that checks out in the source: at v0.28.0, _validate_allowed_token_ids bounds against len(tokenizer); at v0.29.0 it bounds against model_config.get_vocab_size(), which is what actually sizes the logits mask. The reporter's PR is still open, but the release overtook it. Only CVE-2026-93841 (6.3 on v4) is still live — an unbounded index into the penalty bitset from multimodal audio requests, PR 49081 open — which after five consecutive mornings of "through 0.29.0" records with nothing behind them is a better ratio than the week has been running.

One npm row. CVE-2026-77301 (7.5) has adm-zip allocating an entry's output buffer from the uncompressed size declared in the central directory before checking it against the data actually present. A 105-byte archive declaring 1.77 GB commits 1.77 GB, and on a memory-constrained host the OOM kill lands before the CRC check that would have rejected it — so the error you would have caught never arrives. Affects everything below 0.6.1, which shipped September 11 and is now the latest tag. The package takes about 19 million downloads a week, and the advisory text still describes 0.5.17 as current, which it stopped being in June. Relevant to anything server-side that opens an archive it did not create.

LMDeploy, updated. Wednesday's digest noted that three of the four LMDeploy advisories existed only at repository level, returned Not Found from the API, and declared no fixed version. All three reached the global database yesterday afternoon with versions attached: 0.12.3 for the quant_dtype code execution, 0.15.0 for the SSRF bypass, 0.16.0 for the ZeroMQ pickle deserialization. Nothing about the defect changed and 0.17.0 still clears all four — but a pip scan will now raise them, which it would not have done on Wednesday.

Collection notes. The reviewed feed carried 40 entries for the window and stopped dead at 17:59 UTC yesterday — nothing published in the twelve hours since, which is why this table leans on records that landed in one afternoon burst. Nine of the forty were Semantic MediaWiki, four AnyIO, three Capsule, three Perses, three Obot; the tracked stack took eleven. Left off: @file-viewer/doc and md-editor-v3, both npm XSS in document renderers nobody on this stack ships, plus the usual Caddy, kcp, zot, XWiki and Opencast run. The unreviewed feed held 100 records, of which the four AI-runtime ones above are the whole yield — the rest is WordPress plugins, two of them against a chat plugin whose name contains "AI Chat Bots" and which therefore matches every keyword sweep ever written. NVD published 545 for the window; the Azure and Copilot CVEs among them are Wednesday's eighteen reaching the national database, tabled here yesterday. Microsoft revised the September document at 07:00 UTC on the 18th with exactly two new entries — an Edge elevation of privilege at 8.1 and a CoreDNS query-routing issue at 5.9 — and nothing on .NET, ASP.NET Core or the Azure AI services. Nothing at repository level from Ollama, llama.cpp, LangChain, LlamaIndex, Haystack, LiteLLM, Dify, Langflow, Open WebUI, n8n, CrewAI, ComfyUI, transformers, Gradio, Triton, the MCP reference servers, the Python, TypeScript or Rust MCP SDKs, the Anthropic and OpenAI Python SDKs, or any of the vector databases. Angular is unchanged at 22.1.7 since Tuesday. PrimeNG is unchanged at 22.1.1 since September 9.