Veeam, HashiCorp and the Django Software Foundation have together patched eleven vulnerabilities in their tooling for management, integrations and web applications. The key message is simple: install the critical patches as soon as possible, because some issues involve credential takeover and cross-tenant isolation problems.
In this overview, you’ll see which components are affected, which versions you need to update, and why the impact in some cases strongly depends on your configuration.
What has been patched: three ecosystems, eleven CVEs
The updates target three different products/toolchains:
- Veeam Service Provider Console (VSPC): four fixes in build 9.3.0.35057.
- Terraform MCP Server: three related problems in the Streamable HTTP transport layer.
- Django (GeoDjango): four CVEs, of which one is rated as high under Django’s own policy.
Important: according to the publications, there are no signs that the vulnerabilities are actively being exploited at that time, and the listed CVEs (as of 5 August 2026) are not included in CISA’s Known Exploited Vulnerabilities catalog. That doesn’t mean you can wait—patches are exactly meant to prevent “later exploitation”.
Veeam VSPC: unauthenticated credential takeover
Veeam’s top priority is the Service Provider Console, which hosting companies and managed service providers use to manage and monitor customer backups. In build 9.3.0.35057, multiple issues have been resolved, including two criticals.
CVE-2026-58073 (CVSS 9.5): intercepting agent credentials
The most striking vulnerability is CVE-2026-58073 with a CVSS score of 9.5. The flaw allows an attacker to impersonate a managed agent without authentication and then obtain that agent’s credentials.
“Unauthenticated” often sounds like: easy to misuse. In this case, however, the Veeam/CVE vector has indeed been assessed as high attack complexity. That still doesn’t change the fact that patching should be viewed as a direct process and risk measure.
CVE-2026-58072 (CVSS 9.0): arbitrary file write and potential RCE
The second critical is CVE-2026-58072 (CVSS 9.0). This bug is about arbitrary file write on the management server. In certain scenarios, it can lead to remote code execution, where a low-privilege account is sufficient.
Other high-severity issues
Besides the two criticals, two additional high-severity issues are included:
- CVE-2026-58067: unauthenticated memory-exhaustion denial of service.
- CVE-2026-58071: temporarily exposes the proxied appliance API as Portal Administrator after the start of an administrator session.
These four issues affect VSPC 9.2.1.33875 and all 9-series builds before it. The fix is upgrading to 9.3.0.35057.
Terraform MCP Server: one token, multiple tenants
Terraform MCP Server is designed to connect AI assistants to Terraform through the Model Context Protocol. The patched concerns are tied to how the server communicates in multi-user mode, specifically via Streamable HTTP.
There’s an important detail: if you run deployments only in stdio mode (local single-user setups), then—according to the publication—these bugs do not apply. So the problems are explicitly in the central, shared configuration.
CVE-2026-16498 (CVSS 10.0): cross-tenant token reuse
The most severe is CVE-2026-16498 (CVSS 10.0): a cross-tenant credential-reuse problem in stateless HTTP mode. In this setup, the MCP library does not assign unique session identifiers. As a result, user separation breaks down: a token from user A can later be reused in requests from user B.
CVE-2026-16496 (CVSS 8.9): isolation break in stateful mode
In addition, there is CVE-2026-16496 (CVSS 8.9). This is a variant for stateful mode. The cache used in that mode uses the MCP session ID as the only key and does not bind the cached content to the token that initiated the session. In other words: someone can use another party’s session ID to perform tool calls with that person’s Terraform client and reach resources that the victim token allows.
CVE-2026-14869 (CVSS 8.6): server-side request forgery
The third issue is CVE-2026-14869 (CVSS 8.6): a server-side request forgery (SSRF) in server-side request handling. The middleware rejects a Terraform address supplied by the client in the form of an HTTP header, but it accepts the same value as a query parameter. If an attacker can reach the Streamable HTTP listener, the server may then send a bearer token to an endpoint controlled by the attacker.
Which versions should you upgrade?
The publication states that you need to upgrade to at least Terraform MCP Server 1.1.0 or later. The fixed release is 1.1.0; later 1.2.0 updates were also released. If an immediate upgrade isn’t possible, the guidance is to restrict the Streamable HTTP listener to trusted users and to treat MCP session IDs as sensitive values.
Be careful when prioritizing: Veeam and HashiCorp use different CVSS versions (respectively CVSS 4.0 and CVSS 3.1). Also, the isolation issues can depend on the mode/configuration you use (stateless vs. stateful, and who enables or disables that setting).
Django/GeoDjango: write a file and possibly execute code
Django released updates on 4 August for multiple CVEs. Within that set, CVE-2026-15307 stands out because it affects GeoDjango—the layer for geographic data, in other words the part that helps process spatial queries and raster data.
CVE-2026-15307: spatial lookups may write data and (depending on setup) execute code
The problem is in spatial lookups: certain input values (str or dict) can, according to the publication, end up with GDALRaster. Depending on the raster driver used, that can:
- write a file to disk, or
- cause the Django process to make a network request.
Furthermore, writing to a location that is later imported by the application can lead to remote code execution.
The documented misuse path is reachable via a staff account with view permission on a registered model that contains a spatial field. So it’s not “public internet = direct danger”, but: once you have staff members (or compromised staff accounts), the risk becomes more relevant.
Which Django versions are patched?
According to the update, the fixes are included in Django 6.0.8 and Django 5.2.17. The same repairs have also been included in the main branch and the Django 6.1 release-candidate branch.
The approach changes behavior in part: dict values and strings that are not valid GEOSGeometry values are no longer allowed in spatial lookups. This may be a (small) breaking change for some workflows, while direct model-field assignments still accept these types.
Other CVEs in the release
Besides CVE-2026-15307, there are three other issues with lower severity:
- CVE-2026-15920: moderate stored cross-site scripting in the admin (URLField values can be rendered as links, leading to execution when clicked).
- CVE-2026-15830: moderate denial of service via deeply nested GEOMETRYCOLLECTION objects; in the fix this is limited to 198 collections.
- CVE-2026-15337: low-severity memory-consumption DoS in check_for_language(), with a limit (no language codes longer than 500 characters).
Not assessed are older, unsupported branches such as Django 5.1, 5.0 and 4.2; these may also be vulnerable.
Why these bugs fit the broader risk picture
Together, these three patches tell a clear story about modern infrastructure: management interfaces, integration servers and development/administration code are increasingly being connected to shared environments and tooling. As a result, a bug with an “almost” scope can still spread into credential issues, isolation failures or executable actions.
You see that reflected in the Veeam issue (agent credentials via unauthenticated impersonation), in the Terraform MCP issues (token/caches that don’t properly separate tenants) and in GeoDjango (spatial input that triggers unexpected behavior). In all cases, the solution isn’t only “fix the system”, but also: look at how you deploy it and which access levels you have organized.
If you want to dig deeper into comparable supply chain or tooling-like risks, this article can help:
