Terraform MCP Server Credential Reuse (CVSS 10.0), Veeam VSPC, and Django - August 2026 Patches

What happened

Three unrelated vendors shipped security releases in the same window at the start of August 2026, and one of them lands squarely on the agent layer. The Terraform MCP Server vulnerability tracked as CVE-2026-16498 carries a CVSS 10.0 for cross-tenant credential reuse. Alongside it, Veeam Service Provider Console patched an unauthenticated agent-impersonation flaw at CVSS 9.5, and Django shipped fixes led by a GeoDjango issue that can write files or make outbound requests. We are covering them together because the failure mode underneath all three is the same, and it is a failure mode agent architectures reproduce at scale: a component trusted an identity or a type it had not actually verified.

HashiCorp Terraform MCP Server: three ways to lose a token

The Terraform MCP Server exists so that an AI agent can query and act on Terraform infrastructure. That makes its credential-handling the whole of its security model, and all three flaws are credential-handling flaws. Critically, all three affect the streamable HTTP transport only. Running over stdio is unaffected.

Affected versions run 0.2.1 through 1.0.0 per HashiCorp's bulletin, with some CVE records listing 0.3.0 as the starting point. 1.1.0 (July 14, 2026) carries the fixes and 1.2.0 followed on August 4, 2026. CVE-2026-16496 was reported by Juan Pablo Martinez Kuhn of Coinspect; HashiCorp identified the remaining two internally. No active exploitation and no public proof-of-concept were reported as of August 5, 2026.

The 10.0 and the 8.9 are the same mistake at two different depths, and the pair is worth understanding rather than just patching. In stateless mode there were no session identifiers to bind to. In stateful mode there were, but the cache treated possession of a session ID as equivalent to possession of the credential. That conflation is the recurring structural error in remote MCP deployments, and we wrote about it when the stateless transport was specified in the stateless MCP spec and its security implications. A session identifier is a routing key. A token is an authorization. When a cache stops distinguishing them, every tenant sharing that cache shares an identity.

The SSRF deserves its own note because of what it leaks. CVE-2026-14869 does not exfiltrate the caller's credentials; it exfiltrates the server's own configured bearer token. A successful attempt hands an unauthenticated attacker the Terraform authority the server was provisioned with. That the same value is rejected in a header but accepted in a query parameter is the signature of partial input validation, and it is the same shape as the LiteLLM SSRF that leaked an API base key and the MCP Atlassian SSRF-to-RCE chain. Token passthrough between an agent, a gateway, and an MCP server is the architecture where this class keeps appearing, which is the subject of AI gateway OAuth passthrough and MCP and OAuth for MCP servers explained.

The stdio-versus-HTTP distinction is the configuration detail to actually verify. The two transports have close to inverted risk profiles: local stdio keeps the server in one user's context, where the concern is unreviewed local execution as documented in the Anthropic MCP stdio by-design RCE. Remote HTTP turns it into a shared multi-tenant service, where session isolation becomes load-bearing and one mistake affects every tenant simultaneously. Moving an MCP server from stdio to HTTP is not a deployment convenience. It changes which class of vulnerability applies to you.

Veeam Service Provider Console: impersonating an agent

Veeam patched four issues in Service Provider Console, fixed in 9.3.0.35057 (released July 29, 2026), affecting 9.2.1.33875 and all earlier version 9 builds. The two critical entries are CVE-2026-58073 (CVSS 9.5), unauthenticated agent impersonation leading to credential theft, and CVE-2026-58072 (CVSS 9.0), arbitrary file write on the management server leading to remote code execution. The high-severity pair are CVE-2026-58067, an unauthenticated memory-exhaustion denial of service, and CVE-2026-58071, proxied appliance API exposure to the Portal Administrator during a brief post-session window.

The mitigating detail on the 9.5 is that it requires high attack complexity despite needing no authentication, and the 9.0 requires a low-privilege account first. Veeam reported no known active exploitation, and these were not in CISA's Known Exploited Vulnerabilities catalog as of August 5, 2026. Note that Veeam scored these under CVSS 4.0 while HashiCorp used 3.1, so the numbers are not directly comparable across the two vendors.

"Agent" here means a backup agent, not an AI agent, and we are not going to pretend otherwise. But the failure is instructive precisely because it is the mature version of the same problem: a management plane accepted an unauthenticated claim about which non-human client was calling, and credential theft followed. Backup agents have had two decades to get identity right and this still happened. AI agents are being handed comparable authority now with far less scaffolding, which is the argument in non-human identity governance and in least privilege for AI agents. If a control plane cannot cryptographically distinguish one non-human caller from another, its permission model is decoration.

Django: a type confusion with filesystem reach

Django released 6.0.8 and 5.2.17 on August 4, 2026, with the fixes also applied to the main branch and the 6.1 release candidate. The lead issue, CVE-2026-15307, is rated High under Django's own policy: GeoDjango spatial lookups accepted string and dictionary values that were passed through to GDALRaster, which depending on the raster driver could result in file writes to disk or outbound network requests. Code execution becomes possible if a written file is later imported by the application. The documented attack path runs through staff users holding view permission on models containing spatial fields. The fix disallows dictionary values and non-valid GEOSGeometry strings in spatial lookups, and is deliberately backward-incompatible.

Two caveats worth carrying forward. Django's GIS code has drawn attacker attention already this year: CVE-2026-1207 in February 2026 was a SQL injection in PostGIS raster lookups with observed exploitation in the wild. So the GeoDjango surface is not theoretical, even though no exploitation of these four was reported as of August 5, 2026. And Django 5.1, 5.0, and 4.2 were not evaluated and may be affected, which is the usual unsupported-version trap: no advisory does not mean no vulnerability.

Why this set is an agentic-endpoint risk

The Terraform MCP flaws are the ones that change your agent exposure directly, and the reason is what the server is for. An MCP server is a capability grant. Connecting one gives every agent that can reach it the ability to act on whatever the server fronts, using whatever credential the server holds. When that server manages Terraform, the granted capability is infrastructure change, which is why the guardrail thinking in preventing destructive agent operations applies as much to terraform apply as it does to a DROP TABLE. A session-isolation bug in that position is not a data-confidentiality problem. It is an unauthorized-infrastructure-change problem.

The second reason is inventory. Patching requires knowing you run the thing, at which version, in which transport mode - and MCP servers are exactly the artifact class that gets installed without a ticket. A developer adds a Terraform MCP server to a local config to make one task easier, and it is now a component in your infrastructure control path that no asset inventory records. That is the gap how to build an MCP server registry exists to close, with the broader model in MCP server security: the complete guide and what MCP is and why it is a blind spot. Session-isolation failures are a recognized pattern in this ecosystem rather than a one-off: compare the Network AI empty-secret cross-origin MCP flaw and the MCP Kubernetes server tool-access bypass.

Django belongs in this advisory for a narrower reason. AI coding agents write and modify Django applications constantly, and the CVE-2026-15307 fix is backward-incompatible by design. An agent asked to make a spatial lookup work, on a codebase pinned to an older Django, has an obvious path of least resistance: loosen the input handling until the query passes. That is a plausible way for a fixed vulnerability to be reintroduced by a well-intentioned agent, and it is why scan-time checks and runtime governance solve different problems.

How Anomity surfaces and governs it

Anomity inventories MCP servers as one of eight AI artifact types its lightweight, unprivileged Endpoint Sensor collects per endpoint, alongside agents, skills, extensions, plugins, hooks, CLIs, and secrets. For this advisory that answers the question a vendor bulletin cannot: which endpoints have a Terraform MCP server configured, at which version, and against which transport. Anomity sends metadata only over HTTPS, never source code or prompts, with secrets redacted on the endpoint - so the credential a server holds is inventoried as a fact without the value leaving the machine.

Two things follow. First, on agents that expose a hook such as Claude Code's PreToolUse, runtime governance returns allow, deny, or log on each tool call before it runs. For an unpatched Terraform MCP server that means the infrastructure-changing call is a decision point rather than an execution, which is the only control that helps in the window between a disclosure and a completed rollout. Second, every added, changed, and removed artifact lands in a queryable 90-day audit trail, so an MCP server that appeared on a developer machine three weeks ago is a timestamped event you can find, and violations route to your SIEM, Slack, email, and Jira. Being honest about the boundary: Anomity does not patch these servers or scan your Django dependencies. It tells you where the affected artifacts are, decides what their agents may do meanwhile, and records what happened.

A session identifier is a routing key. A token is an authorization. CVE-2026-16498 is what a CVSS 10.0 looks like when a cache stops telling them apart.Anomity Threat Research

What to check across your fleet

• Find every Terraform MCP Server instance and record its version and transport. Versions 0.2.1 through 1.0.0 on streamable HTTP are affected; stdio is not. Upgrade to 1.1.0 or later, ideally 1.2.0.
• Determine specifically whether stateless HTTP mode was ever enabled. That is the precondition for the CVSS 10.0; the 8.9 stateful flaw affects default centralized deployments and is the more likely live exposure.
• Rotate any Terraform token configured on an affected server. CVE-2026-14869 can leak the server's own bearer token to an attacker-supplied endpoint, so assume disclosure rather than confirming it.
• Review logs for Terraform state changes and applies during the exposure window, and reconcile them against the humans and agents that should have made them.
• Upgrade Veeam Service Provider Console to 9.3.0.35057. Anything at 9.2.1.33875 or an earlier version 9 build is affected by the CVSS 9.5 agent-impersonation flaw.
• Upgrade Django to 6.0.8 or 5.2.17. If you run 5.1, 5.0, or 4.2, note those were not evaluated and may be affected regardless of the absence of an advisory.
• Audit which staff users hold view permission on models with spatial fields, since that is the documented attack path for CVE-2026-15307.
• Do not compare the CVSS numbers across vendors as if they were one scale. HashiCorp scored against 3.1 and Veeam against 4.0. Sequence remediation by internet reachability and blast radius instead.
• Reconcile your MCP server inventory against what was actually approved. An unpatched server nobody recorded is the case where this advisory does not reach the person who needed it.

The reason CVE-2026-16498 reaches 10.0 is not that the bug is clever. It is that the component sits between an autonomous agent and production infrastructure, holds a credential on the agent's behalf, and confused a routing key for an authorization. Every remote MCP server occupies that same position. This advisory is part of our MCP server security coverage; for the rest of the connected surface, see the top MCP servers of 2026. To see every MCP server, version, and transport across your fleet, and what runtime governance would deny while you patch, book a 30-minute demo.