mcp-grafana is the morning. The MCP advisory wave that has been grinding through hobby servers for five days reached a vendor-owned one, and it arrived at 9.1 with no fixed version. Behind it, the August servicing release landed after yesterday's digest went out: ten .NET CVEs across all three supported branches, and sixteen new n8n advisories that name the AI and LLM nodes by name.

Worth your morning

mcp-grafana — a 9.1, and the previous fix solved the adjacent problem. CVE-2026-19516 is a server-side request forgery in Grafana's MCP server: a caller-supplied X-Grafana-URL header sets the destination of the server's outbound requests, and the grafana_api_request tool lets the caller pick the method, path and body that go with it. No restriction on the destination means internal services and cloud metadata endpoints are reachable, with the responses returned to the caller. CVSS 9.1, published August 11, and the GHSA entry is unreviewed with no version range and no fixed version.

The history is the instructive part. This is the second CVE against the same header. CVE-2026-15583 was fixed in v0.17.2 on July 13, and that fix bound environment-configured credentials to the configured Grafana URL — the service-account token, deprecated API key, basic auth and extra headers stopped following a caller-specified host. What it did not do was stop the request from going there. The credential no longer leaks; the request still reaches whatever you point it at. One of those is the vulnerability the report described, and the other is the one that got fixed.

There is a control, and it is not a version bump for the SSRF. v1.1.0, released August 10, added bearer-token caller authentication for the SSE and streamable-http transports. That does not constrain the destination either, but it does mean an unauthenticated caller cannot set the header in the first place, which is the reachability precondition for all of this. So: if you run mcp-grafana over stdio for a single local client, this does not reach you. If you run it over SSE or streamable-http, get to 1.1.0, turn caller authentication on, and treat anything that can talk to that port as able to make Grafana-shaped requests to your internal network.

Worth naming what changed about this wave. The first four days were article-scraper-mcp and handwriting-ocr-mcp-server — single-maintainer servers, low scores, no fixed versions, and the honest answer was inventory work rather than patch work. This one is Grafana's, it is maintained, it ships releases on a schedule, and it is still a critical with an empty fix column. The class of finding has not changed. The class of project has.

.NET — ten CVEs, and read the attack vector before you read the title. The August servicing release is out: 8.0.30, 9.0.19 and 10.0.11, ten CVEs, published to the NuGet advisory database on August 11. That database had not moved since July 31, so this is the first NuGet item this digest has had in twelve days.

Two are titled as remote code execution and both need local access. CVE-2026-70354 (7.8) is an out-of-bounds write in Windows Presentation Foundation, and CVE-2026-62897 (7.0) is an integer overflow — both require local access and user interaction, both land in Microsoft.WindowsDesktop.App.Runtime, and neither is reachable over a network. If you saw them written up as critical RCEs overnight, that is Microsoft's own severity rating rather than the CVSS vector, and the vector is the one that tells you whether your fleet cares.

For a Linux-hosted ASP.NET Core estate the two that matter are elsewhere in the batch. CVE-2026-62901 (7.5) is an unchecked loop condition reachable over a network for denial of service, and it hits every Microsoft.NETCore.App.Runtime platform including all the Linux and musl variants. CVE-2026-62899 (5.9) is HTTP request smuggling in System.Net.HttpListener — inconsistent interpretation of requests, network vector, Linux and macOS runtimes. That one only applies if you use HttpListener directly rather than Kestrel, which most ASP.NET Core apps do not, so check before you prioritise it. Microsoft.AspNetCore.App.Runtime is not named in either advisory.

Self-contained deployments do not get this from a host runtime update — they need a rebuild against the patched reference and a redeploy. And the calendar item behind all of it: .NET 8 and .NET 9 both reach end of support on November 10, three months out. 8.0.30 and 9.0.19 are real fixes, and they are also the second-to-last few chances to do this as a patch rather than a migration.

n8n — a new CVE range, and this time the AI nodes are named. Sixteen advisories reached the global npm database on August 11, running from CVE-2026-72749 to CVE-2026-72775 — nine high, seven moderate, all unreviewed. These carry different GHSA identifiers from the project's own August 5 batch and name lower fixed versions: 1.123.67, 2.31.5 and 2.32.1, against the 1.123.69, 2.33.4 and 2.34.1 the repository advisories named. The practical answer does not change and does not require resolving which record is which — the higher numbers cover both sets, so 1.123.69 / 2.33.4 / 2.34.1 remains the target, and that closes an eight-day-old standing item.

The one to read is CVE-2026-72771 (7.1, high): before 2.32.1, the Allowed HTTP Request Domains allowlist is not enforced when a custom URL is configured on the AI and LLM nodes, so a workflow editor holding use-only access to a shared credential can point a request at a host they control. That is an authorization failure rather than a network one — the allowlist you configured to contain credential reach does not apply on the code path most likely to carry a model API key. If you run n8n multi-user with shared LLM credentials, that is the row that describes your setup.

Standing items. The llama.cpp JSON-schema-to-grammar pair (CVE-2026-17500, CVE-2026-17501) is unpatched for a sixteenth day, but there is movement for the first time since August 3: PR #26939 opened today, supersedes four earlier attempts including the closed #25308, and takes a different approach — unsupported regex patterns degrade to accepting any string rather than failing. It is open, review was requested today, and automated review has already flagged unvalidated quantifier bounds. Keep schema input inside your trust boundary; there is nothing to install yet. Milvus CVE-2026-69111 (8.7) is unchanged — PR #49847 is still open with no activity since July 28, so firewall port 9091. The broader MCP wave continues at roughly the same rate, still no fixed versions. Last week's items stand: NLTK wants 3.10.2, Traefik wants 2.11.52 / 3.6.23 / 3.7.7, go-git wants 5.19.2 or 6.0.0-alpha.5, re2 wants 1.26.1, Open WebUI wants 0.11.0 with no 0.10.x backport, Flowise wants 3.1.4. The reviewed npm and pip feeds have still not published since August 7 — five days, and the weekend explanation has run out.

On the rest of the Venicecom side, the August drop was 421 CVEs across all Microsoft products, of which seventeen touch Azure. Most are service-side and already fixed without customer action; CVE-2026-50516 against Azure Kubernetes Service is the one to confirm rather than assume, at 9.4 for missing authentication on a critical function reachable by an unauthenticated caller over a network. The actively exploited zero-day in the release, CVE-2026-68820, is in the Windows Ancillary Function Driver and is a workstation-patching item rather than an application one. Angular's third July 29 advisory (CVE-2026-69151, 7.6, i18n event-handler XSS, fixed in 20.3.27 / 21.2.19 / 22.0.1) finally reached the global npm database on August 10 — this digest covered it on the 4th from the repository advisory, so if your scanner raised it this week, you are already patched or already behind. primeng remains archived with no repository that can issue a security fix.