al-ice.ai

HashiCorp Terraform MCP Server Flaws Cross Tenant and Token Boundaries

AI CVEs by al-ice.ai Editorial

HashiCorp has disclosed three vulnerabilities in the streamable-HTTP transport of its Terraform MCP Server. Together they reach each of the credentials a centralized deployment must keep separate: the server’s own Terraform bearer token, one stateful user’s cached client, and the per-user tokens sent through stateless requests.

The affected vendor range is 0.2.1 through 1.0.0, and all three issues are fixed in 1.1.0. Exclusive stdio deployments are outside the bulletin’s affected scenarios. The 1.1.0 release was published on July 14; HashiCorp’s HCSEC-2026-23 bulletin and the CVE records followed on July 28.

The highest-scored issue is CVE-2026-16498, rated Critical at CVSS 3.1 10.0 by HashiCorp’s CNA. CVE-2026-16496 is High at 8.9, and CVE-2026-14869 is High at 8.6. The advisory does not report exploitation in the wild, so these scores should drive exposure review rather than be read as evidence of active attacks.

An address override could send the server token off-site

CVE-2026-14869 is an unauthenticated server-side request forgery and credential-disclosure path. The HTTP middleware rejected a client-supplied Terraform address when it arrived in a header, but failed to apply the same rule to the equivalent query parameter. A remote caller able to reach the streamable-HTTP listener could therefore redirect Terraform API requests to an attacker-controlled endpoint. The server would attach its configured bearer token to that destination.

This is more precise than a generic “MCP SSRF” label: the consequential asset is the authorization header deliberately added after destination selection. The patch removes client control over the Terraform address in HTTP mode. Version 1.1.0 requires operators to configure it server-side with TFE_ADDRESS; clients that try the old header or query mechanism receive a 403.

The same boundary has appeared elsewhere in agent infrastructure. The site’s ToolHive host-side SSRF briefing showed why address validation must be enforced in the component that owns credentials and network reach—not left to a tool description or an upstream client.

Stateful mode trusted a session ID more than the current credential

In default stateful HTTP mode, the server cached a Terraform API client under the MCP session ID but did not bind that cached client to the token that created it. Under CVE-2026-16496, a user who obtained another user’s session ID could present it and have tool calls execute through the victim’s cached Terraform client.

The resulting authority is limited by the victim token, but that can still cover Terraform organizations, workspaces, variables, runs, and other resources. The issue does not affect stateless HTTP or stdio according to HashiCorp. It also is not a claim that session IDs are universally guessable; exploitation depends on obtaining one. The operational lesson is that a bearer-like routing identifier cannot safely stand in for credential binding.

Stateless mode collapsed all callers into one cache identity

CVE-2026-16498 affects deployments explicitly configured for stateless HTTP. In that mode, the underlying MCP library did not assign unique session identifiers to requests. The server nevertheless used session identity as the key for its Terraform-client cache, so credentials supplied by one tenant could be reused for later tenants regardless of the credentials they supplied.

This is a cross-tenant confused-deputy failure, not merely stale data. A later caller’s tool request can run with a previous caller’s Terraform token. Because the mix-up requires no victim interaction and can affect confidentiality, integrity, and availability across a security boundary, the CNA assigned the maximum CVSS 3.1 base score.

The stateful and stateless flaws look opposite—one over-trusts an attacker-presented session ID while the other lacks a distinguishing session ID—but they share one root design error: a cached privileged client was not cryptographically or structurally bound to the credential and principal authorized for the current request.

Defensive priorities

  • Upgrade every centralized server to 1.1.0 or later. Rebuild pinned containers and verify the running binary, not just the deployment manifest. HashiCorp presents network restriction only as an interim measure.
  • Inventory transport mode. Distinguish exclusive stdio, default stateful streamable HTTP, and explicitly stateless HTTP. The credential at risk and the exploitation prerequisite differ for each mode.
  • Rotate credentials when exposure is plausible. For CVE-2026-14869, rotate the server-side Terraform token if an affected listener was reachable by untrusted clients. For the cache flaws, assess and rotate user tokens where session theft or cross-tenant requests cannot be excluded.
  • Review outbound and Terraform audit logs together. Look for Terraform API traffic to unexpected hosts, unusual address parameters, one session used from unrelated identities or networks, and tool actions inconsistent with the token the caller presented.
  • Treat MCP session IDs as secrets. Keep them out of URLs, analytics, referers, support captures, and broadly readable reverse-proxy logs. Expire sessions aggressively and bind cached authorization state to both the authenticated principal and current credential.
  • Enforce destinations and egress outside the model path. Pin the Terraform endpoint in server configuration, allowlist it at the network layer, and prevent the MCP process from reaching arbitrary internet and metadata destinations.
  • Audit the rest of 1.1.0’s security changes. The changelog also records fixes for conflicting-token organization-allowlist bypass and unsafe forwarded-IP handling. Proxy deployments must explicitly configure MCP_REMOTE_IP_METHOD and trusted hops rather than assuming the old behavior remains safe.

Terraform automation makes this disclosure unusually consequential. The MCP server does not just read documentation: depending on enabled tools and token permissions, it can inspect or change infrastructure control-plane resources. Multi-user deployment therefore requires isolation at the request, cache, credential, session, and network layers. If any one of those bindings is implicit, an agent gateway can execute the right tool with the wrong tenant’s authority.

Sources: