Il SIEM che non chiedeva la password

L'origine

CVE-2026-20253. CVSS 3.1: 9.8 CRITICAL, vettore AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. CWE-306: Missing Authentication for Critical Function. CNA assegnataria: Cisco, proprietaria di Splunk dal 2024.

Traduzione della sigla: attaccabile dalla rete, complessità bassa, nessun privilegio richiesto, nessuna interazione utente, compromissione totale di riservatezza, integrità e disponibilità. È il profilo peggiore che una CVE possa avere.

La cronologia è compressa:

• 10 giugno 2026 — Splunk pubblica l'advisory SVD-2026-0603
• 12 giugno — watchTowr Labs pubblica l'analisi tecnica completa, con PoC
• 18 giugno — Splunk conferma "limited exploitation" in the wild. Lo stesso giorno CISA la inserisce nel catalogo KEV, con scadenza di rimedio al 21 giugno (BOD 26-04)

Tre giorni per patchare, per gli enti federali USA. Shadowserver contava all'epoca oltre 1.400 istanze Splunk esposte su Internet — 952 in Nord America, 223 in Europa. Quante fossero effettivamente vulnerabili non è dato saperlo.

Versioni affette: Splunk Enterprise 10.2.0–10.2.3 e 10.0.0–10.0.6. Splunk Cloud Platform non è affetto.

La catena d'attacco

Il colpevole è il PostgreSQL Sidecar Service, un componente interno che Splunk usa per le proprie pipeline dati. Dovrebbe parlare solo con sé stesso, sul loopback. Non è andata così.

La catena ricostruita da watchTowr — che descriviamo a livello concettuale, senza fornire codice riutilizzabile — è una sequenza di quattro fiducie mal riposte:

1. 01
   Reverse proxy

   il web server sulla porta 8000 espone gli endpoint interni del sidecar
2. 02
   Header Authorization

   qualunque valore viene accettato, non validato
3. 03
   Parametro database

   accetta una connection string che sovrascrive l'host
4. 04
   Opzione passfile

   Splunk legge il proprio .pgpass e cede le credenziali admin
5. 05
   /restore

   un dump malevolo diventa scrittura file arbitraria, poi RCE

Prima fiducia: il reverse proxy. Il web server principale di Splunk (porta 8000, in ascolto su tutte le interfacce) espone endpoint interni del sidecar — /v1/postgres/recovery/backup e /restore — che erano pensati per il solo loopback. E l'autenticazione? Qualunque valore nell'header Authorization viene accettato. Non validato: accettato.

Seconda fiducia: il parametro database. Dovrebbe contenere il nome di un database. Accetta invece un'intera connection string PostgreSQL, che sovrascrive i parametri hardcoded — incluso l'host. L'attaccante può quindi convincere Splunk a connettersi a un database PostgreSQL che controlla lui.

Terza fiducia: l'opzione passfile. Sfruttandola, si può far leggere a Splunk il proprio file .pgpass locale — ottenendo le credenziali dell'utente PostgreSQL amministrativo interno.

Quarta fiducia: /restore. Con quelle credenziali, un dump malevolo viene fatto ripristinare sull'istanza locale, ottenendo una primitiva di scrittura file arbitraria.

Da lì al RCE il passo è breve: si sovrascrive uno script Python che Splunk esegue periodicamente — ssg_enable_modular_input.py — e si aspetta.

Nessuno di questi quattro passaggi è un exploit di memoria. Sono quattro decisioni di design che, singolarmente, sembravano ragionevoli.

Detection

L'advisory Splunk dice, testualmente, "Detections: None". Nessun IOC ufficiale: né hash, né IP, né domini. Siete soli.

Cosa si può comunque cercare:

• Richieste HTTP verso /en-US/splunkd/__raw/v1/postgres/recovery/backup o /restore — non dovrebbero mai arrivare dall'esterno
• File inattesi in /opt/splunk/var/run/supervisor/pkg-run/pkg-postgres*/
• Modifiche non pianificate a ssg_enable_modular_input.py — questo è il segnale che siete già oltre
• Connessioni PostgreSQL in uscita dal sidecar verso host esterni. Un database interno non ha alcun motivo di chiamare Internet

watchTowr ha pubblicato uno script di verifica pubblico che distingue le istanze vulnerabili in base alla risposta HTTP dell'endpoint backup (400 contro 401).

Rimedi

Patch: upgrade a Splunk Enterprise 10.4.0, 10.2.4 o 10.0.7 (o superiore). Non ci sono alternative eleganti.

Mitigazione temporanea, se davvero non potete patchare subito: disabilitare il sidecar con [postgres] disabled = true in server.conf.

Attenzione però — e questa è la parte che l'advisory dice e molti non leggono: questa mitigazione interrompe Edge Processor, OpAmp e le pipeline dati SPL2. Non è un interruttore gratuito. Rompe funzionalità che probabilmente state usando.

Nota sulle fonti: su NVD il punteggio 9.8 è riportato "as provided by CNA" — l'arricchimento indipendente NVD non risultava ancora completato. E Splunk conferma lo sfruttamento senza dettagliare cosa cercassero gli attaccanti osservati.

Cosa insegna

L'ironia si commenta da sola: una vulnerabilità pre-auth critica in un SIEM. Lo strumento che le aziende comprano proprio per accorgersi delle intrusioni, bucato da un componente di database che si fida di chiunque bussi. I ricercatori di watchTowr l'hanno riassunta meglio di come potremmo noi: Splunk ha deciso che l'autenticazione è un problema di qualcun altro.

Ma ci sono due lezioni meno ovvie.

La prima è sul default. Il sidecar è abilitato di default su Splunk Enterprise su AWS: chi ha fatto quel deployment era vulnerabile out of the box, senza aver configurato nulla di sbagliato. Chi ha installato a mano su Windows on-prem spesso ce l'ha disabilitato. Stessa CVE, stesso CVSS, rischio reale radicalmente diverso a seconda di come avete installato il prodotto. Il punteggio non ve lo dice.

La seconda riguarda chi ha trovato il bug. watchTowr ha usato un proprio agente LLM interno — "Project Red" — per suggerire la richiesta HTTP che si è rivelata la chiave di volta dell'intera catena. È ricerca di vulnerabilità assistita da AI, applicata con successo a un prodotto di sicurezza, documentata pubblicamente. Vale la pena notarlo: lo stesso mestiere che studiamo su questo sito sta cambiando strumenti.