Zum Inhalt springen

Splunk Enterprise: Kritische Lücke im PostgreSQL-Sidecar wird aktiv ausgenutzt

Splunk warnt vor der aktiven Ausnutzung einer kritischen Sicherheitslücke in Splunk Enterprise. Betroffene Systeme lassen sich ohne jegliche Anmeldedaten zur Ausführung von Dateioperationen zwingen, was sich nach Erkenntnissen von Sicherheitsforschern bis zur vollständigen Codeausführung ausbauen lässt. Die US-Behörde CISA hat die Lücke bereits in ihren Katalog aktiv ausgenutzter Schwachstellen aufgenommen.

Was ist passiert

Die Schwachstelle trägt die Kennung CVE-2026-20253 und steckt in einem PostgreSQL-Sidecar-Dienst, der in Splunk Enterprise für Backup- und Wiederherstellungsaufgaben zuständig ist. Der zugehörige Service-Endpunkt prüft beim Aufruf keine Anmeldedaten. Jeder, der den Dienst über das Netzwerk erreichen kann, kann dadurch beliebige Dateien auf dem Splunk-Server anlegen oder kürzen, ganz ohne Benutzerkonto oder Passwort. Splunk veröffentlichte die Schwachstelle am 10. Juni 2026 zusammen mit Patches.

Am 12. Juni legten Analysten von watchTowr nach: Sie veröffentlichten eine technische Analyse sowie funktionierenden Exploit-Code und zeigten, dass sich die Datei-Schreibrechte unter realistischen Bedingungen zu einer vollständigen Remote Code Execution (RCE) ausbauen lassen. Kurz darauf bestätigte das Product Security Incident Response Team von Splunk, dass die Lücke bereits in freier Wildbahn ausgenutzt wird. Am 18. Juni aktualisierte Splunk seine Warnmeldung entsprechend, und CISA nahm die Schwachstelle am selben Tag in ihren KEV-Katalog (Known Exploited Vulnerabilities ) auf, die erste Splunk-Lücke überhaupt auf dieser Liste. US-Bundesbehörden mussten gemäß der neuen Direktive BOD 26-04 bis zum 21. Juni nachbessern.

Technischer Hintergrund

Die Ursache ist eine klassische Authentifizierungslücke (CWE-306 (Common Weakness Enumeration)): Dem PostgreSQL-Sidecar-Endpunkt fehlen jegliche Zugriffskontrollen. Nach Angaben von Splunk genügt es, dass ein Angreifer den Dienst über das Netzwerk erreichen kann, um Dateioperationen ohne Anmeldedaten auszulösen. Die Schwachstelle erhält damit einen CVSS-Basiswert von 9,8 und gilt als kritisch.

Sicherheitsforscher von Rescana berichten als mögliche Hinweise auf eine Kompromittierung unter anderem unerwartete Dateien in Verzeichnissen wie „/tmp/“ oder „/opt/splunk/var/run/supervisor/pkg-run/“, veränderte Python-Skripte in der App splunk_secure_gateway sowie ungewöhnliche ausgehende Verbindungen von Splunk zu unbekannten PostgreSQL-Servern. Eine konkrete Zuordnung der laufenden Angriffe zu einer bestimmten Gruppe liegt bislang nicht vor.

Wer ist betroffen

Betroffen sind Splunk Enterprise in den Versionen 10.2.0 bis 10.2.3 sowie 10.0.0 bis 10.0.6. Splunk Enterprise 9.4 und älter sind laut Hersteller nicht betroffen, ebenso wenig Splunk Cloud Platform, da dort keine PostgreSQL-Sidecars eingesetzt werden.

Nach Daten der Sicherheits-Überwachungsorganisation Shadowserver sind weltweit mehr als 1400 Splunk-Instanzen direkt über das Internet erreichbar. Den Großteil davon verzeichnet Shadowserver in Nordamerika (952 Instanzen) und Europa (223 Instanzen). Wie viele dieser Instanzen tatsächlich verwundbar sind, ist nicht bekannt.

Splunk stellt fehlerbereinigte Versionen bereit. Betroffene Installationen sollten auf 10.2.4, 10.0.7 oder neuere Releases wie 10.4.0 angehoben werden. Für Systeme, die nicht sofort aktualisiert werden können, empfiehlt Splunk als vorübergehende Notlösung das Deaktivieren des PostgreSQL-Sidecar-Dienstes über die Konfigurationsdatei server.conf. Diese Maßnahme verringert die Angriffsfläche, schränkt aber die Funktionalität bestimmter Daten-Pipelines wie Edge Processor, OpAmp oder SPL2 ein.

Handlungsempfehlungen
  • Betroffene Splunk-Enterprise-Installationen umgehend auf Version 10.2.4, 10.0.7 oder höher aktualisieren
  • Ist ein sofortiges Update nicht möglich, den PostgreSQL-Sidecar-Dienst deaktivieren oder den Netzwerkzugriff auf den zugehörigen Port auf localhost beschränken
  • Internetexponierte Splunk-Instanzen identifizieren und priorisiert patchen, insbesondere Management- und Sidecar-Schnittstellen aus dem Internet abschotten
  • Logs auf unautorisierte Dateioperationen, ungewöhnliche Verbindungen zu unbekannten PostgreSQL-Servern und veränderte Konfigurationsdateien prüfen