Splunk Enterprise: Kritische Schwachstelle erlaubt Zugriff auf Suchjobs und Admin-Aktionen

Kurzfassung

Splunk Enterprise hat eine kritische Schwachstelle, die in mehreren Versionen unter den genannten Korrekturen liegt. Betroffen sind Versionen vor 10.4.2, 10.2.6, 10.0.9 und 9.4.14.

Das Risiko ist ernst: Ein nicht angemeldeter Angreifer mit einem eingebetteten Report-Token kann das zugehörige Suchjob-Archiv herunterladen, Sitzungsmaterial rekonstruieren und auf Daten zugreifen, die dem Besitzer des Reports offenstehen. Wenn dieser Besitzer die Splunk-Rolle admin hat, sind auch administrative Aktionen möglich.

Was ist passiert?

Die Lücke sitzt in der Art, wie Splunk Enterprise mit eingebetteten Reports und dem Download von Dispatch-Archiven umgeht. Der Zugriff über eingebettete Reports blockiert bestimmte REST-API-Anfragen für diese Archive nicht. Genau diese Lücke im Zugriffspfad macht den Angriff möglich.

Praktisch heißt das: Ein Token, das eigentlich nur den Zugriff auf einen eingebetteten Report erlauben soll, kann in die falsche Richtung weiterhelfen. Daraus lässt sich mehr lesen, als der Betreiber erwartet hat. Im ungünstigsten Fall landet der Angreifer bei Daten, die eigentlich nur für den Report-Besitzer gedacht sind.

Technische Details

Splunk ordnet das Problem als kritisch ein. Der Kern ist kein klassischer Login-Fehler, sondern ein Autorisierungsproblem rund um REST-API-Requests für Search-Job-Dispatch-Archive.

Ausgenutzt wird ein unauthentisierter Zugriff mit vorhandenem Embedded-Report-Token. Die Folge kann sein, dass ein Angreifer das Archiv eines Suchjobs herunterlädt und daraus Session-Material gewinnt. Mit diesem Material lassen sich dann Daten und Systemfunktionen missbrauchen, die an die Rechte des Report-Besitzers gekoppelt sind.

Besonders heikel wird es, wenn der Besitzer des Reports die Splunk-Rolle admin trägt. Dann kann der Angriff laut Beschreibung bis zu administrativen Aktionen reichen. Ob auch weitere Rollen ähnliche Folgen haben, geht aus der Quelle nicht hervor.

Wer ist betroffen?

Betroffen sind Splunk-Enterprise-Installationen unterhalb der Versionen 10.4.2, 10.2.6, 10.0.9 und 9.4.14. Die Quelle nennt keine anderen Produkte.

Für Unternehmen im DACH-Raum ist das vor allem dann relevant, wenn Splunk als zentrales SIEM, für Monitoring oder für Auswertungen mit eingebetteten Reports läuft. Wer Report-Dashboards extern oder intern teilt, sollte die eigene Nutzung sofort prüfen. Je mehr Reports mit weitreichenden Rechten laufen, desto größer der Schaden.

Für Privatnutzer spielt das kaum eine Rolle. Splunk Enterprise ist ein typisches Unternehmensprodukt.

Empfohlene Maßnahmen

Wer Splunk Enterprise betreibt, sollte zuerst die Version prüfen und auf eine der korrigierten Fassungen aktualisieren: 10.4.2, 10.2.6, 10.0.9 oder 9.4.14. Das hat Priorität eins.

Danach gehören eingebettete Reports auf den Prüfstand. Nur dort einsetzen, wo sie wirklich nötig sind. Rechte der Report-Besitzer eng ziehen, vor allem bei Konten mit Admin-Rolle. Wenn ein Report keinen breiten Zugriff braucht, sollte er auch keinen bekommen.

Admins sollten außerdem nachsehen, wo Embedded Reports nach außen oder an viele interne Nutzer freigegeben sind. Logs auf ungewöhnliche Downloads von Dispatch-Archiven und auffällige API-Zugriffe prüfen. Falls ein Token kompromittiert wirkt, sofort rotieren und betroffene Sitzungen beenden.

Einschätzung von CyberSecurity-News.de

Die Schwachstelle ist ernst, weil sie ohne Anmeldung ausnutzbar sein kann und in ein Produkt sitzt, das oft sensible Betriebsdaten sammelt. Wer Splunk als Schaltzentrale für Security- oder Infrastruktur-Daten nutzt, sollte hier nicht abwarten.

Auffällig ist die dünne Lagebeschreibung in der Quelle. Klar ist die technische Richtung, aber nicht, wie leicht sich das in der Praxis massenhaft ausnutzen lässt oder ob bereits Angriffe laufen. Für eine saubere Priorisierung reicht das trotzdem: patchen, Zugriffsmodell prüfen, Embedded Reports härten.

Fazit

CVE-2026-76310 trifft einen empfindlichen Punkt in Splunk Enterprise. Ein scheinbar begrenzter Report-Zugriff kann in weitreichenden Datenzugriff und unter Umständen in Admin-Funktionen kippen.

Wer Splunk Enterprise in einer betroffenen Version betreibt, sollte das Update jetzt einplanen und die Freigaben für eingebettete Reports nicht weiter laufen lassen wie bisher. Das ist keine Lücke für die Schublade.