pgvector 0.8.7 shipped yesterday evening with the fix for an 8.8: a database role that can build an IVFFlat index can write past a buffer and run code inside the Postgres server. It's a C extension, so npm audit, pip-audit and Dependabot will never raise it, and anyone storing embeddings in Postgres, managed or not, should check their version this morning. Mooncake, the KV-cache transfer engine behind disaggregated vLLM and SGLang serving, picked up a 9.8 and an unfixed 7.5, and piscina's 9.2 reaches every Angular LTS build through an exact pin.

Worth your morning

pgvector: an 8.8 your package scanners can't see. pgvector 0.8.7 went out at 17:26 UTC yesterday, seven minutes after the fix commit, and the official Docker images for Postgres 13 to 18 followed by 17:48. CVE-2026-103484 (8.8) was filed at 21:32 UTC: building an IVFFlat index can write out of bounds, which can lead to code execution in the database server. The precondition is a role allowed to build an IVFFlat index. Wherever the extension is installed, that includes any role that can create a table, so deployments that only use HNSW aren't excluded. Every version before 0.8.7 is affected. July's 0.8.6 fixed an IVFFlat build overflow on 32-bit systems only. To fix it, install the 0.8.7 package or image, restart Postgres so no session keeps the old library loaded, and run ALTER EXTENSION vector UPDATE; in each database that has it. The record has no package mapping, because pgvector ships through OS packages, images and managed services, so the language-level scanners won't raise it. Container scanners will once the distribution packages carry an advisory. On managed Postgres (RDS, Cloud SQL, Azure Database for PostgreSQL, Supabase, Neon) the provider picks the version: run SELECT extversion FROM pg_extension WHERE extname = 'vector'; and check the provider's notes. Until you're on 0.8.7, keep table creation away from roles you don't trust. An application whose database role owns its tables now turns any SQL injection into a path to the database host.

Mooncake: a 9.8 with an unconfirmed fix, and a 7.5 with none. Mooncake's transfer engine moves KV cache between prefill and decode nodes in disaggregated vLLM and SGLang deployments. VulnCheck filed two CVEs at 00:31 UTC today from issues opened yesterday afternoon. CVE-2026-103764 (9.8, 9.3 on v4) says an unauthenticated peer on the TCP transport's data port can read and write process memory, which can expose KV cache contents, prompts and secrets. VulnCheck names 0.3.13 (August 26) as the first fixed release and cites a TCP transport rewrite that 0.3.13 contains. Mooncake hasn't confirmed that, and the reporter's issue 4441 is still open with no maintainer reply. CVE-2026-103761 (7.5, 8.7 on v4) lets an unauthenticated caller grow the engine's memory through the handshake RPC port until the OOM killer ends it. It names 0.3.13.post1 (August 31), the newest release on PyPI, and issue 4445 is open. Upgrade to 0.3.13.post1 anyway, and firewall the engine's data and handshake ports so that only the serving cluster can reach them. It's the same boundary as the vLLM NIXL and Mooncake connector CVEs from September 22 and SGLang's PD issue below.

piscina: a 9.2 on every Angular LTS build. GHSA-67c8-pqhq-4rmx (9.2 on v4) reached GitHub's reviewed feed at 15:03 UTC yesterday, so npm audit and Dependabot raise it from today. It's a prototype-pollution gadget: code that can already pollute Object.prototype in the same process can make piscina run code in its workers. The fix shipped on August 28 in 5.3.2 and 4.9.4. Angular's CLI runs its build workers on piscina, and the LTS lines pin it exactly. @angular/build and @angular-devkit/build-angular 21.2.24 and 20.3.37 pin 5.2.0, and 19.2.27 pins 4.8.0. Angular 22.2 pins 5.3.2. The real exposure is lower than the score. piscina runs at build time on developer machines and CI, not in the app you ship, and it needs a second bug that pollutes the prototype inside the build. To clear the alert on 19 to 21, add an override ("piscina": "5.3.2", or 4.9.4 on v19) under npm's overrides or pnpm.overrides, and run a full build to confirm. It's the same shape as webpack-dev-middleware on September 30: the framework pins a version the fix never reached.

pydantic-ai and the AI SDK's ACP harness: two fixes no scanner knows about. pydantic-ai 2.53.0 went out at 03:17 UTC today, two minutes before GHSA-6fqq-452j-qhrp (7.5). When ConcurrencyLimitedModel or limit_model_concurrency wraps a model, a streamed request could keep its slot after it finished or the client disconnected. A client that keeps opening and abandoning streams can then use up a shared limiter and stall every other request. It affects pydantic-ai and pydantic-ai-slim from 2.10.0. If you can't upgrade, use the agent-level max_concurrency setting instead, or don't stream through a concurrency-limited model. Vercel published GHSA-g3x3-7q3h-gmhj at 19:22 UTC yesterday. @ai-sdk/harness-acp's host-tool relay didn't check that relay requests matched tool calls the model had made, so sandboxed code holding the relay credential could invoke registered host tools during an active turn. Tools that require user approval stayed protected. 1.0.77 came out 28 minutes after the advisory, and its changelog carries the fix. The advisory's package field names ai-sdk, an unrelated npm package last published in 2022, so if the record reaches GitHub's database as filed, scanners will flag the wrong package and pass the right one. Neither advisory is in GitHub's database yet.

MCP fetch server: an SSRF whose fix is still in review. VulDB filed CVE-2026-104120 (7.3 on v3.1, 5.5 on v4) at 03:31 UTC today against the official mcp-server-fetch reference server, and the record also names mcp-server-everything. The fetch tool will request internal addresses. The record says "up to 2026.6.4", but the guard against private addresses and cloud metadata endpoints is PR 4890, open since September 28. The server on main still has no such check, so 2026.8.18, the current release, is affected too. The model chooses what the tool fetches, so any page or document the model reads can steer it. Run the fetch server where its outbound traffic can't reach internal networks or 169.254.169.254, behind an egress proxy or a network policy.

Paperwork your scanner may raise. All of these were fixed before their records appeared:

• n8n: VulnCheck filed sixteen CVEs at 12:31 UTC yesterday (CVE-2026-103245 to CVE-2026-103260, up to 9.0 on v3.1) for the September 16 batch fixed in 2.39.6, 2.40.1 and 1.123.80. A correction: the September 17 digest counted eight advisories from that morning. n8n's repository lists sixteen, twelve of them high, all fixed in the same releases. If you're on 2.41.4 or later, as yesterday's digest recommended, you're covered. n8n released 2.41.5 and 2.42.2 yesterday.
• vm2: GitHub reissued fifteen reviewed records yesterday with CVEs attached, ten of them critical (up to 10.0). The September 17 versions are now marked as duplicates. All are fixed in 3.11.7 (August 24), and 3.12.2, the floor this digest gave on September 13, covers them.
• Obot: CVE-2026-103758 (8.1) is the CVE for GHSA-6fwv, tabled on September 28. Its range still says 0.21.1 through 0.24.1, which clears 0.24.2, and 0.24.2 doesn't carry the fix. Use 0.25.0 or later.
• AWS security-agent MCP server: GHSA-8g28-rj54-p5p2 (8.2, CVE-2026-97662), an argument injection published yesterday, was fixed in 0.2.0 on August 26. 0.2.1 is current.
• LiteLLM: GHSA-g5ff-637f-6q2m (8.1) lets an internal_user_viewer read local files through vertex_ai_credentials. It was published yesterday and fixed in 1.95.0 on August 2.
• virtualenv: two older records (7.3 and 7.8, fixed in 21.7.12 and 21.7.13) reached the reviewed feed. 21.14.2 covers them and yesterday's two.
• Thirteen unscored records filed together at 00:31 UTC today name old versions of Langflow (1.8.4 and 1.9.3), RAGFlow (0.24.0 and 0.25.3, six records), Langchain-Chatchat (0.3.x, three) and Devika (1.0, two). None names a fix. Langflow is at 1.12.4 and RAGFlow at 0.27.2, and the Langflow issue one record cites was closed in June. I didn't check whether the current releases carry fixes.

Standing items. SGLang 0.5.21 shipped at 01:09 UTC today. Its notes list three security changes: request-supplied chat_template is rejected by default, and two changes restrict the SafeUnpickler to explicit globals. None has an advisory, and issue 40125, the PD and Mooncake crash from September 30, is still open, so that CVE stays unfixed on 0.5.21. LightLLM is still at v1.2.0, with issues 1576 and 1595 to 1597 open. vLLM 0.30.0 is still the newest release. Milvus 2.6.25 and 3.0.2 are its newest tags. FalkorDB released 6.0.1 on the Rust engine yesterday, and its notes mention no CVE. Tencent BrowserSkill's community fix, PR 363, is still unmerged. mcp-remote is still 0.14.3 and NLTK still 3.10.3, and MetaMCP and mcp-chrome have released nothing since December. Office-PowerPoint-MCP-Server joins the unfixed MCP tools: CVE-2025-71427 (6.8, 7.6 on v4), a path traversal, names 2.0.7, the newest release (December 31, 2025), and its fix PR has been open since October 2025. LiteLLM 1.103.2 is the newest stable release, and its main branch still doesn't check email_verified in the proxy's auth code, so the JWT account takeover (CVE-2026-93355) remains unfixed. The repository advisories from n8n (14), GitPython (6), the MCP TypeScript SDK, Next.js (7), Angular (3) and two from PyJWT still return 404 in GitHub's database.

On the Microsoft side there's nothing new to apply. No tracked product in the September document has been revised since September 29, and October's arrives with Patch Tuesday on October 13. GitHub's reviewed NuGet feed hasn't published anything since September 25.