HashiCorp Vault: Remote Code Execution über aus Snapshots wiederhergestellte Plugin-Katalogeinträge
Zusammenfassung
Vault und Vault Enterprise prüfen gespeicherte Einträge im Plugin-Katalog nicht konsistent darauf, ob sie auf Binaries innerhalb des konfigurierten Plugin-Verzeichnisses verweisen. Bei Clustern mit Shamir-Seals und einem externen Plugin-Verzeichnis kann ein privilegierter Operator, der einen Integrated-Storage-(Raft-)Snapshot wiederherstellen darf, unter Umständen beliebigen Code als Dienstbenutzer von Vault auf dem Vault-Host ausführen. Cluster mit Auto-Unseal oder ohne konfiguriertes Plugin-Verzeichnis sind nicht betroffen.
Betroffen
- HashiCorp Vault Community Edition bis 2.1.1
- HashiCorp Vault Enterprise bis 2.1.1 (genaue Bereiche für die Linien 1.19, 1.20 und 1.21 sind in den geprüften Quellen vom Hersteller nicht bestätigt)
- Nur Shamir-versiegelte Cluster mit konfiguriertem externem Plugin-Verzeichnis sind betroffen
Behoben in
- Vault Community Edition 2.1.2
- Vault Enterprise 2.1.2, 1.21.12, 1.20.17 und 1.19.23
Umgehung
- Keine offizielle Workaround des Herstellers über das Patchen hinaus.
- Cluster mit Auto-Unseal oder ohne konfiguriertes Plugin-Verzeichnis sind nicht betroffen.
- Snapshot-Wiederherstellungsrechte auf sehr wenige vertrauenswürdige Operatoren beschränken und deren Zuweisung prüfen.
- Externe Plugins innerhalb des Plugin-Verzeichnisses halten und den Plugin-Katalog nach jeder Wiederherstellung überprüfen.
Ausnutzung
- CISA SSVC: Exploitation none, nicht automatisierbar, totale technische Auswirkung.
- In den geprüften Quellen nicht als aktiv ausgenutzt markiert.
- Kein öffentlicher Proof of Concept gefunden.
Unsere Empfehlung
- Prüfen, ob Vault-Instanzen mit Shamir-Seals und gesetztem plugin_directory betrieben werden.
- Vault-Versionen auf allen Knoten erfassen, einschliesslich Standbys und Enterprise-Performance- und DR-Sekundärsystemen.
- Alle Knoten auf die fixe Version der jeweiligen Linie aktualisieren. Plugins, die nach dem Update abgelehnt werden, mit Binaries innerhalb des Plugin-Verzeichnisses neu registrieren.
- Prüfen, wer Snapshots wiederherstellen kann, und den Plugin-Katalog überprüfen.
- Das HashiCorp-Bulletin HCSEC-2026-41 und den NVD-Eintrag auf Aktualisierungen überwachen.
Öffentliche Exploits
In PoC-in-GitHub, Metasploit und Exploit-DB ist für diese CVE nichts verzeichnet.
Quellen der Recherche
- HashiCorp HCSEC-2026-41 bulletin discuss.hashicorp.com
- IBM Security Bulletin www.ibm.com
- OSV record CVE-2026-105816 osv.dev
- OpenCVE CVE record app.opencve.io
- HCSEC remediation mirror cve.imfht.com
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 01.11.2026 21:31.
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.