HashiCorp Consul MCP Server — SSRF and cross-tenant credential-reuse CVEs (CVE-2026-16328, CVE-2026-16326)

View raw markdownEdit on GitHub ↗

TL;DR

HashiCorp's own consul-mcp-server — the official Model Context Protocol server for its Consul service-mesh/service-discovery product — shipped two vulnerabilities patched in 0.1.4 (versions 0.1.0–0.1.3 affected): an SSRF (CVE-2026-16328, CVSS 8.6) that lets a connected MCP client override the server's configured Consul backend address and exfiltrate the server's Consul token, and a cross-tenant credential-reuse bug (CVE-2026-16326) that, in stateless deployment mode, can let one client's authenticated Consul session be reused for a different client's requests. Update to 0.1.4 if you run this MCP server.

What happened

HashiCorp disclosed both issues in security bulletin HCSEC-2026-24 on 2026-07-29 (HashiCorp Discuss).

CVE-2026-16328 (SSRF, CVSS 8.6, High) — consul-mcp-server did not validate the Consul backend address a connected client could supply via request header, allowing that client to redirect the server's own Consul API traffic to an attacker-controlled endpoint — and, in the process, potentially exfiltrate the Consul token the server was configured with. Confirmed directly on NVD: CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N, published 2026-07-29.

CVE-2026-16326 (Cross-tenant credential reuse) — in the server's stateless operation mode, per-client session state was not properly isolated, so one client's Consul authentication token could end up being used to serve a different client's requests when multiple clients connect concurrently.

Both affect consul-mcp-server 0.1.0 through 0.1.3; both are fixed in 0.1.4.

Am I affected?

# Check your consul-mcp-server version
consul-mcp-server --version 2>/dev/null
npm ls consul-mcp-server 2>/dev/null

You're affected if you run consul-mcp-server below 0.1.4. The SSRF (CVE-2026-16328) is reachable by any client connected to the server; the cross-tenant issue (CVE-2026-16326) only matters if you run the server in stateless mode with more than one concurrent client.

If you are affected

  1. Upgrade to consul-mcp-server 0.1.4.
  2. Rotate the Consul token the server was configured with, since the SSRF could have exfiltrated it to an attacker-controlled endpoint before you patched.
  3. See playbooks/if-an-mcp-server-was-malicious.md and playbooks/rotating-cloud-credentials.md.

Prevention

This fits this repo's standing "MCP servers are unauthenticated network services by default" pattern: an MCP server that proxies a backend API and holds a privileged token for it needs the same input-validation discipline as any other network service accepting client-supplied destination addresses. See prevention/mcp-hygiene.md and prevention/agent-sandboxing.md.

Sources