Elastic Kibana: Autorisierungsumgehung ermöglicht Abfangen von Daten anderer Mandanten

Zusammenfassung

Die Fleet-Komponente von Kibana erlaubt einem Benutzer mit delegierten Fleet-Paketverwaltungsrechten, aber ohne Elasticsearch-Superuser-Rechte, eine Data-Stream-Kennung zu beanspruchen, die bereits von einem anderen Mandanten (einem Benutzer oder Team auf derselben Kibana-Instanz) verwendet wird. Da die Besitzrechte nicht geprüft werden, kann ein manipuliertes hochgeladenes Paket den Data Stream dieses Mandanten über eine vom Angreifer kontrollierte Infrastruktur umleiten. Der Angreifer kann danach die nachfolgenden Daten des Mandanten einsehen und verändern, und das Abfangen kann auch nach dem Entfernen des Pakets weiterlaufen. Voraussetzung ist ein gültiges Konto mit Fleet-Rechten für benutzerdefinierte Pakete.

Betroffen

• Elastic Kibana 8.14.0 bis 8.19.21
• Elastic Kibana 9.0.0 bis 9.4.6
• Elastic Kibana 9.5.0 bis 9.5.3
• Self-managed und Elastic Cloud Hosted Deployments mit aktiviertem Fleet, bei denen Nicht-Superuser benutzerdefinierte (hochgeladene) Integrationspakete installieren können
• Elastic Cloud Serverless war vor der Offenlegung bereits behoben.

Behoben in

• Kibana 8.19.22
• Kibana 9.4.7
• Kibana 9.5.4
• Spätere Versionen enthalten die Korrektur ebenfalls. Den genauen Build pro Zweig im Advisory ESA-2026-187 prüfen, da eine Sekundärquelle andere Builds (9.4.8, 9.5.5) nennt.

Umgehung

• Die Fleet-Rechte zur Installation benutzerdefinierter Integrationspakete aus allen Rollen entfernen, die Benutzer innehaben, denen die Verwaltung der Daten anderer Mandanten nicht anvertraut werden sollte.
• Das Hochladen benutzerdefinierter Pakete auf vollwertige Superuser beschränken.
• Dieselbe Einschränkung auf Elastic Cloud Hosted über die Rollenverwaltung in Kibana anwenden.

Ausnutzung

• Keine bekannte Ausnutzung in freier Wildbahn.
• CISA SSVC (Vulnrichment): Ausnutzung keine, automatisierbar nein, technische Auswirkung total.
• Zum Zeitpunkt der Recherche nicht im KEV-Katalog aufgeführt.

Unsere Empfehlung

• Kibana zeitnah auf den korrigierten Build des eigenen Release-Zweigs aktualisieren.
• Bis dahin die oben genannten Rechteeinschränkungen anwenden.
• Die Installationshistorie hochgeladener (nicht aus der Registry stammender) Fleet-Pakete auf Datasets prüfen, die bereits von Data Streams verwendet werden, die nicht selbst erstellt wurden.
• Prüfen, ob sich Ingest-Pipelines bestehender Data Streams nach unerwarteten Installationen geändert haben; falls ja, die betroffenen Data Streams separat bereinigen.
• Die Exposition von Kibana begrenzen: Kibana sollte nicht aus dem Internet erreichbar sein, und Fleet-Paketrechte sollten nur an eine kleine Administratorgruppe vergeben werden.
• Elasticsearch gemäss Advisory ESA-2026-185 ebenfalls aktualisieren.

Öffentliche Exploits iAngriffscode ist öffentlich verfügbar (PoC auf GitHub, Metasploit oder Exploit-DB).

In PoC-in-GitHub, Metasploit und Exploit-DB ist für diese CVE nichts verzeichnet.

Quellen der Recherche

• Elastic security advisory ESA-2026-187 discuss.elastic.co
• CVE record (CVE Program / cvelistV5) raw.githubusercontent.com
• Canadian Centre for Cyber Security AV26-1021 www.cyber.gc.ca
• TechGeeks security notice (ESA-187, 191, 193) www.techgeeks.org
• OpenCVE CVE-2026-102406 app.opencve.io
• Strix CVE-2026-102406 www.strix.ai
• OSV BIT-kibana-2026-102406 osv.dev
• DEV Community analysis dev.to

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 31.10.2026 21:41.