CVE-2026-20253: Pre-Auth RCE in Splunk Enterprise ueber PostgreSQL sidecar

Splunk hat ausserplanmaessige Sicherheitsupdates veroeffentlicht, um die kritische Schwachstelle CVE-2026-20253 mit einem CVSS-Score von 9.8 im Produkt Splunk Enterprise zu beheben. Die Schwachstelle ermoeglicht es einem nicht authentifizierten Angreifer, ueber einen ungeschuetzten PostgreSQL-sidecar-Endpunkt beliebige Dateien anzulegen und zu kuerzen, was sich nach Angaben der Forscher von watchTowr Labs zu einer vollwertigen Remote Code Execution (RCE) ohne vorherige Authentifizierung ausbauen laesst. Betroffen sind die Versionen 10.0.0–10.0.6 und 10.2.0–10.2.3; Fixes stehen in den Versionen 10.0.7 und 10.2.4 zur Verfuegung. Splunk Cloud ist nicht verwundbar. Angesichts der Veroeffentlichung technischer Exploit-Details sollte das Update als vorrangige Aufgabe betrachtet werden.

Kern der Schwachstelle

Laut dem offiziellen Splunk-Sicherheitsbulletin liegt die eigentliche Ursache des Problems in der vollstaendigen Abwesenheit von Authentifizierung am PostgreSQL-sidecar-Endpunkt. Jeder Benutzer, der Netzwerkzugriff auf eine verwundbare Instanz von Splunk Enterprise hat, kann Dateisystemoperationen ausloesen, ohne Zugangsdaten angeben zu muessen. Der Hersteller formuliert es so: Ein nicht authentifizierter Benutzer kann ueber den Service-Endpunkt des PostgreSQL sidecar beliebige Dateien erstellen oder kuerzen.

Betroffene und behobene Versionen:

• Splunk Enterprise 10.0.0–10.0.6 — behoben in Version 10.0.7
• Splunk Enterprise 10.2.0–10.2.3 — behoben in Version 10.2.4
• Splunk Enterprise 10.4 — nicht betroffen
• Splunk Cloud — nicht betroffen (PostgreSQL sidecar wird im Cloud-Produkt nicht verwendet)

Exploitchain: von Dateischreibzugriff bis RCE

Die Forscher Piotr Bazydlo und Yordan Ganchev von watchTowr Labs haben eine detaillierte technische Analyse veroeffentlicht, die den Weg von einem primitiven Dateischreibzugriff bis hin zur vollstaendigen Ausfuehrung beliebigen Codes beschreibt. Wichtig ist: Im Hersteller-Bulletin wird die Moeglichkeit nicht authentifizierter Dateisystemoperationen bestaetigt, waehrend die vollstaendige RCE-Kette von den Forschern beschrieben wird und bislang nicht unabhaengig bestaetigt ist.

Nach Angaben der Forscher nutzt der Angriff zwei Endpunkte:

• /v1/postgres/recovery/backup — zum Verbinden mit einer vom Angreifer kontrollierten Datenbank und zum Ablegen ihres Inhalts in einer beliebigen Datei im Splunk-Dateisystem
• /v1/postgres/recovery/restore — zum Laden eines boesartigen Dumps in die lokale PostgreSQL-Instanz unter Verwendung des Parameters passfile, der auf die Datei /opt/splunk/var/packages/data/postgres/.pgpass verweist, welche das Passwort des Benutzers postgres_admin enthaelt

Ein zentrales Element des Angriffs besteht darin, dass SQL-Queries, die in den Datenbankdump eingebettet sind, von der PostgreSQL-Instanz waehrend des Restore-Vorgangs ausgefuehrt werden. Dies ermoeglicht es dem Angreifer, eine benutzerdefinierte Funktion zu definieren, die lo_export verwendet — einen regulaeren PostgreSQL-Mechanismus zum Export grosser Objekte (BLOB) in Dateien auf dem Datentraeger. Ueber diese Funktion erhaelt der Angreifer einen primitiven, aber kontrollierten Schreibzugriff fuer beliebige Inhalte auf das Dateisystem.

Zur Eskalation bis hin zur Codeausfuehrung reicht es laut watchTowr Labs aus, ein Python-Skript zu ueberschreiben, das von Splunk regelmaessig ausgefuehrt wird — etwa /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py. Nach dem Ueberschreiben wird der boesartige Code im Kontext des Splunk-Prozesses ausgefuehrt.

Vollstaendige Abfolge des Angriffs

1. Der Angreifer erstellt eine externe PostgreSQL-Datenbank mit einer Konfiguration, die eine Authentifizierung ohne Passwort zulaesst, und raeumt ausreichende Privilegien fuer Aufrufe von Funktionen wie CREATE FUNCTION und lo_export ein.
2. Ueber den Endpunkt /backup wird der Dump dieser Datenbank in das Splunk-Dateisystem geschrieben.
3. Ueber den Endpunkt /restore wird der boesartige Dump in die lokale PostgreSQL-Instanz geladen; beim Restore wird die boesartige Funktion ausgefuehrt, die ein vom Angreifer kontrolliertes Python-Skript auf die Festplatte schreibt.

Bewertung der Auswirkungen

Splunk Enterprise ist eine der am weitesten verbreiteten SIEM-Plattformen und wird zur Aggregation und Analyse von Sicherheitslogs in Organisationen jeder Groessenordnung eingesetzt. Die Kompromittierung eines SIEM-Systems stellt eine besondere Bedrohung dar: Ein Angreifer erlangt nicht nur die Kontrolle ueber den Server, sondern potenziell auch Zugriff auf die Sicherheitsprotokolle der gesamten Infrastruktur, was fuer die Planung weiterer Angriffe und das Vertuschen von Spuren genutzt werden kann.

Der CVSS-Score von 9.8 spiegelt die Kritikalitaet wider: Der Angriff erfordert keine Authentifizierung, kann remote ausgefuehrt werden und fuehrt zu einer vollstaendigen Kompromittierung von Vertraulichkeit, Integritaet und Verfuegbarkeit. Am staerksten gefaehrdet sind Organisationen, deren Splunk-Enterprise-Instanzen aus nicht vertrauenswuerdigen Netzsegmenten erreichbar sind.

Zum Zeitpunkt der Veroeffentlichung wurden keine bestaetigten Ausnutzungen in realen Angriffen festgestellt, und die Schwachstelle ist nicht im CISA-KEV-Katalog aufgefuehrt. Die Veroeffentlichung einer detaillierten technischen Beschreibung der Exploit-Kette erhoeht jedoch die Wahrscheinlichkeit opportunistischer Angriffe in den kommenden Tagen erheblich.

Empfehlungen

• Aktualisieren Sie umgehend Splunk Enterprise auf Version 10.0.7 bzw. 10.2.4, je nach verwendeter Branch
• Beschraenken Sie den Netzwerkzugang zu den Endpunkten /v1/postgres/recovery/backup und /v1/postgres/recovery/restore mittels Netzsegmentierung und Firewalls — als temporaere Massnahme bis zum Update
• Pruefen Sie die Integritaet der Python-Skripte im Verzeichnis /opt/splunk/etc/apps/, insbesondere der Datei ssg_enable_modular_input.py, auf unbefugte Aenderungen
• Analysieren Sie die Zugriffslogs des PostgreSQL sidecar auf Aufrufe der genannten Endpunkte von nicht autorisierten Quellen
• Wenn Sie Splunk Enterprise in Version 10.4 oder Splunk Cloud verwenden, ist kein Update erforderlich, da diese Produkte nicht betroffen sind

Die Kombination aus maximaler Kritikalitaet (CVSS 9.8), fehlender Notwendigkeit einer Authentifizierung und der oeffentlich verfuegbaren Beschreibung der vollstaendigen Exploit-Kette macht CVE-2026-20253 zu einer der prioritaeren Schwachstellen fuer eine sofortige Behebung. Organisationen, die die betroffenen Versionen von Splunk Enterprise einsetzen, sollten die Updates im Rahmen eines ausserplanmaessigen Notfall-Patchingzyklus einspielen, ohne auf das naechste Wartungsfenster zu warten, und den PostgreSQL sidecar bis zum Update von nicht vertrauenswuerdigen Netzen isolieren.