The reviewed feed has published nothing since Friday at 17:59 UTC — forty hours — so this is a short table built from repository advisories and one record the package feeds carried in just before the lights went out. That record is mnemosyne-memory, a 9.1 authentication bypass in an agent memory layer, and it is the only row this morning that asks you to change a version.

Worth your morning

mnemosyne-memory — the one version change. CVE-2026-59163 (9.1) has the sync server's authentication check decoding JWT bearer tokens and never verifying their HMAC-SHA256 signatures. Any well-formed token was accepted, which makes the caller whoever the token's payload says they are, with read and write access to that user's stored memory. A signature-verification step that runs on every request and validates nothing is the genre's oldest shape, and it is still the one that scores highest.

The package describes itself as a universal memory layer for AI agents, which is the part that decides whether this matters to you: what it holds is the accumulated context an agent has been trusted with, not a cache you can drop. Affected is everything through 3.10.0; the fix is 3.10.1, published June 22 — five days after the affected release and nearly three months before Friday's disclosure. Current is 3.15.1 from July 30, so anyone tracking releases cleared this in the summer and anyone pinned at 3.10.0 has been exposed the whole time. About 6,100 downloads a week.

One qualifier the advisory makes itself, and it is worth keeping: the 9.1 assumes the sync endpoint is reachable over the network. A localhost-only deployment scores materially lower. Check which one you are running before deciding how fast to move — but the upgrade is four months old and costs nothing.

The GitLab MCP server, re-filed. Two advisories went up Saturday afternoon against @zereight/mcp-gitlab — GHSA-64mg-3vx9-g74j (8.1) covering the execute_graphql read-only and allow-list bypasses, and GHSA-24vp-rch2-gjqq (7.5) covering unauthenticated session exhaustion. Neither is new. Both are constituents of GHSA-5648-rgj9-v224, the composite this digest tabled on September 16, split out and published under their own identifiers. Same defects, same < 2.1.30 boundary, same July 5 fix.

What changed is the paperwork, and the paperwork is the reason to mention it. Neither split carries a CVE, both are repository-only, and a scanner keyed on advisory IDs will raise two identifiers this morning for something remediated ten weeks ago. Worth knowing before someone escalates it.

While you are in that file: 2.1.30 is not the floor. Two July 19 advisories against the same package name higher boundaries — < 2.1.41 for a path escape in download_release_asset, and < 2.1.32 for a path traversal in job_id. The second names a version that does not exist; the release line runs 2.1.30 then jumps to 2.1.38. Take 2.1.41 as the real floor, or 2.1.64, which shipped Saturday. The package moves about 70,000 downloads a week.

vLLM, above the ceiling again. CVE-2026-93989 (3.1 on v3, 2.3 on v4) has SamplingParams.update_from_tokenizer() failing to validate bad_words token indices against the model's generation output width, so out-of-range indices reach the logits buffer and corrupt memory belonging to other in-flight requests. The scored impact is low and the honest reading of it is a correctness problem rather than a security one — but the failure mode is that two concurrent callers get each other's tokens, which is a worse sentence than 3.1 suggests for anyone serving more than one tenant from one process.

It is also the sixth consecutive record filed as "vLLM through 0.29.0" with nothing behind the bound. PR 48824 has been open since July 16 — two months — and 0.29.0 does not clear this. The standing floor line holds: upgrading to 0.29.0 closes several things and leaves this one open.

Collection notes. The reviewed feed carried 40 entries for the window and every one predates Friday 17:59 UTC; all of them were tabled yesterday. The only item in that batch this digest had not already covered is mnemosyne-memory, which landed at 17:54 — five minutes before the feed went quiet. The unreviewed feed held 152 records for Saturday and Sunday, and an anchored keyword sweep returned three hits, of which the vLLM record is the only tracked one; the other two were an unrelated DevOps tool and an OpenPanel token-logging issue at 3.3. The repository sweep covered 34 projects and returned two advisories, both the gitlab-mcp splits above. Nothing at repository level from Ollama, llama.cpp, LangChain, LlamaIndex, Haystack, LiteLLM, Dify, Langflow, Open WebUI, n8n, CrewAI, ComfyUI, transformers, Gradio, Triton, SGLang, LMDeploy, Obot, ToolHive, LightLLM, the MCP reference servers, the Python, TypeScript or Rust MCP SDKs, the Anthropic or OpenAI SDKs, or any vector database.

Microsoft revised the September document overnight at 01:54 UTC, and the revision is larger than it looks: 337 products against 307 on Thursday, 1,974 vulnerabilities against 1,547, with 247 entries carrying a revision date of Friday or later. None of them touch this stack. The additions are Azure Linux package mirrors — strongSwan, libXfont2, c-ares, BlueZ, containerd, the RabbitMQ Go client, nginx's JavaScript module — and the newest revision on anything genuinely .NET, ASP.NET Core or Azure AI is still September 17, which is the eighteen cloud CVEs this digest covered on the 18th. An unanchored azure filter would have reported 247 new Azure advisories this morning. There are none.

Chroma is unchanged: chromadb 1.5.9 remains both the newest PyPI release and the newest repository tag, four and a half months after publication and with the cross-tenant issue still open, so the compensating control tabled on September 17 stands. Angular is unchanged at 22.1.7 since September 16. PrimeNG is unchanged at 22.1.1 since September 9.