vLLM shipped 0.26.0 and attached four advisories to it, and two are the same story: an earlier fix that didn't reach far enough. Nothing here is worse than a 6.5, but if you run vLLM as a serving layer, that's this morning's upgrade. The day's biggest number sits elsewhere and is mostly already handled — Google's MCP Toolbox takes an 8.4 for a tool that would attach its bearer token to whatever URL a caller named, and the fix for that has been in releases since June 18.

Worth your morning

vLLM — four at once, one version to move to. All four are medium and all four close in 0.26.0, published alongside them on July 27. The one to read first is GHSA-87x5-vmc3-756j (6.5): /v1/completions accepts prompt as a list with no bound on how many entries it holds, and the serving path turns each entry into its own engine request with its own response slot — so one authenticated call becomes as many backend subrequests as the caller asked for, before any aggregate budget applies. Availability only, but it's the cheapest of the four to trip.

The other two worth your attention are both patches on patches. GHSA-48jh-3gj7-fg8v (5.3) is a ReDoS in structured_outputs.regex: the earlier fix wrapped the regex compile in a timeout for the xgrammar and outlines backends and left lm-format-enforcer compiling caller-supplied patterns with no timeout and no buildability check — the guard covered two of the three backends. GHSA-pr7f-p5mw-fc87 is an incomplete remediation of CVE-2025-62164, where the follow-up protection relies on a PyTorch context manager that saves and restores process-global state, so two prompt-embedding parts gathered concurrently in one request can leave one of them outside the guard it thinks it's inside. Rounding out the set, GHSA-8737-qx52-hjff (4.3) has the /v1/*/derender endpoints detokenizing caller-supplied token-ID lists without applying context-length, max_tokens, or response-size bounds. If you expose derender routes or accept structured-output regexes from callers you don't control, take 0.26.0 today.

MCP Toolbox — an 8.4 you may have already patched by accident. CVE-2026-16481 (8.4, CVSS v4) is in the cloud-healthcare-fhir-fetch-page tool of Google's MCP Toolbox for Databases. The tool took a pageURL parameter from the client without validating it and fetched it with an authenticated client, and the transport underneath attaches an Authorization: Bearer header to every outbound request regardless of destination host — so a URL pointing anywhere off-platform gets the OAuth or service-account token sent along with it. The advisory puts the exposure at the end-user token or the broader ADC service-account token, and from there Protected Health Information and other GCP services. The useful detail for a defender is the timeline: the fix merged June 18 and landed in v1.5.0 the same day, six weeks before the CVE was indexed. Check what you're pinned to rather than waiting for a new release — v1.8.0 shipped this morning, and anything from v1.5.0 up already has it.

Also on the MCP side, and much smaller: NanoClaw CVE-2026-17433 (1.9, low) is an improper-authorization flaw in the MCP server approval path in versions up to 2.0.64. It needs local access, the impact is low across the board, and there's no fix — NVD records that the project was notified through an issue report and hasn't responded. Worth knowing if you run it, not worth your morning.

Still unpatched from yesterday: the two llama.cpp JSON-schema-to-grammar denial-of-service CVEs (CVE-2026-17500, CVE-2026-17501) picked up GHSA mirrors overnight but no release — hardening PR #25308 has been open since July 4 and was still open at time of writing, so keep schema input inside your trust boundary. Quiet on the Venicecom side: GitHub's reviewed advisory feed has published nothing for npm, NuGet, pip, or Go since July 24, .NET's last security advisories remain the July 14 servicing batch, Angular's stand at June 10, and PrimeNG hasn't shipped since 21.1.9 on June 4.