Una vulnerabilità nel servizio PostgreSQL sidecar di Splunk Enterprise consente esecuzione remota di codice senza autenticazione. La falla con identificatore CVE-2026-20253 ha punteggio CVSS 9.8 e colpisce le versioni 10.0.0-10.0.6 e 10.2.0-10.2.3. La ricerca è stata condotta da watchTowr Labs; Orca Security ha pubblicato un advisory aggiuntivo. Il problema non sta in un bug di PostgreSQL, ma in un errore architetturale: il proxy application-layer del web server Splunk dissolve il confine tra rete esterna e localhost, rendendo raggiungibile un servizio progettato per essere locale.
- CVE-2026-20253 ha CVSS 9.8: l'endpoint /v1/postgres/recovery/backup e /restore del sidecar PostgreSQL non richiede autenticazione, permettendo a chiunque sia raggiungibile via rete di innescare operazioni di file system.
- Il web server Splunk sulla porta 8000 funge da proxy non autenticato verso il sidecar su 127.0.0.1:5435: l'assunto "localhost = sicuro" collassa quando un layer application gestisce il routing interno.
- L'attacco sfrutta connection string smuggling nel parametro dbname per dirottare la connessione verso un database controllato dall'attaccante, poi usa lo_export per scrivere file arbitrari e sovrascrivere script Python di sistema.
- Splunk Enterprise su AWS AMI è vulnerabile out-of-the-box: il sidecar è pre-installato e attivo, esponendo immediatamente le istanze cloud.
Il meccanismo: come il proxy dissolve il perimetro
Secondo l'analisi di SocFortress e le ricerche di watchTowr Labs, il cuore del problema è un sidecar PostgreSQL che Splunk avvia in ascolto esclusivamente su loopback alla porta 5435. In un'architettura tradizionale, questo garantirebbe isolamento: il servizio non è esposto sulla rete fisica, quindi solo processi locali possono contattarlo. Ma l'architettura di Splunk introduce un reverse proxy nel web server principale, che ascolta sulla porta 8000 e inoltra richieste HTTP verso servizi interni.
L'endpoint /v1/postgres/recovery/backup e il corrispettivo /restore sono raggiungibili attraverso questa interfaccia senza alcuna verifica di identità. Secondo il comunicato di Splunk riportato da The Hacker News, "the PostgreSQL sidecar service endpoint lacks authentication controls, allowing any network-reachable user to invoke file operations without credentials". La CWE associata è la 306: Missing Authentication for Critical Function. L'API accetta credenziali arbitrarie — inclusi campi vuoti — e le inoltra a pg_dump e pg_restore.
Qui interviene il secondo livello della catena. Il parametro dbname non viene validato come semplice nome database: se contiene una connection string completa, i flag interni come hostaddr sovrascrivono il parametro -h localhost passato dalla linea di comando. Questo consente all'attaccante di indirizzare l'operazione di backup verso un server PostgreSQL sotto il suo controllo. Il dump risultante viene scritto sul filesystem della macchina Splunk con permessi del processo sidecar.
Dal file write alla RCE: la catena multi-step
Il passaggio da scrittura arbitraria di file a esecuzione di codice remoto segue una sequenza documentata dai ricercatori. I ricercatori Piotr Bazydlo e Yordan Ganchev di watchTowr Labs hanno pubblicato i dettagli tecnici e un proof-of-concept.
"At this point, we can authenticate, restore attacker-controlled SQL, and interact with the local database... Once we could restore attacker-controlled SQL into the local PostgreSQL instance, we quickly put together a database dump template that gave us a controlled file write" — Piotr Bazydlo e Yordan Ganchev, watchTowr Labs (via The Hacker News)
Una volta stabilito il controllo sul contenuto del database remoto, l'attaccante costruisce un dump manipolato che, al restore, utilizza la funzione lo_export di PostgreSQL per materializzare file sul disco locale. Il file target documentato è /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py, uno script Python eseguito dal sistema Splunk. Sovrascrivendolo, l'attaccante ottiene esecuzione con i permessi del processo Splunk. Nessuna interazione utente è necessaria. Nessuna sessione autenticata precedente.
Un elemento aggiuntivo emerge dal file .pgpass locale, posizionato in /opt/splunk/var/packages/data/postgres/.pgpass: contiene le credenziali postgres_admin in chiaro, abbassando la barriera per la fase di autenticazione al database locale una volta ottenuto l'accesso al sidecar.
L'angolo AWS: perché il cloud amplifica il rischio
SocFortress e CyberSecurityNews convergono su un punto specifico che rende la vulnerabilità particolarmente urgente per deployment cloud. "Splunk Enterprise on AWS is vulnerable out of the box", scrive SocFortress: l'Amazon Machine Image distribuita ufficialmente include il sidecar PostgreSQL pre-installato e attivo al primo avvio. Questo significa che un'amministratore che lancia un'istanza dalla console AWS, senza configurazioni aggiuntive, espone immediatamente il sistema alla catena di exploit descritta.
Il profilo di rischio cambia qualitativamente. Non si tratta di un'amministrazione negligente che lascia aperte porte inaspettate: il servizio vulnerabile è parte del prodotto standard, distribuito e attivato dal vendor stesso. L'unica variabile protettiva è la posizione dell'istanza nel piano di rete: se la porta 8000 è esposta su internet, l'exploit è diretto. Il numero di istanze Splunk Enterprise esposte su internet, specialmente su AWS, non è quantificato nelle fonti disponibili.
Splunk Cloud, al contrario, non è affetto. Tutte le fonti primarie — Hacker News, Cyber Express, Orca, SocFortress — confermano che Splunk Cloud non utilizza i PostgreSQL sidecar e quindi non è vulnerabile a CVE-2026-20253.
Cosa fare adesso
La priorità assoluta è l'aggiornamento. Splunk ha rilasciato le versioni 10.0.7 e 10.2.4 che correggono la vulnerabilità. Orca Security menziona anche le versioni 10.4.0, 9.4.12 e 9.3.13 come patchate, ma queste ultime due non sono confermate da altre fonti primarie come versioni affette a CVE-2026-20253: la fonte non specifica se le versioni 9.x siano vulnerabili alla stessa catena di exploit.
Orca Security dichiara esplicitamente: "No workaround is available for CVE-2026-20253 — upgrading is the only mitigation". Non esiste mitigazione alternativa documentata.
Per gli ambienti AWS, la verifica deve concentrarsi su istanze con porta 8000 esposta su internet che eseguano Splunk Enterprise nelle versioni vulnerabili. La fonte non specifica una soglia temporale per il check retrospettivo; l'assenza di evidenza di sfruttamento in-the-wild, dichiarata dalle fonti, non esclude attacchi non rilevati.
Le CVE correlate divulgate da Orca Security — CVE-2026-20251 (CVSS 8.8, richiede low-privilege), CVE-2026-20252 (CVSS 7.6), CVE-2026-20258 (CVSS 7.1) — non sono documentate come tecnicamente concatenabili con CVE-2026-20253. Il brief non documenta se queste siano tecnicamente concatenabili.
Perché questo caso sfida i presupposti dell'architettura sicura
La vulnerabilità CVE-2026-20253 mette in luce un pattern architetturale problematico: il sidecar locale, teoricamente protetto dal binding su loopback, diventa raggiungibile esternamente attraverso un proxy application-layer. Questo è un fatto documentato dalle fonti tecniche.
Una considerazione analitica, non quantificata nelle fonti: il modello di threat model implicito nel design di Splunk assume che i servizi su localhost siano protetti per default. La presenza di un proxy non autenticato che inoltra verso questi servizi invalida quell'assunto senza aggiungere controlli compensativi. L'analisi di SocFortress descrive questo come "a helpful, unauthenticated bridge" — un'ironia tecnica che evidenzia il gap tra intento architetturale e implementazione.
Il caso solleva questioni sulle responsabilità di sicurezza nei deployment cloud: quando un vendor distribuisce un'immagine con servizio vulnerabile attivo di default, il confine tra configurazione sicura e vulnerabilità prodotto si assottiglia. Questa è un'interpretazione editoriale basata sui fatti documentati, non un'affermazione di fatto aggiuntiva.
Nota sui limiti delle fonti: questo articolo si basa principalmente su The Hacker News come fonte primaria strutturata con statement ufficiale Splunk, integrata da Orca Security (advisory vendor), SocFortress (analisi tecnica dettagliata) e CyberSecurityNews (corroborazione). Non esiste una seconda fonte primaria strutturata indipendente con accesso diretto a comunicati Splunk. I dettagli tecnici della catena multi-step provengono da analisti di sicurezza e blog specializzati, non da documentazione ufficiale del vendor.
Fonti: The Hacker News | Orca Security | SocFortress | CyberSecurityNews | The Cyber Express
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- https://thehackernews.com/2026/06/critical-splunk-enterprise-flaw-lets.html
- https://orca.security/resources/blog/cve-2026-20253-splunk-enterprise-rce-unauthenticated-file-operations/
- https://socfortress.medium.com/splunk-enterprise-cve-2026-20253-unauthenticated-remote-code-execution-vulnerability-ef509536309b
- https://cybersecuritynews.com/splunk-enterprise-pre-auth-rce-chain-exposes/
- https://thecyberexpress.com/cve-2026-20253-critical-splunk-enterprise/
- https://www.securityweek.com/chrome-and-firefox-updated-to-patch-critical-high-severity-vulnerabilities/
- https://gbhackers.com/splunk-enterprise-and-cloud-platform-rce-vulnerability/
- https://us.gov.app.orcasecurity.io/
- https://about.gitlab.com/releases/2026/04/08/patch-release-gitlab-18-10-3-released/