Splunk CVE-2026-20253: Unauthentifizierte RCE im PostgreSQL Sidecar

Jeder Platform-Engineer, der Splunk jemals hinter einem internen Load Balancer betrieben hat, verliert gerade sein Wochenende. CVE-2026-20253 ist genau die Art von Disclosure, die aus einem Freitags-Standup ein Notfall-Change-Ticket macht. Ein PostgreSQL Sidecar wurde ohne Authentifizierung ausgeliefert – zwei REST-Endpunkte und ein direkter Pfad von unauthentifiziertem Netzwerkzugriff zu Remote Code Execution als Splunk-Benutzer.

Splunk, inzwischen Teil von Cisco, hat die Fixes diese Woche veröffentlicht. watchTowr Labs folgte am Freitag mit der vollständigen Exploit-Chain. Es gibt bisher keine gemeldeten Angriffe in freier Wildbahn, aber das technische Writeup ist so detailliert, dass opportunistisches Scanning eine Frage von Tagen ist, nicht Monaten.

Was passiert ist

Splunk hat Sicherheitsupdates für eine kritische Schwachstelle in Splunk Enterprise veröffentlicht, die als CVE-2026-20253 verfolgt wird und mit 9,8 auf CVSS bewertet ist. Wie The Hacker News berichtete, ermöglicht der Bug unauthentifizierte Dateioperationen und Remote Code Execution über einen PostgreSQL-Sidecar-Dienst-Endpunkt, dem Authentifizierungskontrollen fehlen.

In Splunks eigenen Worten: „Ein unauthentifizierter Benutzer könnte beliebige Dateien über einen PostgreSQL-Sidecar-Dienst-Endpunkt erstellen oder kürzen" – betroffen sind Versionen unterhalb von 10.2.4 und 10.0.7. Splunk Enterprise 10.0.0 bis 10.0.6 wird in 10.0.7 gepatcht. Die Versionen 10.2.0 bis 10.2.3 werden in 10.2.4 behoben. Version 10.4 ist nicht betroffen. Splunk Cloud ist ebenfalls außerhalb des Geltungsbereichs, da Postgres Sidecars in diesem Produkt nicht verwendet werden.

Die technischen Details stammen von watchTowr Labs, deren Forscher Piotr Bazydlo und Yordan Ganchev die Angriffskette am Freitag veröffentlichten. Die beiden verwundbaren Endpunkte, /v1/postgres/recovery/backup und /v1/postgres/recovery/restore, sind ohne Zugangsdaten exponiert. Von dort verbindet der Angreifer den Backup-Endpunkt mit einer von ihm kontrollierten Datenbank, lädt den Dump auf das Splunk-Dateisystem und spielt ihn über Restore zurück. Der Restore-Schritt akzeptiert ein passfile-Argument, das auf /opt/splunk/var/packages/data/postgres/.pgpass zeigt – dort liegt praktischerweise das Passwort für den postgres_admin-Benutzer.

Das ermöglicht SQL-Ausführung innerhalb der lokalen PostgreSQL-Instanz. Von dort missbraucht ein Angreifer lo_export, um angreiferkontrollierten Inhalt an beliebige Stellen auf der Festplatte zu schreiben. Der finale Schwenk zu RCE ist unkompliziert: Ein Python-Skript überschreiben, das Splunk routinemäßig ausführt – im Proof of Concept ist das die Datei /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py – und warten. Keine Zugangsdaten. Keine Benutzerinteraktion. Kein CVE-Chaining erforderlich.

Technische Analyse

Die Struktur dieses Bugs ist deprimierend vertraut. Ein Team baut einen Microservice mit einer sauberen HTTP-API für internes Orchestrierungsmanagement, geht davon aus, dass die Netzwerkgrenze die Auth-Grenze ist, und liefert aus. Der PostgreSQL Sidecar in Splunk Enterprise ist genau dieses Muster. Backup- und Restore-Endpunkte, die für interne Recovery-Workflows konzipiert wurden, exponiert auf einem Port, der von allem erreichbar ist, was mit dem Splunk-Host kommunizieren kann.

Schritt eins der Angriffskette: Der Angreifer richtet eine PostgreSQL-Instanz ein, die für passwortlose Authentifizierung konfiguriert ist, mit ausreichenden Berechtigungen zum Aufrufen von lo_export. Schritt zwei: /v1/postgres/recovery/backup auf dem Ziel aufrufen und auf die Datenbank des Angreifers zeigen. Splunks Sidecar lädt den Remote-DB-Inhalt bereitwillig auf das lokale Dateisystem. Schritt drei: /v1/postgres/recovery/restore mit dem passfile-Argument aufrufen, das auf die on-disk gespeicherte .pgpass zeigt, was dem Restore-Prozess das Passwort für postgres_admin auf der lokalen Instanz gibt.

Während des Restores wird das SQL innerhalb dieses Dumps gegen das lokale PostgreSQL ausgeführt. Die Forscher erstellten einen Dump, der eine Funktion definiert, die lo_export aufruft – diese extrahiert ein binäres Large Object und schreibt es als Datei. Das gibt einem eine beliebige File-Write-Primitive mit den Rechten des Splunk-PostgreSQL-Prozesses. Wie Bazydlo und Ganchev es formulierten: „Sobald wir angreiferkontrolliertes SQL in die lokale PostgreSQL-Instanz restoren konnten, haben wir schnell ein Datenbank-Dump-Template zusammengestellt, das uns ein kontrolliertes File Write ermöglichte."

Die Eskalation zu RCE ist der einfache Teil. Splunk Secure Gateway führt Python-Skripte nach eigenem Zeitplan aus. ssg_enable_modular_input.py überschreiben, auf die nächste Ausführung warten, und das Payload läuft im Splunk-Kontext. Die gesamte Kette ist mechanisch. Keine Memory Corruption, keine Race Conditions, keine exotischen Primitives. Das ist die Art von Exploit, die innerhalb einer Woche in einem Metasploit-Modul bewaffnet wird. Den Eintrag in der MITRE CVE-Datenbank auf nachgelagerte Advisories verfolgen.

Wer betroffen ist

Splunk Enterprise steht im Mittelpunkt der Detection-Pipelines von Banken, Börsen, iGaming-Betreibern, Ad-Netzwerken und den meisten Fortune-500-SOCs. Das ist der schmerzliche Teil. Das System, dem man vertraut, einem zu melden, wenn etwas Schlimmes passiert, ist selbst das schwache Ziel. Aus Produktionsvorfällen, die ich erlebt habe: Wenn ein Logging- oder Observability-Stack ausfällt, verlieren Blue Teams genau in dem Moment die Sichtbarkeit, in dem sie sie am dringendsten brauchen. Angreifer wissen das. Eine Pre-Auth-RCE in Splunk ist kein Ziel für Credential-Diebstahl; es ist ein „Verteidiger blind machen"-Ziel.

Der CVSS-Score von 9,8 ist kein Marketing. Er entspricht Netzwerk-Angriffsvektor, keine Rechte, keine Benutzerinteraktion und vollständige Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit. Für einen regulierten iGaming-Betreiber, der Splunk als System of Record für Spieleraktivitäten betreibt, bedeutet dieser Score eine Compliance-Feuerwehrübung. Prüfer werden Patch-Zeitpläne, Netzwerkexposition der betroffenen Ports und allfällige anomale Datei-Schreibvorgänge im /opt/splunk/etc/apps/-Verzeichnisbaum wissen wollen.

Teams, die Splunk Cloud betreiben, bleiben hier verschont. Die PostgreSQL Sidecars werden in diesem Produkt nicht verwendet. Alle Nutzer von selbst-gehostetem Enterprise zwischen 10.0.0 und 10.0.6 oder 10.2.0 und 10.2.3 haben Handlungsbedarf. Version-10.4-Deployments können bei diesem CVE entspannt bleiben.

Meine Einschätzung: Die Betreiber, die am härtesten getroffen werden, sind jene, die Splunk als „interne" Infrastruktur behandeln und es nie hinter einen echten Auth-Proxy oder eine Netzwerksegmentierungsrichtlinie gestellt haben. Teams, mit denen ich gearbeitet habe, lassen Indexer- und Management-Ports regelmäßig über flache VLANs erreichbar, weil „es hinter der Firewall ist." Genau diese Annahme bestraft dieses CVE. Wenn Ihr Splunk-Knoten von einem Entwickler-Laptop aus erreichbar ist, ist er auch von einem kompromittierten Entwickler-Laptop aus erreichbar.

Playbook für Security-Teams

Erst patchen, dann untersuchen, dann refaktorisieren. Die unbequeme Wahrheit: Wenn Sie noch 10.0.x oder 10.2.x mit dem exponierten Sidecar betreiben, gehen Sie davon aus, dass das Zeitfenster für opportunistisches Scanning Tage und keine Wochen beträgt. watchTowrs Writeup ist detailliert genug, dass die Exploit-Arbeit im Wesentlichen erledigt ist.

Maßnahmen für diese Woche:

• Splunk Enterprise sofort auf 10.0.7, 10.2.4 oder 10.4 upgraden. Kein Staging-Gate länger als 48 Stunden für Produktions-Indexer.
• Netzwerkexposition der PostgreSQL-Sidecar-Endpunkte prüfen. Die beiden Pfade, nach denen in Firewall- und WAF-Logs gesucht werden sollte: /v1/postgres/recovery/backup und /v1/postgres/recovery/restore.
• Den Inhalt von /opt/splunk/etc/apps/splunk_secure_gateway/bin/ und angrenzenden App-Verzeichnissen hashen und überwachen. Jede unerwartete Änderung an ssg_enable_modular_input.py ist ein Indicator of Compromise.
• Auf unerwartete Dateien prüfen, die unter Pfaden geschrieben wurden, die der Splunk-Benutzer erreichen kann. Der Bug ermöglicht beliebiges File Write, nicht nur das im PoC angezielte Skript.
• Den CISA-KEV-Katalog täglich auf Updates zum aktiven Ausnutzungsstatus prüfen.

Für die nächsten 90 Tage ist die strukturelle Lösung Segmentierung. Splunk-Indexer und Search Heads sollten auf Management-Ports nicht von allgemeinen Unternehmensnetzwerken erreichbar sein. Sie hinter einem Bastion-Host oder Service Mesh platzieren, das mTLS erzwingt. Jeden internen Sidecar standardmäßig als öffentlichen Endpunkt behandeln – denn so wird der nächste Bug dieser Art landen.

Wichtige Erkenntnisse

• CVE-2026-20253 ist eine CVSS-9.8-Pre-Auth-RCE im PostgreSQL Sidecar von Splunk Enterprise. Auf 10.0.7, 10.2.4 oder 10.4 patchen.
• Die Exploit-Chain missbraucht /v1/postgres/recovery/backup und /v1/postgres/recovery/restore sowie lo_export, um beliebiges File Write zu erreichen, und überschreibt dann ein geplantes Python-Skript zur Code-Ausführung.
• Splunk Cloud ist nicht betroffen. Selbst-gehostete Enterprise-Nutzer in den betroffenen Versionsbereichen schon.
• Bisher keine gemeldete Ausnutzung in freier Wildbahn, aber watchTowrs öffentliche technische Details machen opportunistisches Scanning innerhalb von Tagen wahrscheinlich.
• Interne Sidecar-Dienste standardmäßig als nicht vertrauenswürdig behandeln. Netzwerkposition ist keine Authentifizierung – dieses CVE ist der Beweis.