HashiCorp Consul-k8s: Autorisierungsumgehung über Namespaces in ACL-Bindungsregeln
Zusammenfassung
Consul-k8s ab Version 0.42.0 ist anfällig für eine namespace-übergreifende Autorisierungsumgehung in den ACL-Bindungsregeln der Komponenten. Ein Angreifer, der in einem anderen Kubernetes-Namespace einen ServiceAccount anlegen und dessen Token abrufen kann und Netzwerkzugriff auf die Consul-API hat, kann sich als Consul-Komponente authentifizieren und deren erhöhte Berechtigungen erlangen. Das Problem betrifft nur Installationen mit global.acls.manageSystemACLs=true.
Betroffen
- consul-k8s 0.42.0 bis 2.0.4 (gemäss HashiCorp-Advisory HCSEC-2026-50)
- Nur Installationen mit global.acls.manageSystemACLs=true sind betroffen
- Hinweis: Die CNA-Daten nennen den Bereich als kleiner als 2.0.4, daher ist 2.0.4 nicht bestätigt; nicht davon ausgehen, dass diese Version sicher ist
Behoben in
- consul-k8s 2.1.0
- consul-k8s 1.8.18
Umgehung
- Kein Workaround des Herstellers; die korrigierten Versionen einspielen.
- Übergangsmassnahmen (eigene Analyse, keine Herstellerempfehlung): prüfen, ob die System-ACL-Verwaltung aktiviert ist, bestehende ACL-Bindungsregeln überprüfen, einschränken, wer ServiceAccounts in anderen Namespaces anlegen oder deren Token abrufen kann, und den Netzwerkzugriff auf die Consul-API begrenzen.
Ausnutzung
- Es wurden keine Hinweise auf eine Ausnutzung in freier Wildbahn gefunden; laut Strix-Eintrag ist die Schwachstelle nicht in KEV gelistet.
- CISA SSVC: Ausnutzung keine, nicht automatisierbar, technische Auswirkung total.
- Ein öffentlicher PoC wird von Drittquellen behauptet, ist aber nicht verifiziert; entsprechenden Code als nicht vertrauenswürdig behandeln.
Unsere Empfehlung
- Alle consul-k8s-Installationen identifizieren und deren Versionen prüfen.
- Prüfen, ob die System-ACL-Verwaltung (global.acls.manageSystemACLs) aktiviert ist.
- Auf consul-k8s 2.1.0 oder 1.8.18 aktualisieren; vorher die Release Notes lesen: Regeln verlangen neu auch den Consul-Release-Namespace, Komponenten ausserhalb davon müssen verschoben werden.
- Multi-Tenant-Cluster priorisieren und bis zur Aktualisierung die Erstellung von ServiceAccounts und den Zugriff auf die Consul-API einschränken.
Öffentliche Exploits
Links zu fremden Seiten, von uns nicht geprüft – Exploit-Code kann Schadsoftware enthalten. Nur in isolierten Testumgebungen verwenden.
- Proof of Concept auf GitHub (1 Repositories)
Ghost-Bx1/ConsulK8s-CVE-2026-110720
Quellen der Recherche
- HashiCorp HCSEC-2026-50 advisory discuss.hashicorp.com
- consul-k8s releases github.com
- OpenCVE CVE-2026-110720 app.opencve.io
- Strix CVE-2026-110720 www.strix.ai
- SecurityOnline: consul-k8s vulnerability CVE-2026-110720 securityonline.info
- Cryptika: critical HashiCorp Consul Kubernetes flaw www.cryptika.com
- CyberPress: critical HashiCorp Consul Kubernetes flaw cyberpress.org
Recherchiert und auf Deutsch und Englisch aufbereitet von einer KI (Claude von Anthropic) auf Basis von NVD, CISA, EPSS und den genannten Quellen. Massgebend sind die Angaben des Herstellers. Recherche vom 30.10.2026 14:52.
Quellen
Der Tracker verbindet offizielle, frei nutzbare Datenquellen – laufend aktualisiert:
- NVD (NIST) – CVE, Bewertung (CVSS), betroffene Produkte
- CISA KEV – von der CISA bestätigt aktiv ausgenutzte Lücken
- CISA Vulnrichment – Einschätzung der CISA (SSVC) im offiziellen CVE-Eintrag
- FIRST EPSS – Wahrscheinlichkeit einer Ausnutzung
- Microsoft MSRC – Patch Tuesday: Lücken, Schweregrad, Updates
- PoC-in-GitHub – öffentliche Proof-of-Concept-Repositories
- Metasploit (Rapid7) – Module des Metasploit Framework
- Exploit-DB (OffSec) – Archiv öffentlicher Exploits (nur Verweise)
- Patch-Tage: offizielle Seiten der Hersteller (je Hersteller verlinkt) (Patch-Tage der Hersteller)
Dieses Angebot nutzt Daten der NVD-API, ist aber von der NVD weder unterstützt noch zertifiziert. EPSS-Daten © FIRST.org.
Betroffen? Wir helfen.
Wir prüfen, ob Ihre Systeme betroffen sind, spielen Updates ein und schliessen die Lücke – auf Wunsch auch laufend mit dem System Health Checker.