Sicherheitslücke in HashiCorp Vault ermöglicht Angreifern die Anmeldung ohne Zugangsdaten

Eine neue Sicherheitslücke in HashiCorp Vault ermöglicht es Angreifern, die LDAP-Authentifizierung vollständig zu umgehen.

Verfasst von
Ken Underhill
Ken Underhill
Nov 25, 2025
3 minute read
eSecurity Planet Inhalte und Produktempfehlungen sind redaktionell unabhängig. Wir können Geld verdienen, wenn Sie auf Links zu unseren Partnern klicken. Mehr erfahren

Eine neue Schwachstelle im HashiCorp Vault Terraform Provider könnte Angreifern ermöglichen, sich ohne Zugangsdaten zu authentifizieren und dadurch auf vertrauliche Geheimnisse und Infrastrukturdaten zuzugreifen.

Die Schwachstelle geht auf eine falsch konfigurierte Standardeinstellung in den LDAP-Authentifizierungseinstellungen des Providers zurück.

„Wenn der zugrunde liegende LDAP-Server anonyme oder nicht authentifizierte Bindungen zuließ, konnte dies zu einer Umgehung der Authentifizierung führen“, erklärte HashiCorp in seiner Stellungnahme.

Die Sicherheitslücke durch die LDAP-Fehlkonfiguration in Vault

Die Sicherheitslücke (CVE-2025-13357) geht auf ein fehlerhaftes Standardverhalten bei der Verarbeitung des Parameters deny_null_bind für die LDAP-Authentifizierung im Vault Terraform Provider zurück.

In betroffenen Versionen war der Parameter standardmäßig auf false gesetzt, wenn er in einer Terraform-Konfiguration nicht ausdrücklich festgelegt wurde.

In Umgebungen, in denen der zugrunde liegende LDAP-Server anonyme oder Null-Bindungen zuließ, entstand dadurch ein unbemerkter und gefährlicher Zustand: Vault behandelte ein leeres Passwort als gültigen Authentifizierungsversuch.

Wenn der Terraform Provider mit dem Standardparameter ein LDAP-Auth-Backend erstellte oder aktualisierte, akzeptierte Vault nicht authentifizierte LDAP-Verbindungen und ermöglichte es Angreifern, sich ohne Zugangsdaten zu authentifizieren.

Diese Fehlkonfiguration erstreckte sich auf Umgebungen, die über Infrastructure as Code (IaC) verwaltet wurden. Dadurch konnten mehrere Vault-Cluster oder Namespaces die unsichere Einstellung unbemerkt übernehmen.

HashiCorp bestätigte, dass die Schwachstelle den Terraform Provider von Version 4.2.0 bis einschließlich 5.4.0 betrifft sowie Vault-Versionen, die vor der Behebung weiterhin leere Passwörter akzeptierten.

Zwar gibt es keine bestätigten Fälle einer aktiven Ausnutzung, doch wäre ein Proof of Concept in Umgebungen, die anonyme LDAP-Bindungen zulassen, problemlos umzusetzen.

Advertisement

So sichern Sie Ihre Vault-Bereitstellungen

Da Vault als zentrale Ablage für Geheimnisse und Verschlüsselungsmaterial dient, ist die Behebung dieser Sicherheitslücke entscheidend, um unbefugten Zugriff und nachgelagerte Kompromittierungen zu verhindern.

  • Führen Sie ein Upgrade auf die neuesten Versionen von Vault und dem Terraform Provider durch.
  • Setzen Sie explizit deny_null_bind = true in allen LDAP-Authentifizierungskonfigurationen, um nicht authentifizierte oder anonyme Bindungen in jeder Umgebung zu verhindern.
  • Deaktivieren Sie anonyme Bindungen direkt auf dem LDAP-Server, damit der Verzeichnisdienst keine Authentifizierungsversuche mit Null- oder leeren Passwörtern akzeptieren kann.
  • Beschränken und segmentieren Sie den Netzwerkzugriff auf die LDAP-Authentifizierungsendpunkte von Vault mithilfe von Firewall-Regeln, ACLs und Least-Privilege-Konnektivitätskontrollen.
  • Prüfen und härten Sie LDAP-Authentifizierungs-Backends und Vault-Richtlinien, um sicherzustellen, dass keine unsicheren Standardeinstellungen fortbestehen, und um die mit LDAP-basierten Anmeldungen verbundenen Berechtigungen zu minimieren.
  • Überwachen Sie verdächtige Authentifizierungsaktivitäten wie Versuche mit leeren Passwörtern, die unerwartete Erstellung von Tokens oder ungewöhnliche Anmeldemuster bei Vault.
  • Stärken Sie die Betriebssicherheit rund um Vault durch die regelmäßige Erneuerung von Zugangsdaten und Tokens, die Durchsetzung von MFA für Rollen mit hohen Berechtigungen, die Überprüfung des Terraform-Status auf Abweichungen und die feste Vorgabe von Provider-Versionen.

Die Behebung der Schwachstelle erfordert eine Kombination aus Softwareupdates, Konfigurationsänderungen und verbesserten betrieblichen Verfahren, um eine sichere Authentifizierung zu gewährleisten.

Warum Geheimnisse und Identitätsebenen bevorzugte Ziele sind

Dieser Vorfall zeigt, wie eine scheinbar geringfügige Fehlkonfiguration in Infrastructure-as-Code-Tools zu einem schwerwiegenden Authentifizierungsfehler eskalieren und ganze Organisationen beeinträchtigen kann.

Da Unternehmen Sicherheits- und Identitätsabläufe zunehmend automatisieren, wird die Zuverlässigkeit von Standardeinstellungen in Tools wie Terraform Providern immer wichtiger.

Die Vault-Sicherheitslücke spiegelt zudem einen größeren Trend wider: Angreifer nehmen zunehmend die Identitäts- und Geheimnisebenen von Cloud-Umgebungen ins Visier, in denen bereits eine einzige Fehlkonfiguration weitreichenden Zugriff mit hohen Berechtigungen ermöglichen kann.

Dieser zunehmende Druck auf die Identitätsinfrastruktur macht Zero-Trust-Prinzipien zur Verringerung der Auswirkungen von Fehlkonfigurationen unerlässlich.

Ken Underhill

Ken Underhill is an award-winning cybersecurity professional, bestselling author, and seasoned IT professional. He holds a graduate degree in cybersecurity and information assurance from Western Governors University and brings years of hands-on experience to the field.

eSecurity Planet Logo

eSecurity Planet is a leading resource for IT professionals at large enterprises who are actively researching cybersecurity vendors and latest trends. eSecurity Planet focuses on providing instruction for how to approach common security challenges, as well as informational deep-dives about advanced cybersecurity topics.

Eigentum von TechnologyAdvice. © 2026 TechnologyAdvice. Alle Rechte vorbehalten

Werbetreibenden-Offenlegung: Einige der auf dieser Website erscheinenden Produkte stammen von Unternehmen, von denen TechnologyAdvice eine Vergütung erhält. Diese Vergütung kann beeinflussen, wie und wo Produkte auf dieser Website erscheinen, einschließlich beispielsweise der Reihenfolge, in der sie erscheinen. TechnologyAdvice schließt nicht alle Unternehmen oder alle auf dem Marktplatz verfügbaren Produkttypen ein.