Veeam, Terraform MCP, Django Patch Critical Flaws, Led by CVSS 10.0 Cross-Tenant Bug

HashiCorp, Veeam, and the Django Software Foundation have patched 11 vulnerabilities across Terraform MCP Server, Veeam Service Provider Console, and Django.

The three most serious:

• An unauthenticated flaw in Veeam's console that hands over a managed agent's credentials, rated 9.5
• A cross-tenant flaw in HashiCorp's MCP server that lets one user's Terraform token be reused for later users' requests, scored a maximum 10.0 on its CVE record
• A flaw in GeoDjango's spatial lookups that can write a file to disk and, on some setups, run code, reachable by a staff user with view permission on a registered model containing a spatial field

Each has a fix available now. Operators should update Terraform MCP Server to version 1.1.0 or later, Veeam Service Provider Console to 9.3.0.35057, and Django to 6.0.8 or 5.2.17.

Exposure is configuration-dependent: HashiCorp's bugs affect Streamable HTTP rather than stdio, Veeam's flaws affect version 9 builds before 9.3, and Django's documented admin attack path requires a staff account with view permission for a model containing a spatial field.

None of the three advisories says the flaws are under active exploitation, and as of August 5, 2026, none of the eleven CVEs appears in CISA's Known Exploited Vulnerabilities catalog, and no public proof-of-concept has surfaced.

Impersonate an agent, take its credentials

Veeam Service Provider Console, the multi-tenant console that hosting firms and managed service providers use to run and monitor customer backups, got four fixes in build 9.3.0.35057, detailed in a security bulletin published August 4. Two are critical. Veeam released the build on July 29.

• The one to watch is CVE-2026-58073 (CVSS score: 9.5), which lets an unauthenticated attacker impersonate a managed agent and obtain that agent's credentials. Its CVSS vector rates attack complexity as high.
• The second critical flaw, CVE-2026-58072 (CVSS score: 9.0), is an arbitrary file write on the management server that can lead to remote code execution and requires a low-privilege account.

The 9.5 reads as the worst of the two because it needs no login, but its high attack complexity is the reason the vector is not a straight-line exploit; unauthenticated here does not mean easy.

Two high-severity bugs round out the set: CVE-2026-58067, an unauthenticated memory-exhaustion denial of service, and CVE-2026-58071, which exposes the proxied appliance API as Portal Administrator during a short window after an administrator session begins.

All four affect VSPC 9.2.1.33875 and every earlier version 9 build. The fix is the upgrade to 9.3.0.35057.

This is the second critical patch cycle for the console in roughly three months. In May, Veeam fixed CVE-2026-32998, a 9.4-rated remote code execution bug tied to alarm script execution.

One tenant's token, reused for the next

HashiCorp's Terraform MCP server, which connects AI assistants to Terraform over the Model Context Protocol, carries three related flaws in its Streamable HTTP transport, disclosed July 28 and fixed in version 1.1.0. HashiCorp released the fixed build on July 14, followed by version 1.2.0 on August 4.

Deployments that run only in stdio mode, the local single-user setup, are unaffected. The bugs live in the multi-user HTTP mode meant for centralized, shared deployments, the configuration HashiCorp promoted when it made the server generally available in June.

The most severe is CVE-2026-16498 (CVSS score: 10.0), a cross-tenant credential-reuse bug in stateless HTTP mode. The underlying MCP library does not assign unique session identifiers, and the server's credential cache relied on those identifiers to tell users apart.

One user's Terraform token could therefore be reused for later users' requests regardless of the token they supplied. The root is an assumption about the layer beneath the tool: the server used those session identifiers to keep tenants apart, and in stateless mode the MCP library did not provide unique ones.

A second flaw, CVE-2026-16496 (CVSS score: 8.9), is the stateful-mode version of the isolation failure. Stateful mode is the default when the server runs centrally.

Its cache used the MCP session ID as its sole lookup key, without binding the cached client to the token that created it. That let a user who obtained another user's session ID run tool calls with that user's Terraform client and reach resources allowed by the victim's token.

Juan Pablo Martinez Kuhn of Coinspect reported the flaw; HashiCorp found the other two internally.

The third, CVE-2026-14869 (CVSS score: 8.6), is a server-side request forgery flaw. Request middleware rejected a client-supplied Terraform address when it arrived as an HTTP header but not when the same value came through a query parameter.

An unauthenticated caller able to reach the Streamable HTTP listener could make the server send its configured bearer token to an attacker-controlled endpoint.

Two things complicate reading the CVSS numbers as a priority order. They are not on one scale: Veeam scores on CVSS 4.0 and the HashiCorp records on 3.1, so the 9.5 and the 10.0 are not the same measurement.

And the two isolation flaws land on different configurations: the 10.0 (CVE-2026-16498) affects stateless mode, which an operator has to enable deliberately, while the 8.9 (CVE-2026-16496) affects the stateful mode that is the default for a central deployment.

Which of the two is in reach depends on how the server is configured, not on which carries the higher number.

There is a discrepancy in the published affected-version ranges. HashiCorp's umbrella bulletin lists versions 0.2.1 through 1.0.0, while the individual CVE records begin at version 0.3.0. Both sources agree that version 1.1.0 is the first fixed release.

The scores come from the CVE records HashiCorp assigned; the advisory itself lists none. Operators who cannot upgrade immediately should restrict network access to the Streamable HTTP listener to trusted users and treat MCP session IDs as sensitive values.

Back in GeoDjango's raster path

Django shipped 6.0.8 and 5.2.17 on August 4, with the same fixes applied to the main branch and the Django 6.1 release-candidate branch. The release covers four CVEs. Django rates their severity under its own security policy, and only one is rated high.

That flaw, CVE-2026-15307, sits in GeoDjango, the framework's geographic-data layer. Spatial lookups accepted str and dict values and passed them to GDALRaster when they appeared to represent rasters.

Depending on the raster driver, that could write a file to disk or make the Django process issue a network request. Writing a file to a location later imported by the application can result in remote code execution.

The documented admin path is reachable by staff users with view permission on a registered model containing a spatial field. The fix disallows dict values and strings that are not valid GEOSGeometry values in spatial lookups, a backward-incompatible change. Direct model-field assignments still accept those types.

The other three flaws are lower severity:

• a moderate stored cross-site scripting bug in the admin where unsafe URLField values could be rendered as links and execute when clicked (CVE-2026-15920);
• a moderate denial of service through deeply nested GEOMETRYCOLLECTION objects that could trigger a GEOS segmentation fault (CVE-2026-15830, now limited to 198 collections); and
• a low-severity memory-consumption denial of service in check_for_language() (CVE-2026-15337, now rejecting language codes longer than 500 characters).

Older unsupported branches, including Django 5.1, 5.0, and 4.2, were not evaluated and may also be affected.

Django's GIS code has already drawn attacker attention this year. In February, the project patched CVE-2026-1207, a SQL injection flaw in PostGIS raster lookups.

CrowdSec reported exploitation in the wild: it released a detection rule on February 18, observed the first attacks on February 26, and subsequently saw steady probing aimed at locating PostGIS-backed Django deployments.

That flaw required a PostGIS backend and user-controlled input to a specific lookup. The probing locates the kind of application without opening it. The new flaw's documented route needs a staff account, and fingerprinting a public site does not supply one, so the reconnaissance that found PostGIS-backed Django stops a step short of an actual way in. What carries over is the scrutiny on this code.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.