Die Splunk-Lücke, die ohne Login Dateien löscht
Eine kritische Lücke in Splunk Enterprise lässt Angreifer ohne Anmeldung Dateien auf dem Server anlegen und löschen. Die US-Behörde CISA führt sie seit dem 18. Juni als aktiv ausgenutzt. Über 1.400 Instanzen stehen weltweit offen im Netz, 223 davon in Europa.
Das Wichtigste in Kürze
- CVSS 9,8, kein Login nötig. Die Schwachstelle CVE-2026-20253 sitzt im PostgreSQL-Sidecar von Splunk Enterprise und erlaubt das Anlegen und Löschen von Dateien ohne Authentifizierung.
- Die Angriffe laufen bereits. Nach dem öffentlichen Exploit-Code vom 12. Juni setzte die CISA die Lücke am 18. Juni auf ihre Liste aktiv ausgenutzter Schwachstellen, mit Patch-Frist zum 21. Juni für US-Bundesbehörden.
- Der Notbehelf kostet Funktionen. Wer nicht sofort patchen kann, schaltet den PostgreSQL-Sidecar ab und verliert damit Edge Processor, OpAmp und die SPL2-Datenpipelines.
Verwandt:Patch-Priorisierung: Warum CVSS allein dein SOC bremst / Detection-Engineering ohne Vendor-Lock
Was die Lücke technisch möglich macht
Was ist CVE-2026-20253? Eine kritische Schwachstelle im PostgreSQL-Sidecar von Splunk Enterprise. Sie umgeht die Authentifizierung, sodass Angreifer ohne Anmeldung Dateien auf dem Server anlegen und löschen können. Der CVSS-Wert liegt bei 9,8 von 10.
Splunk Enterprise betreibt seit einigen Versionen einen PostgreSQL-Sidecar. Dieser Dienst läuft neben dem eigentlichen Splunk-Prozess und versorgt unter anderem den Edge Processor, das Telemetrie-Protokoll OpAmp und die SPL2-Datenpipelines mit einer relationalen Datenbank. Genau dort sitzt der Fehler.
CVE-2026-20253 ist eine fehlende Authentifizierungsprüfung. Ein Angreifer muss sich nicht anmelden, kein Konto besitzen, keine gültige Session vorweisen. Er kann über den exponierten Dienst Dateien auf dem System anlegen und löschen.
Das klingt harmloser als eine klassische Remote-Code-Execution. Das Schadenspotenzial ist trotzdem hoch. Wer ohne Anmeldung Dateien anlegen und löschen kann, ist in der Lage, Komponenten lahmzulegen oder Protokolle zu entfernen. Je nach Umgebung lässt sich ein solcher Zugriff zu weitergehenden Angriffen ausbauen. Der CVSS-Wert von 9,8 von 10 ordnet die Lücke entsprechend als kritisch ein, vor allem wegen der einfachen Ausnutzbarkeit ohne Authentifizierung.
Vom Proof-of-Concept zur aktiven Ausnutzung
Die Eskalation lief in wenigen Tagen ab. Das Splunk Product Security Incident Response Team bestätigte erste Angriffe bereits Anfang Juni. Den Wendepunkt markierte ein öffentlich veröffentlichter Proof-of-Concept.
Sechs Tage zwischen öffentlichem Exploit und KEV-Eintrag sind ein knappes Fenster. Sobald ein Proof-of-Concept kursiert, sinkt die Hürde für Massenscans gegen exponierte Systeme drastisch. Wer auf den nächsten regulären Wartungszyklus wartet, plant zu langsam.
Wie viele Systeme jetzt offen stehen
Splunk sammelt Logs aus dem gesamten Netzwerk und ist deshalb häufig breit angebunden. Ein Teil der Instanzen hängt direkt am Internet, oft aus Bequemlichkeit bei verteilten Standorten.
Jede dieser exponierten Instanzen ist ein direktes Ziel. Auch intern erreichbare Server bleiben angreifbar, sobald jemand im Netz steht, etwa nach einem Phishing-Treffer. Die Internet-Exposition gehört zuerst geschlossen, die internen Instanzen direkt danach.
Patchen, abschalten oder isolieren
Die Priorität ist eindeutig. Splunk stellt einen Patch bereit. Welche Builds betroffen sind und ab welcher Version die Lücke geschlossen ist, nennt das Splunk-Security-Advisory zu CVE-2026-20253. Wer Splunk Enterprise betreibt, gleicht den eigenen Versionsstand damit ab und spielt das Update ein. Das ist die einzige Maßnahme, die die Lücke wirklich schließt.
Ist ein sofortiges Update nicht möglich, bleibt der Notbehelf: den PostgreSQL-Sidecar abschalten. Das stoppt den verwundbaren Dienst, hat aber einen Preis. Edge Processor, OpAmp und die SPL2-Datenpipelines fallen aus. Für viele Umgebungen ist das ein spürbarer Funktionsverlust, der nur als Übergang taugt.
Unabhängig vom Patch-Stand gehört die Internet-Exposition auf den Prüfstand. Ein SIEM hat in den seltensten Fällen einen Grund, offen am Internet zu hängen. Wer den Zugriff auf interne Netze und ein VPN beschränkt, verkleinert die Angriffsfläche sofort.
- Sofort: Versionsstand prüfen, Patch einspielen.
- Wenn kein Patch möglich: PostgreSQL-Sidecar deaktivieren, Funktionsausfall einplanen.
- In jedem Fall: Internet-Exposition prüfen, Zugriff auf VPN und interne Netze begrenzen.
- Danach: Logs auf unerwartete Datei-Operationen und gelöschte Einträge sichten.
Warum das SIEM ein besonders heikles Ziel ist
Auf den Logs des SIEM beruht jede Erkennungsregel. Es sammelt die Protokolle des gesamten Netzwerks an einer Stelle. Fällt diese Plattform aus oder wird sie manipuliert, verliert das SOC seine wichtigste Sichtquelle.
Die Möglichkeit, Dateien zu löschen, verschärft das. Ein Angreifer, der Protokolle entfernt, verwischt seine Spuren genau dort, wo sie sonst auffallen würden. Eine Lücke im Detektionssystem ist deshalb gefährlicher als dieselbe Lücke auf einem Randsystem. Sie trifft die Instanz, die den Angriff eigentlich melden soll.
Für die Praxis heißt das: Diese Schwachstelle ist kein gewöhnlicher Patch unter vielen. Sie betrifft die Komponente, von der die Glaubwürdigkeit aller anderen Alarme abhängt.
Häufige Fragen
Jede Frage ist verschlossen. Ein Tippen entriegelt die Antwort.
Was genau erlaubt CVE-2026-20253?
Die Lücke im PostgreSQL-Sidecar von Splunk Enterprise umgeht die Authentifizierung. Ein Angreifer kann ohne gültige Anmeldedaten Dateien auf dem System anlegen und löschen. Damit lassen sich je nach Umgebung Komponenten lahmlegen oder Protokolle entfernen.
Sind DACH-Unternehmen betroffen, obwohl die CISA-Frist nur US-Behörden gilt?
Ja. Die CISA-Frist verpflichtet nur US-Bundesbehörden, das technische Risiko ist überall identisch. Splunk ist in vielen DACH-SOCs im Einsatz und die 223 in Europa exponierten Instanzen zeigen, dass auch hier Systeme offen stehen. Wer Splunk betreibt, behandelt den 21. Juni am besten als eigenen Stichtag.
Was tun, wenn sofortiges Patchen nicht möglich ist?
Splunk empfiehlt als Übergang, den PostgreSQL-Sidecar-Dienst abzuschalten. Damit ist der verwundbare Dienst gestoppt, allerdings fallen Edge Processor, OpAmp und die SPL2-Datenpipelines aus. Diese Maßnahme ist nur als Notlösung gedacht, bis der Patch eingespielt ist.
Wie erkenne ich, ob meine Splunk-Instanz exponiert ist?
Der schnellste Indikator ist die Erreichbarkeit von außen: Prüfen Sie, ob der PostgreSQL-Sidecar-Dienst aus dem Internet oder aus nicht vertrauenswürdigen Segmenten antwortet. Da seit dem 12. Juni ein öffentlicher Exploit kursiert, ist jede exponierte Instanz akut gefährdet. Konkrete Erkennungsregeln auf Basis bestätigter Angriffsmuster nennt das Splunk-Advisory; ergänzend lohnt der Blick in die Logs auf unerwartete Datei-Operationen.
Warum ist eine Lücke im SIEM besonders kritisch?
Das SIEM liefert die Protokolle für jede Erkennung. Wird es manipuliert, fehlt dem Security-Team die Sicht auf das eigene Netz. Da die Lücke auch das Löschen von Dateien erlaubt, kann ein Angreifer seine Spuren genau dort entfernen, wo sie auffallen müssten.
Lesetipps der Redaktion
LesetippOracle PeopleSoft: aktiv ausgenutzte Lücke, CISA warntLesetippSIEM und XDR verschmelzen – was bleibt für Teams?LesetippLinux-Kernel-Lücken: BSI warnt vor Root-Eskalation
Mehr aus dem MBF Media Netzwerk
cloudmagazinNIS2 und DORA sauber trennen: Compliance-Cluster in KubernetesMyBusinessFutureNIS2-Umsetzung: Checkliste für den Mittelstand jetztDigital ChiefsManaged Security Services: CISO haftet nicht allein
