CVE-2026-20253: Splunk Enterprise Unauthenticated RCE, CVSS 9.8

Diese Woche in unserer InSEKurity of the Week-Serie: eine kritische, unauthentifizierte Remote Code Execution in Splunk Enterprise — der Datenplattform und SIEM-Loesung, die im Herzen unzaehliger Security Operations Center steht und genau jene Logs sammelt, auf die sich Verteidiger verlassen, um Angreifer zu erkennen. Unter der Kennung CVE-2026-20253 gefuehrt und mit CVSS 9.8 (Critical) bewertet, steckt der Fehler in einem PostgreSQL-„Sidecar”-Dienst, der mit neueren Splunk-Versionen ausgeliefert wird. Zwei HTTP-Endpunkte fuer Datenbank-Backup und -Restore werden ohne jegliche Authentifizierung bereitgestellt und erlauben einem entfernten Angreifer, beliebige Dateien zu erstellen und zu ueberschreiben — ein Primitiv, das Forscher zu vollstaendiger Remote Code Execution unter dem Splunk-Dienstkonto ausbauten. Das ist nicht theoretisch: watchTowr Labs hat einen funktionierenden Exploit veroeffentlicht, Splunk hat begrenzte Ausnutzung in freier Wildbahn bestaetigt und CISA hat die Luecke in den Known-Exploited-Vulnerabilities(KEV)-Katalog aufgenommen — mit verbindlicher Frist fuer Bundesbehoerden, womit dies die erste Splunk-Schwachstelle ueberhaupt im KEV-Katalog ist. Wer Splunk Enterprise 10.0 oder 10.2 on-premises betreibt, sollte diese Luecke ganz oben auf die Patch-Liste setzen.

🚨 Zusammenfassung

CVE-ID: CVE-2026-20253
CVSS-Score: 9.8 (Critical)
CVSS-Vektor: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE: CWE-306 (Missing Authentication for Critical Function)
Betroffene Software: Splunk Enterprise (on-premises) — der mitgelieferte PostgreSQL-Sidecar-Dienst, der von Edge Processor, OpAmp und SPL2-Datenpipelines genutzt wird
Angriffsvektor: Netzwerk (entfernt, unauthentifiziert) — praeparierte HTTP-POST-Anfragen an die PostgreSQL-Recovery-Endpunkte backup / restore
Authentifizierung erforderlich: Keine
Benutzerinteraktion: Keine
Auswirkung: Unauthentifiziertes Erstellen/Truncaten beliebiger Dateien, verkettet zu Remote Code Execution unter dem Splunk-Benutzer
Patch-Status: ✅ Behoben in Splunk Enterprise 10.0.7, 10.2.4 und 10.4.0+
Veroeffentlicht: Juni 2026 (Splunk-Advisory SVD-2026-0603)
Ausnutzungsstatus: Aktiv ausgenutzt in freier Wildbahn — oeffentlicher PoC von watchTowr Labs; Splunk PSIRT bestaetigte begrenzte Ausnutzung
CISA KEV: ✅ Gelistet (hinzugefuegt am 18. Juni 2026; FCEB-Frist zum 21. Juni 2026) — die erste Splunk-CVE ueberhaupt

🛡️ Was ist Splunk Enterprise?

Splunk Enterprise ist eine der weltweit am weitesten verbreiteten Plattformen fuer Maschinendaten und Security Information and Event Management (SIEM). Sie sammelt, indexiert und durchsucht riesige Mengen an Logs, Metriken und Events aus der gesamten Infrastruktur eines Unternehmens — Server, Netzwerkgeraete, Anwendungen, Cloud-Dienste — und verwandelt sie in durchsuchbare, alarmierbare und dashboard-faehige Informationen. Speziell im Security-Betrieb ist Splunk haeufig das zentrale Nervensystem des SOC: der Ort, an dem Analysten pivotieren, jagen und untersuchen.

Neuere Splunk-Enterprise-Versionen (die 10.x-Linie) liefern einen PostgreSQL-„Sidecar”-Dienst mit — eine lokale Datenbank, die intern von Funktionen wie Edge Processor, OpAmp und SPL2-Datenpipelines genutzt wird. Zur Unterstuetzung der Notfallwiederherstellung stellt dieser Sidecar HTTP-Endpunkte bereit, die die PostgreSQL-Daten sichern und wiederherstellen koennen. Die bittere Ironie von CVE-2026-20253 ist kaum zu uebersehen: Die Plattform, die Organisationen kaufen, um Angreifer zu erkennen, wurde fuer diese zum unauthentifizierten Einstiegspunkt. Und weil Splunk-Server vertrauenswuerdige, log- und credential-reiche Systeme sind, die mit der gesamten Umgebung verdrahtet sind, ist ein Fuss in der Tuer hier ein Fuss in der Tuer fast ueberall.

Typische Einsatzszenarien

Security-Monitoring & SIEM: zentrale Log-Sammlung, Korrelation, Alarmierung und Threat Hunting im SOC.
IT-Betrieb & Observability: Infrastruktur- und Anwendungs-Monitoring, Troubleshooting und Performance-Analyse.
Compliance & Audit: langfristige Log-Aufbewahrung und Reporting fuer regulatorische Anforderungen.
Business-Analytics: Maschinendaten in operative und geschaeftliche Dashboards ueberfuehren.
Datenpipelines: Edge Processor, OpAmp und SPL2 routen und transformieren Daten im Fluss — die Funktionen, die der verwundbare PostgreSQL-Sidecar absichert.

Weil Splunk tief in Unternehmensnetzwerken eingesetzt wird und haeufig privilegierte Daten und Zugangsdaten enthaelt, ist eine unauthentifizierte RCE in seinen mitgelieferten Diensten so schwerwiegend, wie es nur sein kann.

🔍 Technische Analyse

Schwachstellenbeschreibung

CVE-2026-20253 ist eine Missing Authentication for Critical Function-Luecke (CWE-306). Splunks mitgelieferter PostgreSQL-Sidecar-Dienst stellt zwei Recovery-Endpunkte bereit — einen Backup-Endpunkt und einen Restore-Endpunkt —, die privilegierte Dateioperationen ohne jede Authentifizierung durchfuehren. Jeder Angreifer, der den Dienst ueber das Netzwerk erreicht, kann sie direkt aufrufen:

/v1/postgres/recovery/backup
/v1/postgres/recovery/restore

In der Praxis sind diese ueber Splunks splunkd-Raw-Proxy erreichbar (etwa unter einem Pfad /.../splunkd/__raw/v1/postgres/recovery/...). Der Backup-Endpunkt akzeptiert einen angreifergesteuerten backupFile-Pfad und erstellt oder truncatet eine Datei an diesem Ort — auch per Directory Traversal ausserhalb des vorgesehenen Backup-Verzeichnisses. Der Restore-Endpunkt erlaubt es dem Angreifer, die PostgreSQL-Verbindungsparameter zu kontrollieren und beliebigen Inhalt in eine gewaehlte Datei zu schreiben. Zusammen ergeben sie fuer einen unauthentifizierten Angreifer ein sauberes Primitiv zum Schreiben/Ueberschreiben beliebiger Dateien auf dem Splunk-Host.

Ursachenanalyse (Root Cause)

Unabhaengige Analysen (watchTowr Labs, durch die Forscher Piotr Bazydło und Yordan Ganchev) fuehrten den Fehler auf die fehlende Vertrauensgrenze des Sidecars zurueck. Die entscheidenden Details:

Kritische Funktionen ohne Authentifizierung: Die PostgreSQL-Recovery-Endpunkte backup und restore fuehren privilegierte Dateioperationen aus, pruefen aber nie, ob der Aufrufer authentifiziert ist — das Lehrbuchmuster von CWE-306.
Angreifergesteuerter Dateipfad: Der backup-Endpunkt nimmt einen backupFile-Parameter entgegen und schreibt/truncatet genau diesen Pfad, ohne Kanonisierung, um ihn auf ein sicheres Verzeichnis zu beschraenken — daher erreicht ../../../../-Traversal jeden Ort, an den der Splunk-Prozess schreiben kann.
Angreifergesteuerte Datenbankverbindung: Der restore-Endpunkt laesst den Aufrufer den PostgreSQL-Connection-String festlegen (einschliesslich Parametern wie passfile), sodass der Angreifer bestimmt, welcher Inhalt wohin geschrieben wird.
Schreib-Primitiv wird zu Code-Ausfuehrung: Durch Ueberschreiben eines Skripts, das Splunk selbst spaeter ausfuehrt — etwa ein Python-Helfer fuer Modular Inputs innerhalb der App splunk_secure_gateway —, laeuft der Inhalt des Angreifers unter dem Splunk-Dienstkonto und verwandelt den Dateischreibvorgang in RCE.
Durch eine mitgelieferte Funktion exponiert: Der Sidecar existiert zur Unterstuetzung von Edge Processor / OpAmp / SPL2-Pipelines, sodass die verwundbare Oberflaeche selbst dort vorhanden ist, wo Administratoren PostgreSQL nie bewusst „aktiviert” haben.
Netzwerkerreichbar, pre-authentication: Die gesamte Kette funktioniert remote, ohne Zugangsdaten und ohne Benutzerinteraktion.

Angriffsvektor

Um die Luecke zu waffnen, erreicht ein Angreifer die unauthentifizierten Recovery-Endpunkte und verkettet ein Datei-Erstellen mit einem Inhalts-Schreiben in ein von Splunk ausgefuehrtes Skript. Die folgenden Snippets dienen nur zur Veranschaulichung — sie zeigen die Form des Angriffs, keinen schluesselfertigen Exploit:

# Schritt 1: Internet-exponierte oder netzwerkerreichbare Splunk-Instanzen finden.
# Splunk Web lauscht typischerweise auf TCP/8000, splunkd-Management auf TCP/8089.
nmap -sT -p 8000,8089 --open -oG splunk-candidates.gnmap 203.0.113.0/24

# Schritt 2: Pruefen, ob der unauthentifizierte PostgreSQL-Recovery-Endpunkt OHNE
# Zugangsdaten antwortet -- ein verwundbarer Host reagiert auf den Backup-Endpunkt.
curl -sk -o /dev/null -w "Backup-Endpunkt-Status: %{http_code}\n" \
    -X POST "https://<splunk-host>:8000/en-US/splunkd/__raw/v1/postgres/recovery/backup" \
    -H "Content-Type: application/json" \
    -d '{"database":"search_metadata","backupFile":"/tmp/probe"}'

# Schritt 3 (NUR ZUR VERANSCHAULICHUNG): beliebiges Datei-Erstellen/Truncaten per Path Traversal.
POST /en-US/splunkd/__raw/v1/postgres/recovery/backup HTTP/1.1
Host: <splunk-host>:8000
Content-Type: application/json

{"database":"search_metadata","backupFile":"../../../../../../../../tmp/poc"}

# Schritt 4 (NUR ZUR VERANSCHAULICHUNG): angreifergesteuerten Inhalt ueber den
# Restore-Endpunkt schreiben, indem die PostgreSQL-Verbindungsparameter
# kontrolliert werden. Das Ueberschreiben eines spaeter von Splunk ausgefuehrten
# Skripts (z. B. ein splunk_secure_gateway-Python-Helfer) ergibt Code-Ausfuehrung
# unter dem Splunk-Benutzer. Dies implementiert NICHT CVE-2026-20253.
POST /en-US/splunkd/__raw/v1/postgres/recovery/restore HTTP/1.1
Host: <splunk-host>:8000
Content-Type: application/json

{"database":"dbname=template1 passfile=/opt/splunk/var/packages/data/postgres/.pgpass","backupFile":"/tmp/poc"}

Eine vereinfachte Darstellung der Angriffskette:

Angreifer                                         Opfer (Splunk Enterprise + PostgreSQL-Sidecar)
   |                                                            |
   |  POST /v1/postgres/recovery/backup (keine Auth)            |
   |  backupFile = ../../../tmp/poc                             |
   |----------------------------------------------------------->|  Datei ERSTELLT / TRUNCATED
   |                                                            |  (CWE-306: keine Auth-Pruefung)
   |                                                            |
   |  POST /v1/postgres/recovery/restore (keine Auth)           |
   |  angreifergesteuerte Verbindung + Inhalt                   |
   |----------------------------------------------------------->|  BELIEBIGER Inhalt geschrieben
   |                                                            |  an angreifergewaehlten Pfad
   |                                                            |
   |  von Splunk ausgefuehrtes Python-Skript ueberschreiben     |
   |----------------------------------------------------------->|  Skript laeuft als SPLUNK-Benutzer
   |                                                            |
   |<------------------ Code-Ausfuehrung ---------------------- |  vollstaendige Host-Kompromittierung
   v                                                            v

Der obige Ablauf dient nur zur Veranschaulichung — er implementiert nicht CVE-2026-20253. Der tatsaechliche Exploit missbraucht zwei unauthentifizierte PostgreSQL-Recovery-Endpunkte, um ein beliebiges Datei-Schreiben zu erlangen, und ueberschreibt dann ein von Splunk anschliessend ausgefuehrtes Skript, um Remote Code Execution zu erreichen.

Ausnutzung in freier Wildbahn

12.-13. Juni 2026 — watchTowr Labs veroeffentlicht eine detaillierte technische Analyse und einen funktionierenden Proof-of-Concept-Exploit, was die Huerde fuer eine Ausnutzung deutlich senkt.
18. Juni 2026 — Das Splunk PSIRT bestaetigt begrenzte Ausnutzung in freier Wildbahn von CVE-2026-20253 und aktualisiert sein Advisory.
18. Juni 2026 — CISA nimmt CVE-2026-20253 am selben Tag in den KEV-Katalog auf und signalisiert damit bestaetigten realen Missbrauch.
Laufend — Mit einem oeffentlichen PoC und KEV-Eintrag ist opportunistisches Massen-Scanning nach exponierten Splunk-Recovery-Endpunkten zu erwarten; beobachtete Ausnutzung umfasst harmlose „Marker”-Dateien (z. B. eine abgelegte watchTowr.txt) ebenso wie boesartige Folgeaktivitaeten.

Auswirkungen nach erfolgreicher Ausnutzung

Code-Ausfuehrung unter dem Splunk-Dienstkonto: Der Angreifer fuehrt Befehle auf dem Splunk-Host mit den Rechten des Splunk-Prozesses aus.
Kompromittierung des SIEM selbst: Die Kontrolle ueber genau die Plattform, die Angriffe erkennen soll, erlaubt es einem Eindringling, Security-Telemetrie zu lesen, zu veraendern oder zu loeschen und das SOC zu blenden.
Diebstahl von Zugangsdaten und Daten: Splunk enthaelt gesammelte Logs, API-Tokens und Integrations-Zugangsdaten — erstklassiges Material fuer Eskalation und laterale Bewegung.
Laterale Bewegung: Splunk ist mit weiten Teilen der Umgebung verdrahtet (Forwarder, Integrationen, Cloud-Connectoren), was dem Angreifer viele Pivot-Pfade gibt.
Persistenz: boesartige Apps, Modular Inputs, geplante Suchen oder neue Konten lassen den Angreifer nach der ersten Sitzung zurueckkehren.
Beweismanipulation: Ein Angreifer, der die Log-Plattform kontrolliert, kann seine eigenen Spuren ueber den gesamten Bestand hinweg loeschen.

⚠️ Auswirkungsanalyse

Unmittelbare Auswirkung

Unauthentifizierte, netzwerkerreichbare RCE: keine Zugangsdaten und keine Benutzerinteraktion — nur Netzwerkzugriff auf den Splunk-Dienst.
Hochwertiges, allgegenwaertiges Ziel: Splunk Enterprise ist eine fuehrende SIEM-/Observability-Plattform in Unternehmen und Behoerden.
Aktive Ausnutzung mit oeffentlichem PoC: watchTowrs funktionierender Exploit plus bestaetigter Missbrauch in freier Wildbahn bedeuten, dass das Fenster fuer sicheres Patchen geschlossen ist.
CISA KEV gelistet: die allererste Splunk-CVE im KEV, mit verbindlicher Frist fuer Bundesbehoerden — ein starkes Signal fuer ernsthafte Ausnutzung.
Der Detektor wird zum Einstiegspunkt: Die Kompromittierung des SIEM untergraebt die Faehigkeit der Organisation, den Einbruch ueberhaupt zu bemerken.

Betroffene Versionen

Branch	Status	Hinweise
10.2.0 — 10.2.3	Betroffen	Upgrade auf 10.2.4 oder neuer
10.0.0 — 10.0.6	Betroffen	Upgrade auf 10.0.7 oder neuer
10.2.4+	Behoben	Enthaelt den Fix
10.0.7+	Behoben	Enthaelt den Fix
10.4.0+	Nicht betroffen	Sidecar nicht verwundbar
9.4 und aelter	Nicht betroffen	Vor dem PostgreSQL-Sidecar
Splunk Cloud Platform	Nicht betroffen	Von Splunk verwaltet

Das Splunk-Advisory SVD-2026-0603 ist die massgebliche Quelle fuer die genauen behobenen Builds. Gleichen Sie es vor dem Ausrollen stets ab und pruefen Sie die laufende Version jeder On-Premises-Instanz.

Betroffene Umgebungen

On-Premises-Splunk-Enterprise-10.0.x-/10.2.x-Deployments: Der verwundbare Sidecar wird mit diesen Versionen ausgeliefert.
Instanzen mit Edge Processor, OpAmp oder SPL2-Pipelines: Diese Funktionen stuetzen sich auf den PostgreSQL-Sidecar — die Oberflaeche kann aber unabhaengig davon vorhanden sein.
Netzwerkerreichbares Splunk Web / splunkd: alles, was ein Angreifer ueber das Netzwerk erreichen kann (internet-exponierte Instanzen sind am staerksten gefaehrdet).
SOC- und Kern-Monitoring-Infrastruktur: die Systeme, deren Kompromittierung am meisten schmerzt.
Jede Umgebung, die noch nicht auf 10.0.7 / 10.2.4 / 10.4.0+ aktualisiert wurde.

Angreiferprofile

Opportunistische Scanner: Mit einem oeffentlichen PoC und KEV-Eintrag werden exponierte Splunk-Instanzen massenhaft abgesucht.
Ransomware-Affiliates & Initial-Access-Broker: RCE auf einem hochwertigen, tief integrierten Server ist erstklassiger Zugang.
APT-Gruppen: Die Kontrolle ueber das SIEM ermoeglicht heimliche, langwierige Spionage und Beweismanipulation.
Insider / pivotierende Angreifer: Wer bereits im Netzwerk ist, kann Erreichbarkeit trivial in vollstaendige Host-Kompromittierung verwandeln.

🛡️ Mitigationsstrategien

Sofortmassnahmen (Prioritaet 1) ⚡

Aktualisieren Sie jede betroffene Splunk-Enterprise-Instanz sofort. Dies ist der einzige vollstaendige Fix:

# Laufende Version jeder Instanz ermitteln.
/opt/splunk/bin/splunk version

# Auf eine behobene Version gemaess Splunk-Advisory SVD-2026-0603 aktualisieren:
#   10.2.x  -> 10.2.4 oder neuer
#   10.0.x  -> 10.0.7 oder neuer
#   (10.4.0+ ist nicht betroffen)
# Folgen Sie Splunks Standard-Upgrade-Prozedur und validieren Sie nach dem Upgrade.

Falls Sie nicht sofort patchen koennen, deaktivieren Sie den PostgreSQL-Sidecar ueber server.conf, um die verwundbaren Endpunkte zu entfernen. Beachten Sie, dass dies Edge Processor, OpAmp und SPL2-Datenpipelines deaktiviert — pruefen Sie die Auswirkungen zuerst:
```
# $SPLUNK_HOME/etc/system/local/server.conf
[postgres]
disabled = true
```
```
# Aenderung anwenden und Splunk neu starten, damit sie wirksam wird.
/opt/splunk/bin/splunk restart
```

Beschraenken Sie den Netzwerkzugriff auf Splunk Web (TCP/8000) und splunkd-Management (TCP/8089), sodass die Recovery-Endpunkte aus nicht vertrauenswuerdigen Netzen unerreichbar sind:

# Pruefen, ob der unauthentifizierte Backup-Endpunkt antwortet. Ein gepatchter
# oder mitigierter Host sollte OHNE Authentifizierung KEINE 2xx-Antwort liefern.
curl -sk -o /dev/null -w "Status: %{http_code}\n" \
    -X POST "https://<splunk-host>:8000/en-US/splunkd/__raw/v1/postgres/recovery/backup" \
    -H "Content-Type: application/json" -d '{"database":"x","backupFile":"/tmp/probe"}'

# Splunk-Management-/Web-Ports sollten niemals im oeffentlichen Internet exponiert sein.
# Platzieren Sie sie hinter VPN/Allow-Lists und vorgelagerten Kontrollen.

Suchen Sie nach vorheriger Kompromittierung. Da ein oeffentlicher PoC und aktive Ausnutzung vielen Patch-Fenstern vorausgehen, gehen Sie von einer moeglichen Kompromittierung aus und untersuchen Sie:

# Nach unerwarteten oder kuerzlich geaenderten Dateien suchen, die ueber das
# Schreib-Primitiv abgelegt wurden (gaengige Staging-Orte und die splunk_secure_gateway-App).
find /tmp /opt/splunk/var/run -type f -newermt "2026-06-10" 2>/dev/null
ls -la /opt/splunk/share/splunk/search_mrsparkle/exposed/watchTowr.txt 2>/dev/null
find /opt/splunk/etc/apps/splunk_secure_gateway/bin -name "*.py" \
    -newermt "2026-06-10" 2>/dev/null

Erkennungsmassnahmen 🔍

# Bauen Sie Erkennungen rund um:
#   - HTTP-POSTs an /v1/postgres/recovery/backup oder /restore, insbesondere
#     unauthentifizierte Anfragen oder Anfragen mit ".."-Path-Traversal
#     oder absoluten Pfaden im "backupFile"-Parameter.
#   - Restore-Anfragen, deren "database"-Wert ungewoehnliche Verbindungsparameter
#     traegt (z. B. passfile=, dbname=template1).
#   - Erstellung/Aenderung von Python-Skripten innerhalb von splunk_secure_gateway
#     oder neue Dateien unter /tmp und /opt/splunk/var/run.
#   - Unerwartete Kindprozesse, die vom Splunk-Dienstkonto gestartet werden.
#   - Ungewoehnliche ausgehende PostgreSQL-Verbindungen vom Splunk-Host.

Web-/Proxy-seitige Suche:

# Web-Access-Logs nach Anfragen an die PostgreSQL-Recovery-Endpunkte durchsuchen.
grep -E "/v1/postgres/recovery/(backup|restore)" /opt/splunk/var/log/splunk/*access*.log \
    | grep -E "POST"

# Anfragen mit Path Traversal im Body/in den Parametern markieren.
grep -E "/v1/postgres/recovery/" /opt/splunk/var/log/splunk/*access*.log \
    | grep -F ".."

Rollen Sie IDS/IPS- und WAF-Signaturen fuer die Recovery-Endpunkte aus, sobald sie verfuegbar sind, und ingestieren Sie veroeffentlichte IoCs.
Achten Sie auf das bekannte Marker-Artefakt (eine abgelegte watchTowr.txt) als schnellen Expositions-Check, verlassen Sie sich aber nicht darauf als einzigen Indikator.

Langfristige Sicherheitsverbesserungen

Tier-0-Monitoring schnell patchen: Behandeln Sie das SIEM mit derselben Critical-Patch-SLA wie jede internet-exponierte Sicherheits-Appliance — es ist ein Kronjuwel-System.
Exponierte Oberflaeche minimieren: Halten Sie Splunk Web/splunkd aus dem oeffentlichen Internet heraus; erreichen Sie sie ueber VPN, Bastions und Allow-Lists.
Ungenutzte mitgelieferte Funktionen deaktivieren: Werden Edge Processor / OpAmp / SPL2-Pipelines nicht genutzt, kann der PostgreSQL-Sidecar deaktiviert bleiben.
Das SIEM segmentieren und ueberwachen: Ein derart vertrauenswuerdiger und integrierter Server verdient strenge Netzwerksegmentierung und eigene Alarmierung.
Assume-Breach bei KEV-gelisteten Luecken: Wenn ein oeffentlicher PoC Ihrem Patch vorausgeht, patchen und jagen Sie — gehen Sie nicht von einem sauberen Zustand aus.
Kontinuierlich inventarisieren: Kennen Sie jede Splunk-Instanz, ihre Version und ihre Exposition — man kann nicht patchen, was man nicht sieht.

🎯 Warum ist das kritisch?

Unauthentifizierte Remote Code Execution: keine Zugangsdaten, keine Benutzerinteraktion — nur Netzwerkzugriff auf eine verwundbare Splunk-Instanz.
Aktive Ausnutzung mit oeffentlichem PoC: watchTowrs funktionierender Exploit ist draussen und Splunk hat Missbrauch in freier Wildbahn bestaetigt.
Erste Splunk-CVE ueberhaupt in CISA KEV: Eine verbindliche Frist fuer Bundesbehoerden unterstreicht, wie ernst dies ist.
Der Detektor wird zur Tuer: Die Kompromittierung des SIEM gewaehrt tiefen Zugriff und blendet zugleich die Verteidiger.
Allgegenwaertiges, hochwertiges Ziel: Splunk Enterprise verankert SOCs und IT-Betrieb in Unternehmen und Behoerden weltweit.
Credential- und datenreicher Host: Splunk enthaelt Logs, Tokens und Integrationsgeheimnisse, die weitere Kompromittierungen befeuern.
Ein sauberer Patch und ein sauberer Workaround existieren: Das Upgrade behebt es, und das Deaktivieren des Sidecars entfernt die Oberflaeche — es gibt keine Ausrede, es exponiert zu lassen.

🚀 Zeitleiste und Offenlegung

Juni 2026 — Splunk veroeffentlicht das Advisory SVD-2026-0603 zu CVE-2026-20253 und liefert behobene Builds (10.0.7, 10.2.4, 10.4.0+).
12.-13. Juni 2026 — watchTowr Labs (Piotr Bazydło, Yordan Ganchev) veroeffentlicht eine technische Analyse und einen funktionierenden Proof-of-Concept-Exploit.
18. Juni 2026 — Das Splunk PSIRT bestaetigt begrenzte Ausnutzung in freier Wildbahn; CISA nimmt CVE-2026-20253 in den KEV-Katalog auf — die erste Splunk-Schwachstelle ueberhaupt.
21. Juni 2026 — Verbindliche CISA-FCEB-Frist fuer Bundesbehoerden.

🔗 Ressourcen und Referenzen

CVE: CVE-2026-20253
NVD: NVD — CVE-2026-20253
Splunk-Advisory: SVD-2026-0603 — Unauthenticated Arbitrary File Creation and Truncation in a PostgreSQL Sidecar Service Endpoint
CWE: CWE-306: Missing Authentication for Critical Function
CISA-KEV-Katalog: Known Exploited Vulnerabilities

💼 SEKurity Unterstuetzt Sie

CVE-2026-20253 ist eine deutliche Erinnerung daran, dass Ihre Sicherheitswerkzeuge Teil Ihrer Angriffsflaeche sind — keine Ausnahme davon. Die Plattform, die viele Organisationen gezielt kaufen, um Eindringlinge zu fangen, lieferte einen gebuendelten Datenbankdienst mit zwei unauthentifizierten Endpunkten aus, und Forscher verwandelten eine bescheidene „Backup-Datei erstellen”-Funktion in vollstaendige Remote Code Execution auf dem vertrauenswuerdigsten Server des SOC. Schlimmer noch: Ein Angreifer, der das SIEM besitzt, kann genau jene Beweise still loeschen, die ihn enttarnt haetten. Wir helfen Organisationen, die vergessenen, optionalen und mitgelieferten Dienste zu finden, die still auf kritischen Systemen lauschen, zu validieren, dass internet-exponierte und Tier-0-Infrastruktur wirklich gepatcht und segmentiert ist, und zu pruefen, ob ein Angreifer, der Ihren Monitoring-Stack kompromittiert hat, erkannt wuerde — oder ob er einfach das Licht ausschalten wuerde. Unsere Infrastruktur- und Red-Team-Engagements kartieren genau diese hochvertrauenswuerdigen blinden Flecken, bevor jemand mit einem funktionierenden Exploit sie zuerst findet.

Unsere Leistungen

Penetration Testing: Webanwendungen, mobile Apps (Android & iOS), SAP-Systeme, Active Directory
Groß angelegte Angriffe: Perimeter-Tests, IT-Infrastruktur-Tests, Red-Team-Engagements
Security Awareness: Phishing-Kampagnen, Hacking-Demonstrationen

Handeln Sie jetzt — bevor es Angreifer tun.

Kontakt:

🌐 Website: www.sekurity.de

📧 Anfragen: www.sekurity.de/kontakt

📱 LinkedIn: SEKurity GmbH

Ihr SEKurity Team — Your Trusted Adversaries

Die Sicherheit Ihrer Monitoring-Infrastruktur ist unser Antrieb.

InSEKurity of the Week (CW25/2026): Splunk Enterprise Unauthenticated RCE ueber PostgreSQL-Sidecar (CVE-2026-20253)