Next.js fixed a 9.5 in its Node.js image renderer on Tuesday evening, and Angular shipped a router fix for server-side rendering last night. Yesterday's digest missed the Next.js one. No scanner that reads GitHub's advisory database will raise anything in this table. Twenty of its 22 advisories are repository-only, and the two MLflow CVEs have no package mapping.

Worth your morning

Next.js: check whether you render next/og on Node. GHSA-vcvr-r3jv-pc5j (CVE-2026-94545, 9.5 on CVSS v4) is remote code execution in the Node.js ImageResponse from next/og, in apps that put request-supplied values into the SVG they render. The root is upstream. Satori's SVG output was improperly escaped (GHSA-wx4j-mvgx-mqwp, medium on its own), and other dependencies turn that into code execution. The Edge implementation is not affected, and neither is Next.js 15. The fix is 16.3.6, released Tuesday. Vercel's bulletin describes 15.5.26 as hardening only. If you call Satori directly, the floor is satori 0.33.5, and @vercel/og 1.0.3 pins it. Both shipped the same day. Until you can deploy, keep request input out of the SVG content, attributes and styles you pass to the Node ImageResponse.

Angular: 22.1.8 is fixed, whatever the advisory says. GHSA-ff3f-86qr-9cv3 (8.2 on v4) lets an unauthenticated caller crash a Node.js SSR worker by exhausting its heap with crafted request URLs. Apps that only render in the browser are not affected. The advisory names 22.2.0, 21.2.24 and 20.3.32, all released last night. It leaves out 22.1.8, published minutes earlier on the 22.1 line, which carries the same router fix: the change is in url_tree.ts at the v22.1.8 tag and absent at v22.1.7. Once the record reaches GitHub's database, a scanner reading its range will flag 22.1.8 as vulnerable. Angular 19, through 19.2.25, is out of support and will not be patched. For v19, or until you can deploy, Angular's documented mitigation is to have the reverse proxy reject or strip semicolons in request paths before they reach the SSR server.

MCP servers: two upgrades and one token rotation. @zereight/mcp-gitlab (94,000 downloads a week) published seven advisories yesterday, all fixed in 2.1.65 on Tuesday. The top one, GHSA-cjfw-chc3-4r4v at 8.5, applies when the server authenticates to GitLab with a static Private-Token or JOB-TOKEN and serves a remote HTTP transport: the download proxy can forward that token to a host outside GitLab. Three more defeat the GITLAB_PERMISSION_MODE=modify ban on destructive operations. The others are an SSRF in the same proxy, a bypass of an earlier path-traversal fix, and session exhaustion on SSE. If you ran it with a static token over HTTP, upgrade and rotate the token. The package's floor is now 2.1.65, up from 2.1.41.

ToolHive published four advisories on Tuesday, fixed in 0.51.0 and 0.51.1 the same day. The two at 7.1 matter in multi-user deployments. MCP sessions were not bound to the user who created them (GHSA-hqg7-qjgg-q779), and the legacy HTTP+SSE proxy sent every backend response to every connected client (GHSA-wm2j-ch74-276r), so one authenticated user could receive another's tool results. The two at 4.3 are authorization gaps on resource subscriptions and completions.

MLflow: gaps in an opt-in guard. Two CVEs coordinated by CERT/CC (VU#369093), both 8.8, say the MLFLOW_ALLOW_PICKLE_DESERIALIZATION=false control did not cover two model flavors. For statsmodels (CVE-2026-96804), the guard arrived in 3.15.0 in July (PR 24686). For DSPy (CVE-2026-96775), CERT confirmed 3.12.0, names no fix, and lists MLflow as unreachable. MLflow merged a change in May that passes the control into DSPy's non-pickle loader (PR 23293), and it shipped in 3.13.0. Nobody has confirmed it closes the CVE. The control defaults to true, so on a default install every flavor deserializes pickles and these CVEs change nothing. The protection that works is loading models only from registries you control. If you did set it to false, upgrade to 3.16.1 and load DSPy-flavor models only from trusted sources.

vLLM: seven fixed, six still open. vLLM published seven of its own advisories yesterday, all medium and all fixed in 0.30.0. Three let a single request take down the shared EngineCore, three are resource exhaustion through video sampling or metrics labels, and one lets a caller-chosen request ID mix up late-interaction scores between requests on /score and /rerank. The four that cite a fix PR are merged, and all four are in the v0.30.0 tag. Two records carry typos a parser may trip on. One gives the affected range as < 030.0. The other gives the fix as >= 30.0.0, a release about thirty major versions away. The six KV-transfer CVEs from September 22 are unchanged: 0.30.0 is still the newest release, and all six fix PRs are open. VulDB also filed three CVEs overnight against Mooncake, the KV-cache transfer engine behind several of those connectors (CVE-2026-96762, 7.3 on v3.1 and 5.5 on v4, an authorization bypass in the master service's segment RPC, plus two lows). They cover everything through 0.3.13.post1 and 0.3.14-rc1, and the record says the vendor did not respond. The control is the same as for the connectors: keep the Mooncake master on a private network.

Also landed. GitLab 19.4.1, 19.3.3 and 19.2.7 (Wednesday's patch release) fix CVE-2026-92470 (7.7), which let an authenticated user read CI/CD variable values from debug-mode job traces through Duo's troubleshooting feature, and CVE-2026-92874 (5.4), where an MCP-scoped token could act beyond its scope. Kotaemon, the open-source RAG chat interface (25,800 stars), has CVE-2026-86867 from CERT/CC: in multi-user mode, any authenticated user can read, rename, delete or overwrite another user's conversations, including RAG retrieval history. It covers everything through v0.12.0, the newest release (May 31). There is no fix, and the repository has had no push since July 14. Run it single-user or one instance per tenant. The reviewed feed added nothing else for this stack: four more 9router records fixed by 0.5.6 (0.5.86 is current) and a 5.3 in Google's Mesop fixed in 1.3.4.

Standing items. Tencent BrowserSkill shipped cli-v0.3.1 yesterday morning. CVE-2026-94111 says "through 0.3.0", which now reads like an all-clear, but the report is still open and no commit has touched the daemon's WebSocket handler since it was filed. Treat 0.3.1 as affected until the issue closes. mcp-atlassian is still at 0.23.1, and GHSA-5j8j-256g-vvp5 is still repository-only, so yesterday's 0.23.1 floor stands. SGLang is still 0.5.20 with CVE-2026-93088 open. FalkorDB is still v4.20.6 on the C engine, gray-matter is still 4.0.3, and Chroma is still 1.5.9.

On the Microsoft side there is nothing to apply. The September document's 32 entries revised since yesterday touch no .NET, ASP.NET Core, Visual Studio or Azure AI product, and .NET 10.0.12, 9.0.20 and 8.0.31 are still the current security releases. PrimeNG is still 22.1.1.