CVE-2024-31391 in Solr Operator
Zusammenfassung
von VulDB • 15.05.2026
Ein Schwachstellen-Typ „Insertion of Sensitive Information into Log File“ (Einfügen sensibler Informationen in Protokolldateien) im Apache Solr Operator.
Dieses Problem betrifft alle Versionen des Apache Solr Operator von 0.3.0 bis 0.8.0.
Wenn der Operator aufgefordert wird, die Solr-Sicherheit zu initialisieren (Bootstrap), aktiviert er die Basisauthentifizierung und erstellt mehrere Konten für den Zugriff auf Solr: darunter die Konten „solr“ und „admin“ für die Nutzung durch Endbenutzer sowie ein Konto „k8s-oper“, das der Operator für seine eigenen Anfragen an Solr verwendet. Eine häufige Quelle dieser Operator-Anfragen sind Healthchecks: Liveness-, Readiness- und Startup-Probes werden verwendet, um den Gesundheitszustand von Solr und dessen Fähigkeit zum Empfangen von Datenverkehr zu bestimmen. Standardmäßig konfiguriert der Operator die für diese Proben verwendeten Solr-APIs so, dass sie von der Authentifizierung ausgenommen sind, aber Benutzer können explizit anfordern, dass auch für die Probe-Endpunkte eine Authentifizierung erforderlich ist. Wenn einer dieser Proben fehlschlägt und die Authentifizierung aktiviert ist, erstellt der Solr Operator ein Kubernetes „Event“, das den Benutzernamen und das Passwort des Kontos „k8s-oper“ enthält.
Im betroffenen Versionsbereich betrifft diese Schwachstelle jede solrcloud-Ressource, die (1) die Sicherheit durch Verwendung der Option `.solrOptions.security.authenticationType=basic` initialisiert hat und (2) die Authentifizierung für Proben durch Festlegen von `.solrOptions.security.probesRequireAuth=true` erforderlich macht.
Benutzern wird empfohlen, auf Solr Operator Version 0.8.1 zu aktualisieren, die dieses Problem behebt, indem sichergestellt wird, dass Proben keine Anmeldeinformationen mehr für Solr-Anfragen ausgeben. Benutzer können die Schwachstelle auch abschwächen, indem sie die Authentifizierung für ihre Healthcheck-Proben mit der Einstellung `.solrOptions.security.probesRequireAuth=false` deaktivieren.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.