HashiCorp Consul MCP Server: SSRF and Cross-Tenant Credential Reuse (HCSEC-2026-24)

TL;DR in 90 seconds

Affected?

consul-mcp-server 0.1.0 through 0.1.3.

Risk?

Two vulnerabilities per HashiCorp advisory HCSEC-2026-24: CVE-2026-16328 (SSRF, potential exfiltration of the Consul auth token via an insufficiently validated client-supplied address override) and CVE-2026-16326 (cross-tenant credential reuse in stateless mode, an authenticated client context can be reused across sessions). No official CVSS scores, no statement on active exploitation.

Immediate action?

Update to consul-mcp-server 0.1.4. Until then: restrict network access to the MCP server to trusted clients (HashiCorp's own recommendation).

Recommendation?

Particularly relevant for deployments with a configured Consul auth token (CVE-2026-16328) or running in stateless mode with multiple clients (CVE-2026-16326). Patch both scenarios with elevated priority.

Criticality?

medium (hero badge): no RCE, conditional impact depending on configuration (token present? stateless mode active?), no published CVSS scores, no known active exploitation.

What is the problem?

CVE-2026-16328: Server-side request forgery

The consul-mcp-server offers a feature that lets clients override the destination address for a single Consul API request per call (“per-request address override”). Per the advisory, the server did not validate or restrict the client-supplied destination: “The per-request address override feature did not validate or restrict the destination supplied by the client.” An attacker with access to the MCP server (i.e. a connected client, not necessarily an attacker with no privileges at all) could redirect Consul API traffic to a destination they control. Because the server attaches the configured Consul auth token to these requests, such a redirected request can expose the token to the attacker. HashiCorp clarifies: “Deployments with no Consul token configured in the environment are not exposed to credential exfiltration”. Deployments without a configured token are not exposed to this specific risk.

CVE-2026-16326: Cross-tenant credential reuse

In the server's stateless operating mode, the implementation did not correctly isolate per-client session state: “the server did not correctly isolate per-client session state, which could cause an authenticated Consul client belonging to one session to be reused for requests from a different client.” In environments where multiple clients share the same stateless-mode MCP server, this could let an authenticated Consul client context belonging to one tenant be used for requests from a different tenant: a classic tenant-isolation problem in a multi-tenant operating mode.

Who is affected?

Both vulnerabilities have conditional impact: CVE-2026-16328 only matters if the MCP server has a Consul auth token configured (likely the norm in production environments with an ACL-protected Consul cluster). CVE-2026-16326 affects only deployments running in stateless mode with multiple concurrent clients; single-tenant or stateful deployments are not affected by this specific issue. Especially relevant for organisations using consul-mcp-server to give AI agents or LLM tooling read access to Consul's service-discovery and configuration data, a growing pattern as more infrastructure tools gain MCP integrations.

Impact

For CVE-2026-16328, the worst case is disclosure of the configured Consul auth token to an attacker who already has access to the MCP server. With a valid Consul token, an attacker can, depending on its ACL permissions, access service-discovery data, key-value store entries, and potentially other Consul functions. The concrete scope depends entirely on the privileges that token carries in your Consul ACL system. For CVE-2026-16326, the impact is a mixing of tenant contexts: a client could unintentionally act with another client's Consul permissions, which in multi-tenant environments can lead to access to data or actions the actual requesting client would not be authorised for.

Both issues already require a certain starting position on the attacker's part: access to the MCP server for CVE-2026-16328, or sharing the same stateless server for CVE-2026-16326. That reduces the criticality compared to an unauthenticated remote RCE, but makes both issues relevant precisely in the multi-client and multi-tenant scenarios MCP servers are often deployed for in the first place.

Mitigation / immediate steps

Operational decision block

• Act today if … you run consul-mcp-server 0.1.0–0.1.3 with a configured Consul auth token, reachable by multiple or not-fully-trusted clients.
• Check with priority if … you run the server in stateless mode with multiple clients.
• Schedule routinely if … only a single trusted client connects and no Consul token is configured. The update is still recommended.

Step 1: Update to 0.1.4

# Check version
consul-mcp-server --version   # or per your installation method

# Update via your package manager/deployment mechanism,
# e.g. for an npm-based install:
npm install -g consul-mcp-server@0.1.4

# For container deployments: bump the image tag to 0.1.4 and redeploy

Step 2: Until updated, restrict network access

# HashiCorp's own recommendation: restrict access to trusted clients
# Example firewall rule, making the MCP server reachable only from a defined subnet
sudo ufw allow from 10.0.0.0/24 to any port <mcp-server-port> proto tcp
sudo ufw deny to any port <mcp-server-port> proto tcp

Step 3: After updating, review the Consul token

# As a precaution, verify the configured Consul token still carries only the
# minimally required ACL privileges (principle of least privilege), independent of the patch
consul acl token read -id=<token-accessor-id>

Detection / verification

Establish inventory

# Determine the running consul-mcp-server version
consul-mcp-server --version

# In Kubernetes: check the image tag of running deployments
kubectl get deployments -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.template.spec.containers[*].image}{"\n"}{end}' | grep -i consul-mcp

Review configuration

• Does the MCP server have a Consul auth token configured? If so, CVE-2026-16328 is relevant to you.
• Does the server run in stateless mode with multiple concurrent clients? If so, CVE-2026-16326 is relevant to you.
• Is the server reachable from a network segment that includes not-fully-trusted clients?

A note on evidence

HashiCorp's advisory does not publish indicators of compromise or log signatures for either issue. Without a dedicated forensic review (checking Consul audit logs for unusual destination addresses or cross-session access patterns), past exploitation cannot be reliably established after the fact. The patch plus access restriction remains the most effective control.

Operator guidance

Mid-market

Check whether consul-mcp-server is in use at all. MCP tooling is often introduced experimentally by individual teams without central tracking. If it's in use, update to 0.1.4 and check whether the configured Consul token carries minimal rather than broad ACL privileges.

Enterprise

This case illustrates a pattern that's generally relevant for MCP servers fronting infrastructure tools: address-override and proxy-like features (here: per-request address override) are classic SSRF candidates the moment they accept client-controlled destinations. Use this as a prompt to review other MCP servers for infrastructure components (Vault, Nomad, Kubernetes API proxies, cloud provider APIs) for similar patterns, particularly any feature that lets a client influence the destination address of a server-side request.

Decision block

• Patch immediately: update to consul-mcp-server 0.1.4.
• Compensate until then: restrict network access to trusted clients.
• Also review: minimise ACL privileges on the configured Consul token, reconsider stateless-mode usage with multiple clients.

Conclusion

HCSEC-2026-24 is a good counterpoint to the more spectacular MCP security incidents of recent months: no unauthenticated RCE, no elaborate attack chain, no dramatic CVSS 10.0 rating, just two understandable, conditional implementation bugs in a still-young product category. That's exactly what makes the case instructive: MCP servers that bridge AI agents and infrastructure tools like Consul, Vault, or Nomad necessarily inherit their permissions and must therefore apply the same rigour to SSRF prevention and tenant isolation as the infrastructure tools themselves. The per-request address override feature that led to CVE-2026-16328 is a classic pattern: the moment a server component accepts a client-influenced destination address for its own outbound request, an SSRF check is mandatory, regardless of how trustworthy the client population is assumed to be.

Sources

• HashiCorp Discuss — HCSEC-2026-24: Multiple Vulnerabilities Impacting HashiCorp Consul MCP Server