Hcsec-2026-23: Multiple vulnerabilities impacting HashiCorp Terraform MCP Server

I'll pull the HashiCorp advisory and HN thread so the paragraphs stick to real details only.HashiCorp published security bulletin HCSEC-2026-23 covering multiple vulnerabilities in the HashiCorp Terraform MCP Server. The affected range is terraform-mcp-server 0.2.1 through 1.0.0 inclusive; the issues are fixed in 1.1.0. The advisory, posted by james.warren on the HashiCorp Discuss security forum on July 28, 2026, assigns three CVEs: CVE-2026-14869, CVE-2026-16496, and CVE-2026-16498. All three sit in the streamable-HTTP transport used for centralized, multi-user deployments. On Hacker News the linked thread had 2 points and 0 comments at the time of this write-up.

Technically, the server can run streamable-HTTP in stateful mode (default for central deployments, with a per-session Terraform API client cache) or stateless mode (each request handled independently). It also accepts a configured Terraform endpoint and authenticates with a server-side bearer token; users supply their own Terraform Cloud or Enterprise token per request for RBAC. CVE-2026-14869 is SSRF: middleware blocked a client-supplied Terraform address in an HTTP header but not when the same value arrived as a query parameter, so an unauthenticated client could force the server to send its bearer token to an attacker-controlled endpoint. CVE-2026-16496 is an authorization bypass in stateful mode: the client cache keyed only on MCP session ID and did not bind the cache entry to the token that created it, so possession of another user’s session ID could cause tool calls to run under that user’s cached credentials. CVE-2026-16498 is cross-tenant credential reuse in stateless mode: the underlying MCP library does not assign unique session IDs, so the session-keyed cache could reuse one tenant’s Terraform token on later requests from other tenants. Stdio-only deployments are outside the SSRF path; stateful-only defaults avoid the stateless reuse issue; and stateless or stdio avoid the stateful session-cache bypass.

For engineers and builders wiring agents into infrastructure-as-code, this is not a theoretical MCP bug report. A multi-user Terraform MCP server holds the same class of secrets teams already treat as production-critical: organization and workspace access, variables, and anything else the Terraform token can reach. Session IDs become credential-equivalent material. Query-parameter handling that diverges from header validation is a concrete middleware failure mode. Anyone running terraform-mcp-server behind a shared listener for AI agents, IDE tooling, or internal automation is in the blast radius if they are on 1.0.0 or earlier and expose streamable-HTTP beyond a tight trust boundary.

In market terms, MCP servers are becoming the glue between coding agents and cloud control planes, and HashiCorp’s Terraform MCP Server is a high-value target because Terraform Cloud and Enterprise tokens already map onto real infrastructure change authority. Similar multi-tenant HTTP surfaces in other vendor MCP servers will face the same design pressures: how session identity is keyed, how client-supplied endpoints are validated, and whether stateless mode still isolates credentials. Coinspect’s Juan Pablo Martinez Kuhn reported CVE-2026-16496; HashiCorp’s internal team found the SSRF and the stateless reuse issues, which fits the pattern of both external researchers and product teams racing to harden this new agent-facing layer.

Practical takeaway: upgrade to terraform-mcp-server 1.1.0. If you cannot upgrade immediately, lock network access to the streamable-HTTP listener to trusted clients only and treat MCP session IDs as sensitive. Confirm whether you run stateful HTTP (default central mode), stateless HTTP, or stdio so you know which of the three CVEs actually apply. After upgrade, re-check any reverse-proxy or load-balancer rules that forward query parameters, and audit logs for unexpected Terraform endpoint values or session-ID reuse across users.