FastMCP published thirteen advisories yesterday. The worst lets a malicious MCP server run code inside the FastMCP client that connects to it, and every one of the thirteen is fixed in 3.4.9 or 4.1.0. Xoscar confirmed the unauthenticated 9.8 under Xinference and shipped a fix that stays off until you set a key, LMCache fixed a 9.8 in its multiprocess transport, and Angular's v20 line got an XSRF fix that v21 has had since December.

Few scanners will raise these. All thirteen FastMCP records, the Xoscar and Xinference records and the Angular record return 404 in GitHub's database, so pip-audit, npm audit and Dependabot stay quiet. The SGLang CVE is unreviewed with no package mapping. LMCache is the exception: its record entered the database last night with 0.5.6 as the fix.

Worth your morning

FastMCP: thirteen advisories, all fixed in releases you can install today. FastMCP (28,100 GitHub stars) published thirteen advisories between 15:19 and 20:48 UTC yesterday. The critical, GHSA-gpgx, is on the client side: from 2.10.0, a FastMCP client could execute code supplied in a server's tool output schema, with the client process's file, network and credential access. The advisory names agent hosts and gateways that connect to user-supplied MCP servers as the high-risk case. 3.4.8 and 4.0.11 fixed it on October 4. Of the four highs, GHSA-mhwm (8.1) let an authenticated client find and call a tool added by ToolInjectionMiddleware despite that tool's Tool.auth policy; it matters only if you use the middleware with per-tool auth and tokens of different privilege. GHSA-57vm is an incomplete fix for CVE-2025-64340: on Windows, the install commands for Claude Code and Gemini CLI still passed some arguments to cmd.exe unquoted. GHSA-2qh8 is unauthenticated memory exhaustion through an unbounded client-metadata cache. GHSA-p8g9 makes JWTVerifier fetch the identity provider's key set once for every unknown key ID, so unauthenticated traffic can get the server rate-limited by its own identity provider, and then every login fails. The mediums cover the OpenAPI provider (the client's Cookie header forwarded to third-party backends, undeclared headers passed through, and .. path parameters reaching other backend routes, an incomplete fix for CVE-2026-32871), origin protection silently ignored on the SSE transport, component-management routes that skipped the auth provider, hashed app tool calls that bypassed the allowlist, and MultiAuth merging security state across providers. The low is a skill provider following a symlinked SKILL.md out of its folder.

3.4.8 and 4.0.11 fix nine of the thirteen; the JWKS, MultiAuth, .. path and symlinked SKILL.md advisories need 3.4.9 (yesterday, 20:46 UTC) or 4.1.0 (October 8). The 2.x line is unsupported and gets no fixes, though seven of the thirteen, the critical among them, reach back into it. Upgrade to 4.1.0, or 3.4.9 if you can't move to 4.x yet.

Xoscar: the fix for its 9.8 ships switched off. When this digest covered VulnCheck's CVE-2026-49950 (9.8; 9.3 on v4) on October 14, the maintainers hadn't said anything about it. Yesterday they confirmed it and released Xoscar 0.12.0 (07:42 UTC), which authenticates every actor message with HMAC-SHA256 before deserializing it, but only when XOSCAR_AUTH_KEY is set. Xinference 4.0.1 (11:38 UTC) requires xoscar>=0.12.0 and passes the key through its Docker Compose files. Both projects list the release that carries the fix as affected (Xoscar ≤ 0.12.0, Xinference ≤ 4.0.1), which is accurate. To turn it on, upgrade every supervisor, worker, sub-pool and direct actor client, generate one random secret per deployment, set the same value on every process and restart them together. Keyed and unkeyed processes can't talk to each other, so there's no rolling upgrade. The key doesn't encrypt traffic or stop replay of captured messages, so keep the actor ports private as well; Xinference's distributed Compose setup publishes 9999, 30001 and 30002, and HTTP API authentication doesn't cover them. The CVE text still says "through 0.11.2", so anything matching on it will call 0.12.0 fixed. The Xinference floor moves from 3.5.0, set yesterday, to 4.0.1 with the key set.

LMCache: a 9.8 in multiprocess mode, fixed in 0.5.6. LMCache (12,100 stars), a KV-cache layer used with vLLM, published GHSA-w5f2 (CVE-2026-105192, 9.8) on October 13. Multiprocess mode's ZeroMQ transport (port 5555 by default) took no authentication and deserialized what it received unsafely, so anyone who could reach the port could run code as the LMCache process. The transport binds localhost by default and single-process mode doesn't open it, but multi-node setups bind a routable address, the project's example Kubernetes deployment bound every interface, and the official images ran as root. 0.5.6 reached PyPI on October 15 with a new wire format, so upgrade every worker and server together. It also binds the example deployment to localhost and runs the images as a non-root user. If the port was ever reachable from an untrusted network, the advisory says to treat the host as potentially compromised. GitHub's database has carried the flaw since October 7 under another record with no fixed version. It withdrew that one as a duplicate at 20:08 UTC yesterday, when the reviewed record went in pointing at 0.5.6.

SGLang: an unfixed code injection in the debug dumper. VulnCheck filed CVE-2026-111391 (8.1; 9.2 on v4) yesterday: the filter expressions accepted by the dumper's control endpoint can execute Python code, from 0.5.10 through 0.5.22, the newest release. The endpoint exists only when the dumper is turned on with DUMPER_SERVER_PORT. A port number starts a separate HTTP listener on every interface, and reuse mounts it on the main API port. Default installs don't open it. The report (issue 44188) has been open since October 14; one fix PR closed unmerged and PR 44782 is open. Leave DUMPER_SERVER_PORT unset on any server other people can reach. A second VulnCheck record, CVE-2026-111392 (4.8; 6.3 on v4), covers caller-supplied mm_hashes, which SGLang uses as the multimodal prefix-cache key, so one client can poison cached entries and read another request's image content or corrupt its response. The record says through 0.5.21; the fix (PR 44653, which puts caller hashes behind a --trust-caller-mm-hashes flag) is unmerged, so 0.5.22 is affected too. On a shared multimodal deployment, strip mm_hashes from client requests at the proxy. CVE-2026-93034 (9.8) and the five memory-exhaustion issues from October 13 are still open.

Angular: v20 gets an XSRF fix that v21 had in December. Angular published GHSA-jfgx (high, no score) at 07:43 UTC yesterday, an incomplete fix for CVE-2025-66035. A URL-parsing discrepancy let HttpClient's XSRF interceptor attach the X-XSRF-TOKEN header to a request for another origin. An attacker whose server accepts that header over CORS captures the token and can then forge requests in the user's session. The 21.x fix shipped in 21.0.3 on December 3, 2025, and every 22.x release has it. The v20 fix is 20.3.34, released October 14 with the release note "enable XSRF protection for same-origin absolute URLs" and no security label; the origin check is in xsrf.ts at the tag and absent at 20.3.33. v19 (≤ 19.2.25) is out of support and won't be patched. For v19 apps until the migration, the advisory's workaround: resolve dynamic URLs with new URL(url, window.location.origin), check that the origin matches before passing them to mutating HttpClient calls, and don't pass user-controlled URLs to those calls at all.

Also on the AI stack.

• LangChat CVE-2026-111704 (9.8; 9.3 on v4): the REST controllers have no authentication interceptor, which exposes user records with plaintext passwords and the configured LLM provider API keys without a login. The record names commit 2a6285a, which is the newest commit (September 27). The project (1,300 stars) has no releases, advisories or issues on it. Don't expose it, and rotate the provider keys if it was reachable.
• Z.ai ZCode CVE-2026-88755 (7.8): opening a repository connects to the MCP servers declared in its workspace configuration, which can lead to code execution. The record names v3.11.2.6792 and no fixed version. Don't open untrusted repositories in it.
• DeepSeek Harness CVE-2026-95183: prompt injection through the context-compaction feature, filed against commit c291e796 with no score and no fixed version. Treat fetched external content as untrusted input to the agent.

Paperwork your scanner may raise. Claude Agent SDK for Python CVE-2026-96620 (9.2 on v4) entered GitHub's database at 19:44 UTC yesterday. An application that passed an untrusted value to the resume option could be made to run commands. It was fixed in 0.2.121 on July 17 and the repository advisory went up September 12; this digest didn't cover it then. 0.2.168 is current. GitHub's reviewed feed published thirteen records yesterday evening, and nothing else in it touches the tracked stacks.

Standing items. Node.js main took undici 8.12.2 yesterday (#66721); the v24 and v22 backports are still open, and no Node.js release carries any of the eight fixes from yesterday. n8n shipped 2.43.7 and 2.44.3, the GitLab MCP server 2.3.2 and the MCP Java SDK 2.1.0 / 1.1.5 / 0.18.5, none with advisories; Open WebUI 0.12.3's notes mention unspecified security improvements and no advisory. Unchanged since yesterday: Archon 0.11.1 (CVE-2026-111322, no fix), LightLLM v1.2.0 (two unfixed), Kubeflow Model Registry 0.3.17, vLLM 0.31.0 (PR 51504 merged, in no release), LiteLLM 1.105.1 (CVE-2026-93355 open), Chroma 1.5.9, Portkey AI Gateway 1.15.2, BotSharp 5.2.0, Unla 0.10.0, Plano 0.4.37, the MCP Kotlin SDK 0.15.0, mistral.rs 0.9.4, Vearch 3.5.9, openapi-typescript-codegen 0.31.0, AstronRPA 1.1.6, Mooncake 0.3.13.post1, pandas-ai 3.0.0, mcp-remote 0.15.1 and GPT-SoVITS 20250606v2pro. BrowserSkill PR 363 is unmerged, @deepseek-ai/dsh-client-connection's latest tag still points at the affected 0.0.1-rc.1, and hyper-mcp has only nightly builds after 0.8.3. Microsoft's revisions to October's .NET and ASP.NET Core entries yesterday only added Visual Studio download links. No PrimeNG advisories today.