HashiCorp, Veeam and the Django Software Foundation released fixes in early August 2026 for 11 vulnerabilities, three of which are rated critical. The most severe are: cross-tenant token spoofing in Terraform MCP Server (CVE-2026-16498, CVSS 10.0), theft of managed agent credentials without authentication in the Veeam Service Provider Console (CVE-2026-58073, CVSS 9.5), and file writes with possible code execution via GeoDjango (CVE-2026-15307). Patches are available for: Terraform MCP Server 1.1.0+, Veeam VSPC 9.3.0.35057, Django 6.0.8 / 5.2.17. None of the vulnerabilities was listed in the CISA KEV catalog or had a public exploit at the time of publication; however, because each vulnerability is configuration-dependent, applicability needs to be assessed individually.
Veeam VSPC: agent impersonation and arbitrary file writes
Veeam’s 4 August security advisory describes four vulnerabilities fixed in build 9.3.0.35057 (released 29 July). All builds of version 9 up to and including 9.2.1.33875 are affected.
The key issue is CVE-2026-58073 (CVSS 9.5 using CVSS 4.0): an unauthenticated attacker can impersonate a managed agent and obtain its credentials. Despite not requiring authentication, the CVSS vector indicates high attack complexity — this is not a trivial one-click exploit. The second critical vulnerability, CVE-2026-58072 (CVSS 9.0), allows a low-privileged user to perform arbitrary file writes on the management server, with a potential path to remote code execution.
Two high-severity vulnerabilities round out the set:
- CVE-2026-58067 — denial of service via memory exhaustion without authentication;
- CVE-2026-58071 — short-lived exposure of a proxied device API with Portal Administrator privileges after an administrator session starts.
This is already the second critical patch cycle for VSPC in three months. In May, Veeam fixed CVE-2026-32998 (CVSS 9.4) — remote code execution via the alert script execution mechanism. For organizations using VSPC as a platform for managing customers’ backups, recurring critical vulnerabilities form a consistent risk pattern that requires giving updates priority attention.
Terraform MCP Server: one tenant’s token becomes access for all
On 28 July, HashiCorp disclosed three related vulnerabilities in the Streamable HTTP transport of the Terraform MCP server, which connects AI assistants to Terraform via the Model Context Protocol. A fix is available in version 1.1.0 (released 14 July), and then in 1.2.0 (4 August). Deployments in stdio mode (local single-user mode) are not affected — the vulnerabilities impact only the multi-user HTTP mode that HashiCorp promoted when announcing GA in June.
CVE-2026-16498 (CVSS 10.0) is the most serious of the three. In stateless HTTP mode, the underlying MCP library does not assign unique session identifiers, and the server’s credential cache used those identifiers to separate users. The result: one user’s Terraform token could be applied to subsequent users’ requests, regardless of which token they supplied. This is a classic case of tenant isolation failure whose root cause is an incorrect assumption about the behavior of a lower layer of abstraction.
CVE-2026-16496 (CVSS 8.9) is a similar isolation problem, but in stateful mode, which is the default mode for centralized deployments. The cache used the MCP session identifier as the only lookup key, without binding the cached client to the token that created it. An attacker who obtained another user’s session identifier could invoke tools using the victim’s client and access resources authorized by the victim’s token. This vulnerability was discovered by Juan Pablo Martínez Kun of Coinspect; HashiCorp found the other two internally.
CVE-2026-14869 (CVSS 8.6) is server-side request forgery (SSRF). Middleware rejected the Terraform address when it was supplied via an HTTP header, but allowed the same value through a query parameter. An unauthenticated caller with network access to the Streamable HTTP listener could cause the server to send the configured bearer token to an attacker-controlled endpoint.
A nuance when comparing CVSS scores
Directly comparing Veeam’s and HashiCorp’s scores is incorrect: Veeam uses CVSS 4.0, while HashiCorp’s CVE entries use CVSS 3.1. Scores of 9.5 and 10.0 on different versions of the scale are not equivalent quantities. In addition, the two isolation vulnerabilities in Terraform MCP Server affect different configurations: CVE-2026-16498 (10.0) targets stateless mode, which must be explicitly enabled, while CVE-2026-16496 (8.9) targets the default stateful mode. Practical priority is determined by the deployment configuration, not by the numeric CVSS value.
It is worth noting a discrepancy in the published ranges of affected versions: the umbrella HashiCorp advisory lists versions 0.2.1–1.0.0, whereas the individual CVE record starts at 0.3.0. Both sources agree that 1.1.0 is the first fixed version.
Django: a renewed attack on GIS code
The Django release of 4 August (versions 6.0.8 and 5.2.17) closes four CVEs. The only high-severity vulnerability is CVE-2026-15307 in GeoDjango. Spatial queries accepted string and dictionary values and passed them to GDALRaster when they appeared to be raster data. Depending on the raster driver, this allowed a file to be written to disk or a network request to be initiated from the Django process. Writing a file into a directory from which the application later imports code leads to remote execution of arbitrary code.
The documented exploitation path requires a staff account with permission to view a registered model that contains a spatial field. The fix forbids dictionary values and strings that are not valid GEOSGeometry values in spatial queries — this is a backwards-incompatible change. Direct assignment to model fields still accepts these types.
Three lower-severity vulnerabilities:
- CVE-2026-15920 — stored XSS in the admin interface via unsafe URLField values;
- CVE-2026-15830 — denial of service via deeply nested GEOMETRYCOLLECTION objects (the limit is now set to 198 collections);
- CVE-2026-15337 — memory exhaustion in check_for_language() (language codes longer than 500 characters are now rejected).
Unsupported Django branches 5.1, 5.0 and 4.2 were not assessed and may also be affected.
Context: Django GIS code in the crosshairs
The Django GIS module has already attracted attackers’ attention in 2026. In February, the project fixed CVE-2026-1207 — SQL injection in PostGIS raster queries. According to CrowdSec, exploitation in the wild was observed: a detection rule was released on 18 February, the first attacks were seen on 26 February, followed by sustained scanning to identify Django applications with a PostGIS backend. The new vulnerability CVE-2026-15307 requires a staff account, which makes direct exploitation via the results of that scanning impossible; however, the sustained interest in Django’s GIS code means that any new vulnerability in this module will be investigated by attackers in short order.
Recommendations for response
- Veeam VSPC: update to build 9.3.0.35057. All builds of version 9 up to and including 9.2.1.33875 are vulnerable. Given two critical patch cycles in three months, it is recommended to place VSPC on a priority update schedule.
- Terraform MCP Server: update to version 1.1.0 or later. If an immediate update is not possible, restrict network access to the Streamable HTTP listener to trusted users and treat MCP session identifiers as confidential values. Deployments in stdio mode are not affected.
- Django: update to 6.0.8 or 5.2.17. Check for models with spatial fields registered in the admin interface and audit staff accounts with permission to view such models. Account for the backwards-incompatible nature of the CVE-2026-15307 fix during testing.
- Organizations on unsupported Django branches (5.1, 5.0, 4.2) should assume they are vulnerable as well and plan migration to a supported version.
All 11 vulnerabilities have fixes available; none is being exploited in the wild at the time of publication, and the window for proactive updating is open. Update priority is determined not so much by the numeric CVSS score as by the configuration of a particular deployment: operators of VSPC, centralized Terraform MCP Server installations in HTTP mode, and Django applications using GeoDjango should apply patches in the coming days without waiting for public exploits to appear.
