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

TL;DR — 90 Sekunden

Betroffen?

consul-mcp-server 0.1.0 bis 0.1.3.

Risiko?

Zwei Schwachstellen laut HashiCorp-Advisory HCSEC-2026-24: CVE-2026-16328 (SSRF, potenzielle Exfiltration des Consul-Auth-Tokens über eine unzureichend validierte client-seitige Adress-Überschreibung) und CVE-2026-16326 (Cross-Tenant-Credential-Reuse im Stateless-Modus, ein authentifizierter Client-Kontext kann sitzungsübergreifend wiederverwendet werden). Keine offiziellen CVSS-Werte, keine Angabe zu aktiver Ausnutzung.

Sofortmaßnahme?

Auf consul-mcp-server 0.1.4 aktualisieren. Bis dahin: Netzwerkzugriff auf den MCP-Server auf vertrauenswürdige Clients beschränken (HashiCorps eigene Empfehlung).

Empfehlung?

Besonders relevant für Deployments mit konfiguriertem Consul-Auth-Token (CVE-2026-16328) bzw. im Stateless-Betriebsmodus mit mehreren Clients (CVE-2026-16326) — für beide Konstellationen mit erhöhter Priorität patchen.

Kritikalität?

mittel (Hero-Badge) — kein RCE, konditionale Auswirkung je nach Konfiguration (Token vorhanden? Stateless-Modus aktiv?), keine veröffentlichten CVSS-Werte, keine bekannte aktive Ausnutzung.

Was ist das Problem?

CVE-2026-16328 — Server-Side Request Forgery

Der consul-mcp-server bietet eine Funktion, mit der Clients die Ziel-Adresse für eine einzelne Consul-API-Anfrage pro Request überschreiben können („per-request address override“). Laut Advisory validierte oder beschränkte der Server das vom Client angegebene Ziel nicht: „The per-request address override feature did not validate or restrict the destination supplied by the client.“ Ein Angreifer mit Zugriff auf den MCP-Server — also ein verbundener Client, nicht zwangsläufig ein Angreifer ohne jegliche Berechtigung — konnte dadurch Consul-API-Traffic auf einen selbst kontrollierten Endpunkt umleiten. Da der Server das konfigurierte Consul-Auth-Token bei diesen Anfragen mitschickt, kann ein solcher umgeleiteter Request das Token gegenüber dem Angreifer offenlegen. HashiCorp stellt klar: „Deployments with no Consul token configured in the environment are not exposed to credential exfiltration“ — Deployments ohne konfiguriertes Token sind von diesem spezifischen Risiko nicht betroffen.

CVE-2026-16326 — Cross-Tenant-Credential-Reuse

Im Stateless-Betriebsmodus des Servers isolierte die Implementierung den Sitzungsstatus pro Client nicht korrekt: „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 Umgebungen, in denen mehrere Clients denselben stateless-betriebenen MCP-Server nutzen, konnte dadurch ein authentifizierter Consul-Client-Kontext eines Mandanten für Anfragen eines anderen Mandanten verwendet werden — ein klassisches Mandantentrennungs-Problem in einer Multi-Tenant-Betriebsform.

Wer ist betroffen?

Beide Schwachstellen sind konditional in ihrer Auswirkung: CVE-2026-16328 wirkt sich nur aus, wenn dem MCP-Server ein Consul-Auth-Token konfiguriert ist — was in produktiven Umgebungen mit ACL-geschütztem Consul-Cluster der Regelfall sein dürfte. CVE-2026-16326 betrifft ausschließlich Deployments im Stateless-Betriebsmodus mit mehreren gleichzeitigen Clients; Single-Tenant- oder Stateful-Deployments sind von dieser konkreten Lücke nicht betroffen. Relevant vor allem für Organisationen, die den consul-mcp-server einsetzen, um KI-Agenten oder LLM-Tooling Lesezugriff auf Consuls Service-Discovery- und Konfigurationsdaten zu geben — ein wachsendes Einsatzmuster, da immer mehr Infrastruktur-Tools MCP-Anbindungen erhalten.

Auswirkungen

Bei CVE-2026-16328 ist das Worst-Case-Szenario die Offenlegung des konfigurierten Consul-Auth-Tokens an einen Angreifer, der bereits Zugriff auf den MCP-Server hat. Mit einem gültigen Consul-Token kann ein Angreifer je nach dessen ACL-Berechtigungen auf Service-Discovery-Daten, Key-Value-Store-Einträge und ggf. weitere Consul-Funktionen zugreifen — die konkrete Tragweite hängt vollständig davon ab, welche Rechte das jeweilige Token in Ihrem Consul-ACL-System hat. Bei CVE-2026-16326 ist die Auswirkung eine Vermischung von Mandanten-Kontexten: Ein Client könnte unbeabsichtigt mit den Consul-Berechtigungen eines anderen Clients agieren, was in Multi-Tenant-Umgebungen zu Zugriff auf Daten oder Aktionen führen kann, für die der eigentliche anfragende Client keine Berechtigung hätte.

Beide Lücken setzen bereits eine gewisse Ausgangsposition des Angreifers voraus — Zugriff auf den MCP-Server im Fall von CVE-2026-16328, bzw. Mitnutzung desselben Stateless-Servers im Fall von CVE-2026-16326. Das schmälert die Kritikalität gegenüber einer unauthentifizierten Remote-RCE, macht die Lücken aber in genau den Multi-Client- bzw. Multi-Tenant-Szenarien relevant, für die MCP-Server häufig überhaupt erst eingesetzt werden.

Mitigation / Sofortmaßnahmen

Operativer Entscheidungsblock

• Heute handeln, wenn … Sie den consul-mcp-server in Version 0.1.0–0.1.3 mit konfiguriertem Consul-Auth-Token betreiben und dieser für mehrere oder nicht vollständig vertrauenswürdige Clients erreichbar ist.
• Mit Priorität prüfen, wenn … Sie den Server im Stateless-Modus mit mehreren Clients betreiben.
• Regulär einplanen, wenn … nur ein einzelner vertrauenswürdiger Client zugreift und kein Consul-Token konfiguriert ist — das Update bleibt trotzdem empfohlen.

Schritt 1 — Auf 0.1.4 aktualisieren

# Version pruefen
consul-mcp-server --version   # oder gemaess der jeweiligen Installationsmethode

# Ueber den jeweiligen Paketmanager/Deployment-Mechanismus aktualisieren,
# z.B. bei npm-basierter Installation:
npm install -g consul-mcp-server@0.1.4

# Bei Container-Deployments: Image-Tag auf 0.1.4 anheben und neu ausrollen

Schritt 2 — Bis zum Update: Netzwerkzugriff einschränken

# HashiCorps eigene Empfehlung: Zugriff auf vertrauenswuerdige Clients beschraenken
# Beispiel Firewall-Regel, MCP-Server nur aus einem definierten Subnetz erreichbar machen
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

Schritt 3 — Nach dem Update: Consul-Token prüfen

# Vorsichtshalber pruefen, ob das konfigurierte Consul-Token weiterhin die minimal
# noetigen ACL-Rechte hat (Principle of Least Privilege), unabhaengig vom Patch
consul acl token read -id=<token-accessor-id>

Detection / Prüfung

Bestand feststellen

# Version des laufenden consul-mcp-server ermitteln
consul-mcp-server --version

# In Kubernetes: Image-Tag der laufenden Deployments pruefen
kubectl get deployments -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.template.spec.containers[*].image}{"\n"}{end}' | grep -i consul-mcp

Konfiguration prüfen

• Ist dem MCP-Server ein Consul-Auth-Token konfiguriert? Falls ja, ist CVE-2026-16328 für Sie relevant.
• Läuft der Server im Stateless-Modus mit mehreren gleichzeitigen Clients? Falls ja, ist CVE-2026-16326 für Sie relevant.
• Ist der Server aus einem Netzwerksegment erreichbar, das nicht vollständig vertrauenswürdige Clients enthält?

Hinweis zur Nachweisbarkeit

HashiCorps Advisory enthält keine veröffentlichten Indicators of Compromise oder Log-Signaturen für diese beiden Schwachstellen. Ohne dedizierte forensische Analyse (Consul-Audit-Logs auf ungewöhnliche Zieladressen bzw. Sitzungsübergreifende Zugriffsmuster prüfen) lässt sich eine vergangene Ausnutzung nicht zuverlässig retrospektiv feststellen — der Patch plus Zugriffsbeschränkung bleibt die wirksamste Maßnahme.

Betreiberempfehlung

Mid-Market

Prüfen Sie, ob der consul-mcp-server überhaupt im Einsatz ist — häufig wird MCP-Tooling von einzelnen Teams experimentell eingeführt, ohne dass es zentral erfasst ist. Ist er im Einsatz, updaten Sie auf 0.1.4 und prüfen Sie, ob das konfigurierte Consul-Token minimale statt weitreichende ACL-Rechte hat.

Enterprise

Dieser Fall zeigt ein Muster, das bei MCP-Servern für Infrastruktur-Tools generell relevant ist: Adress-Überschreibungs- und Proxy-ähnliche Funktionen (hier: per-request address override) sind klassische SSRF-Kandidaten, sobald sie clientgesteuerte Ziele akzeptieren. Nehmen Sie das als Anlass, andere MCP-Server für Infrastruktur-Komponenten (Vault, Nomad, Kubernetes-API-Proxys, Cloud-Provider-APIs) auf ähnliche Muster zu prüfen — insbesondere jede Funktion, die es einem Client erlaubt, die Ziel-Adresse einer serverseitigen Anfrage zu beeinflussen.

Entscheidungsblock

• Sofort patchen: Update auf consul-mcp-server 0.1.4.
• Bis dahin kompensieren: Netzwerkzugriff auf vertrauenswürdige Clients beschränken.
• Zusätzlich prüfen: ACL-Rechte des konfigurierten Consul-Tokens minimieren, Stateless-Modus-Nutzung mit mehreren Clients hinterfragen.

Fazit

HCSEC-2026-24 ist ein gutes Gegenbeispiel zu den spektakuläreren MCP-Sicherheitsvorfällen der letzten Monate: kein unauthentifiziertes RCE, keine ausgeklügelte Angriffskette, keine dramatische CVSS-10.0-Bewertung — sondern zwei nachvollziehbare, konditionale Implementierungsfehler in einer noch jungen Produktkategorie. Genau das macht den Fall lehrreich: MCP-Server, die als Brücke zwischen KI-Agenten und Infrastruktur-Tools wie Consul, Vault oder Nomad fungieren, erben zwangsläufig deren Berechtigungen und müssen deshalb dieselbe Sorgfalt bei Themen wie SSRF-Prävention und Mandantentrennung anwenden wie die Infrastruktur-Tools selbst. Die per-request address override-Funktion, die zu CVE-2026-16328 führte, ist ein klassisches Muster: Sobald eine Server-Komponente eine vom Client beeinflussbare Zieladresse für eine eigene ausgehende Anfrage akzeptiert, ist eine SSRF-Prüfung Pflicht — unabhängig davon, wie vertrauenswürdig der Client-Kreis vermeintlich ist.

Quellen

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