Splunk warnt vor einer kritischen Schwachstelle in Splunk Enterprise. Die Lücke CVE-2026-20253 erreicht einen CVSS Wert von 9.8 und betrifft bestimmte Versionen von Splunk Enterprise 10.0 und 10.2. Splunk beschreibt den Fehler in einem Advisory vom 10. Juni 2026 als unauthentifizierte Dateioperation über einen PostgreSQL-Sidecar-Service. In der Security Praxis ist der Vorfall kritisch, weil externe Angreifer ohne Zugangsdaten Dateien auf erreichbaren Systemen erstellen oder kürzen können.
Mehrere Sicherheitsberichte stufen das Risiko als mögliche Remote Code Execution ein. Splunk selbst formuliert enger und spricht von „arbitrary file creation and truncation“. Diese Unterscheidung ist wichtig: Die offizielle Primärquelle bestätigt unauthentifizierte Dateioperationen. Die RCE-Gefahr ergibt sich aus möglichen Folgewirkungen in anfälligen Umgebungen.
Splunk patcht CVE-2026-20253 in Enterprise 10.0 und 10.2
CVE-2026-20253 steckt im PostgreSQL Sidecar Service Endpoint von Splunk Enterprise. Laut Splunk fehlt dort eine Authentifizierungskontrolle. Ein netzwerkseitig erreichbarer Angreifer kann dadurch Dateioperationen ohne gültige Zugangsdaten auslösen. Der CVSS-Vektor lautet AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Das bedeutet: Netzwerkangriff, niedrige Komplexität, keine Anmeldung, keine Nutzerinteraktion und hohe Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit.
Betroffen sind Splunk Enterprise 10.2.0 bis 10.2.3 und Splunk Enterprise 10.0.0 bis 10.0.6. Splunk Enterprise 10.4 ist laut Status nicht betroffen. Splunk Enterprise 9.4 und 9.3 sind ebenfalls nicht betroffen. Admins sollten trotzdem ihre genaue Version prüfen, weil Splunk die Produktliste am 15. Juni zur Klarstellung ergänzt hat.
Die empfohlenen Fix-Versionen sind Splunk Enterprise 10.4.0, 10.2.4 und 10.0.7 oder neuer. Splunk Cloud ist nach dem aktuellen Advisory nicht betroffen. Splunk entfernte frühere Hinweise auf Splunk Cloud am 12. Juni, da Postgres Sidecars dort nicht genutzt werden.
Was Admins jetzt bei Splunk Enterprise prüfen sollten
Die wichtigste Maßnahme ist ein Update auf eine behobene Version. Unternehmen sollten zuerst öffentlich erreichbare Splunk-Instanzen, Management-Ports, interne Netzsegmente und Systeme mit PostgreSQL-Sidecar-Funktion prüfen. Besonders kritisch sind Instanzen mit direkter Netzwerkerreichbarkeit aus weniger vertrauenswürdigen Zonen.
Splunk nennt zusätzlich eine Übergangsmaßnahme. Admins können den PostgreSQL-Sidecar-Service über server.conf deaktivieren. Danach ist ein Neustart von Splunk Enterprise nötig. Diese Maßnahme ist nicht für jede Umgebung geeignet. Splunk warnt ausdrücklich, dass Edge Processor, OpAmp und SPL2-Datenpipelines dadurch brechen können. Core Search, Indexing und Dashboards sollen laut Splunk nicht betroffen sein.
Für Incident Response zählt der Zeitbezug. Das Advisory erschien am 10. Juni 2026. Die Mitigation und zusätzliche Klarstellungen kamen am 15. Juni 2026 hinzu. Teams sollten deshalb prüfen, ob zwischen Veröffentlichung und Patch verdächtige Dateiänderungen, Prozessstarts, Service-Neustarts oder ungewöhnliche Sidecar-Aktivitäten aufgetreten sind.
Splunk nennt im Advisory keine eigenen Erkennungsregeln. Das erhöht den Druck auf lokale Logs, EDR-Telemetrie und Netzwerkdaten. Admins sollten die betroffenen Splunk-Hosts nicht nur patchen, sondern auch auf nachgelagerte Anzeichen einer Manipulation prüfen. Der Fall zeigt erneut, warum Monitoring-Systeme selbst als hochkritische Infrastruktur gelten: Ein kompromittiertes Analysewerkzeug kann Angreifern besonders wertvollen Zugriff auf Protokolle, Systeme und interne Abläufe geben.