Nothing new broke yesterday. What happened instead is that the database caught up: the official MCP Ruby SDK picked up five CVEs for bugs it fixed on July 7, and a 9.5 critical in an AWS code generator reached the npm advisory feed fourteen months after the patch. Both are check-your-pin items rather than drop-everything ones. The item that actually needs a human today is the opposite shape — seventeen .NET advisories that have been at NVD since July 14 and still aren't in the database Dependabot reads.

Worth your morning

MCP Ruby SDK — five CVEs, one version, already superseded twice. All five close in 0.23.0, which shipped July 7; the repo advisories went up July 8; NVD published the CVEs on the 29th and GitHub indexed them yesterday. If you run an MCP server on the Ruby SDK you have most likely already moved — 1.0.0 landed July 24 — so this is a question about what your Gemfile pins, not about waiting for a release.

The one to read first is CVE-2026-67431 (8.3), where StreamableHTTPTransport doesn't bind a session ID to a session owner, so a session identifier that has gone astray is enough to call tools inside someone else's session. The advisory's own framing is the useful part for defenders: the activity looks legitimate in logs, and the fix brings Ruby in line with what the C# and Go SDKs were already doing per the spec's session-binding recommendation. The rest are resource-exhaustion issues across the transports — CVE-2026-67432 (7.5) accepts a JSON-RPC body with no ceiling, CVE-2026-67430 (5.3) never releases sessions that were opened and abandoned, and CVE-2026-63119 (6.2) lets a stdio peer that never sends a newline grow one string until the OOM killer intervenes. CVE-2026-63118 (6.9) is the one to care about if you run a local server on the assumption that localhost is private: the Streamable HTTP transport shipped without Host or Origin checks, so a browser pointed at the right page can reach a server that was only ever meant to listen for the machine it runs on.

The .NET batch nobody's scanner can see. Seventeen advisories from the July 14 servicing release — .NET 8.0.29, 9.0.18 and 10.0.10 — were published as repo advisories in the dotnet/* repos and to NVD, and reported on July 15 as never having reached the global GitHub Advisory Database. Seventeen days later that's still true: CVE-2026-50524 (7.5, a denial of service across .NET 8, 9 and 10 plus Visual Studio 2022 and 2026) returns zero results in a GHSA search, reviewed or unreviewed. The practical consequence is narrow and worth stating plainly: if your only signal for .NET CVEs is Dependabot or an SCA tool sitting on the GitHub feed, you have had a silent gap on this batch for two and a half weeks. Check your runtime version against the July servicing release directly rather than waiting to be told.

A 9.5 that arrived fourteen months late. CVE-2025-4318 in @aws-amplify/codegen-ui-react was published by NVD on May 5, 2025 and fixed in 2.20.3 with follow-up hardening in 2.20.4. GitHub reviewed it into the npm feed yesterday, so it will surface as a new critical in scans run today against a package that has been patched for over a year. Nothing to do beyond confirming you're past 2.20.3 — but expect it in a report and don't treat it as fresh.

Smaller, and the day's other reminder that a control is only as good as its edge cases: CVE-2026-54722 (8.7) is in dssrf, a small npm library whose entire job is rejecting URLs that resolve to internal addresses, and which did not always do it. Fixed in 1.0.4. Low install counts, but if it's the thing standing between an agent's fetch tool and your metadata service, it's load-bearing.

Two standing items. The llama.cpp JSON-schema-to-grammar denial-of-service pair (CVE-2026-17500, CVE-2026-17501) is unpatched for a fourth day — hardening PR #25308 has been open since July 4 with no movement since the 19th, while the project has cut roughly forty builds in the meantime. Keep schema input inside your trust boundary. And on the Venicecom side, the reason PrimeNG has shipped nothing since 21.1.9 on June 4 is that the repository was archived on June 28 and development moved to PrimeUI. Existing releases are unaffected and still MIT, but there is no longer a repo that can issue a security fix for primeng. That's a migration to schedule, not a patch to apply.