A CVSS 10.0 in an MCP Server: The Terraform, Veeam and Django Patch Round

Three unrelated patch rounds landed in the first week of August 2026, and one of them carries a CVSS 10.0. It is in HashiCorp's Terraform MCP Server, it is a cross-tenant credential leak, and it is the one worth reading carefully — not because it is the hardest to fix, but because of what it says about the layer we are all currently building on.

Terraform MCP Server: one user's token, another user's request

CVE-2026-16498, CVSS 10.0. In stateless HTTP mode, the server could reuse one user's Terraform credentials when serving subsequent requests from other users. Not a leak of the token's bytes — a leak of its authority. The second user's request executes with the first user's access.

There is a companion. CVE-2026-16496, CVSS 8.9, is the same class of failure in stateful mode, where the MCP session identifier was used as the sole cache key. Anyone who obtained or guessed a session ID inherited what that session could do. A third, CVE-2026-14869, CVSS 8.6, is server-side request forgery via a query-parameter bypass.

Versions 0.2.1 through 1.0.0 are affected. Fixes shipped in 1.1.0 on 14 July and 1.2.0 on 4 August. Critically: only multi-user HTTP mode is affected. If you run the server locally over stdio — one process, your machine, your credentials — none of this applies to you, and that is most people.

A CVSS 10.0 usually implies something clever. This one is a cache key. The server was written for the case where identity is ambient, because in the local case it is: one process, one user, the credentials in the environment are yours by definition. Then it grew an HTTP mode, and “the credentials in the environment” stopped meaning one thing.

That is the shape to watch across the whole MCP ecosystem. These servers were designed as local adapters between a model and a tool. They are now being deployed as shared services, and the transition from “one user, implicitly trusted” to “many users, mutually distrusting” is one that filesystem and database vendors took years and several incidents to complete. MCP is doing it in months, in public, and the relevant bug is almost never in the protocol — it is in the assumption that survived the port.

We take a specific position on this in our own architecture, and it applies directly: authorise on properties the server can independently verify, never on a claim supplied alongside the request. A session identifier used as a cache key is a client-supplied claim being trusted as an identity. That is the same mistake in a different costume.

What to do

Determine your transport first. Local stdio, and you are done — say so plainly and move on.
Running HTTP mode for a team: upgrade to 1.2.0, and treat it as a priority rather than a queue item.
Rotate the Terraform tokens that server has handled. Cross-tenant reuse leaves no distinctive trace at the token level, so rotation is the only clean answer.
Review what those tokens can reach. An MCP server holding infrastructure credentials deserves the same scoping scrutiny as a CI runner, and usually has not had it.

Veeam Service Provider Console: four fixes, two critical

Veeam patched four flaws in Service Provider Console, the multi-tenant management platform used by service providers to run backups for their customers. That is the second service-provider console on this week's list, alongside N-able N-central, and the reason both are attractive targets is the same: one console, many customer estates.

CVE-2026-58073 (CVSS 9.5) — unauthenticated credential theft allowing agent impersonation.
CVE-2026-58072 (CVSS 9.0) — arbitrary file write leading to remote code execution. Requires a low-privileged account, which in a multi-tenant console is a lower bar than it sounds.
CVE-2026-58067 (High) — unauthenticated memory exhaustion, denial of service.
CVE-2026-58071 (High) — exposure of a proxied appliance API.

Version 9.2.1.33875 and all earlier version 9 builds are affected. The fix is 9.3.0.35057, released 29 July. No exploitation has been observed — which makes this the version of this task you get to do calmly, and those are the ones most often deferred.

Django 6.0.8 and 5.2.17

Django shipped a security release on 4 August. The one that matters:

CVE-2026-15307 (High) — GeoDjango spatial lookups can be induced to write files to disk or make network requests from the Django process, with remote code execution a plausible outcome. Reachable by staff users holding view permission on a registered model containing a spatial field, which is a narrow precondition but not an exotic one for any site with a populated admin.
CVE-2026-15920 (Moderate) — stored cross-site scripting via URLField in the admin.
CVE-2026-15830 (Moderate) — denial of service through deeply nested GEOMETRYCOLLECTION values; nesting is now capped at 198.
CVE-2026-15337 (Low) — memory exhaustion in check_for_language(); language codes longer than 500 characters are now rejected.

A related GeoDjango flaw, CVE-2026-1207, was exploited in February 2026. If you use spatial fields, that history is the argument for treating CVE-2026-15307 as more urgent than “High, requires staff access” reads on paper.

The order to do these in

Terraform MCP Server, if and only if you run HTTP mode. Cross-tenant credential reuse against infrastructure tokens is the highest-consequence item here. Most readers will check this and correctly conclude it does not apply.
Veeam Service Provider Console. Unauthenticated credential theft at CVSS 9.5 on a platform holding customer backup infrastructure. No exploitation yet is a scheduling advantage, not a reason to skip it.
Django, prioritising CVE-2026-15307 if you use GeoDjango, and the whole release on your normal cadence otherwise.

What connects them

Only one of these four issues is a coding error in the traditional sense. The rest are assumptions that stopped being true: a credential scoped to a process that became a service; a console built for one operator that now serves many tenants; an admin permission that was about viewing data before a field type made it about touching the filesystem.

That is what a system looks like as it gains users. The security work is not primarily finding bugs in new code — it is noticing which old assumptions the new deployment silently invalidated. The Terraform MCP bug earned a 10.0 not through sophistication but because nobody re-asked, when HTTP mode was added, the question the stdio design had already answered: whose credentials are these?

If you are running MCP servers as shared infrastructure — and the number of teams doing so is climbing quickly — that question is worth asking of every one of them this week, not just the one with a CVE. Related reading: Langflow CVE-2026-9198, the same week's example of an AI tool whose local-first defaults became a network-facing vulnerability, and malicious MCP skills in the wild.