Splunk CVE-2026-20253: RCE pre-auth dentro il tuo SIEM

Lo strumento che hai comprato per sorvegliare tutto il resto è appena diventato la cosa da sorvegliare. Il 10 giugno 2026 Splunk ha pubblicato SVD-2026-0603, divulgando CVE-2026-20253: una falla non autenticata e raggiungibile via rete in Splunk Enterprise che permette a un attaccante di creare o troncare file arbitrari sull'host, con un percorso pulito da lì fino all'esecuzione di codice remoto. CVSS 9.8. Nessuna credenziale. Entro il fine settimana del 13–14 giugno le analisi tecniche erano pubbliche, catena di exploit completa inclusa. Per una quota enorme di aziende e di SOC, Splunk è il registro di riferimento della detection: il luogo dove gli eventi di sicurezza vanno per essere creduti. Una RCE pre-auth in quel sistema non è l'ennesima CVE di un apparato di frontiera. È un buco nella cosa di cui ti fidi per trovare i buchi.

Cos'è davvero la CVE-2026-20253

Splunk 10 ha introdotto un "sidecar" PostgreSQL: un servizio splunk-postgres in ascolto su localhost:5435 che la piattaforma usa per operazioni interne di backup e recovery. L'applicazione web principale sulla porta 8000 può inoltrare richieste verso di esso tramite un path __raw: /en-US/splunkd/__raw/v1/postgres/recovery/. Due endpoint sotto quel path — /backup e /restore — sono stati rilasciati senza controlli di autenticazione. Qualunque valore nell'header Authorization viene accettato e mai validato. Come scrive lo stesso bollettino Splunk, il risultato è che "un utente non autenticato potrebbe creare o troncare file arbitrari attraverso un endpoint del servizio sidecar PostgreSQL".

Le build interessate e corrette, dal bollettino:

Ramo	Interessate	Corrette in
Splunk Enterprise 10.2	10.2.0 – 10.2.3	10.2.4
Splunk Enterprise 10.0	10.0.0 – 10.0.6	10.0.7
Splunk Enterprise 10.4	non interessate	10.4.0

Un dettaglio decide quanto sei esposto: il sidecar non è installato di default sulle installazioni on-prem manuali, ma è attivo di default su Splunk Enterprise in esecuzione su AWS. Splunk Cloud (il SaaS gestito) non usa il sidecar e non è interessato. La popolazione più esposta è quindi Splunk Enterprise autogestito su AWS: esattamente il deployment che molti team scelgono quando vogliono il controllo sul SIEM senza gestire il ferro.

Da una richiesta non autenticata all'esecuzione di codice

Una primitiva di scrittura file non è automaticamente RCE. La parte interessante dell'analisi di watchTowr Labs è come i due endpoint di recovery si combinino in uno. L'endpoint /backup invoca pg_dump con parametri influenzabili dall'attaccante; l'argomento database confluisce in una stringa di connessione PostgreSQL, e un hostaddr in quella stringa sovrascrive l'-h localhost hardcoded. Significa che il "backup" può essere puntato su un database controllato dall'attaccante. L'endpoint /restore esegue poi pg_restore, che riproduce SQL ed esegue il PL/pgSQL incorporato nel dump.

Concatenato, il flusso è questo:

• Si allestisce un'istanza PostgreSQL controllata dall'attaccante contenente una funzione malevola che chiama lo_export per scrivere un payload di byte scelto su un path scelto.
• Si chiama /backup per trasferire quel database in un file sul filesystem di Splunk.
• Si chiama /restore per riprodurlo; durante il restore, lo_export scatta e scrive il payload su disco sull'host Splunk.
• Si mira la scrittura su uno script Python che Splunk esegue secondo una propria pianificazione. Nel PoC pubblico il bersaglio era /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py. Splunk lo esegue periodicamente — e ora esegue il codice dell'attaccante, con l'utente splunk.

C'è una variante più silenziosa. Poiché la stringa di connessione è controllabile, lo stesso endpoint può essere indirizzato verso host interni che la macchina Splunk raggiunge ma l'attaccante no: un pivot in server-side request forgery dentro la rete, che l'analisi di Orca Security segnala accanto all'impatto di file operation e RCE. Un SIEM è, per progettazione, una macchina con cui tutto il resto parla. Possederla consegna all'attaccante un punto di osservazione privilegiato sul resto del parco.

"Splunk lo abbiamo patchato il trimestre scorso." — "Quale Splunk? I forwarder, gli indexer, o la search head su AWS che qualcuno ha tirato su per una migrazione a marzo e non ha mai inserito nello SLA delle patch?"

La seconda domanda è dove questi incidenti vivono davvero.

Perché un bug in Splunk è peggio di un bug quasi ovunque

C'è un errore di categoria nel modo in cui la maggior parte delle organizzazioni ragiona sui prodotti di sicurezza. Una VPN vulnerabile o un ERP vulnerabile vengono compresi come rischio. Uno strumento di sicurezza vulnerabile tende a ricevere un lasciapassare, perché siede nella colonna mentale "la cosa che ci protegge", non nella colonna "asset che può essere attaccato". Quell'istinto è sbagliato, e gli ultimi mesi lo hanno reso evidente a caro prezzo: prodotti di sicurezza e di gestione finiscono di continuo nel catalogo delle Known Exploited Vulnerabilities di CISA, e a maggio abbiamo scritto degli zero-day di endpoint protection aggiunti al KEV per la stessa ragione strutturale.

Il motivo per cui è peggio, non semplicemente uguale, sta in tre proprietà che un SIEM possiede in modo unico:

• Raggio d'azione. Ogni altro sistema gli inoltra i log, quindi ha percorsi di rete verso quasi tutto. È esattamente ciò che monetizza l'angolo SSRF della CVE-2026-20253.
• Fiducia. Gli analisti trattano ciò che dice il SIEM come verità di base. Un attaccante con esecuzione di codice lì può sopprimere, alterare o fabbricare la telemetria stessa su cui poggia la tua logica di detection.
• Gravità delle credenziali. Un SIEM accumula service account, token API e segreti di integrazione per poter raccogliere dati da ovunque. Il PoC legge persino il file .pgpass da disco per autenticare il passo di restore; è un piccolo campione del materiale segreto che queste macchine accumulano.

Il punto cieco: un SIEM non può testimoniare la propria compromissione

Ecco il fallimento che dovrebbe togliere il sonno ai difensori. Se la piattaforma che ingerisce e correla la tua telemetria di detection è la piattaforma che viene sfruttata, la tua telemetria di detection è esattamente il posto sbagliato dove cercare l'attacco. L'esecuzione di codice come utente splunk è esecuzione di codice dentro il testimone. La prima cosa che operatori competenti fanno dopo essere atterrati in una pipeline di log è impedirle di registrarli.

Quindi la domanda smette di essere "il mio SIEM genererà un alert su questo?" e diventa "chi osserva il SIEM?". C'è una sola risposta che non dipende dall'integrità del SIEM: il filo. Le POST non autenticate verso /en-US/splunkd/__raw/v1/postgres/recovery/, la connessione in uscita dall'host Splunk verso un'istanza PostgreSQL controllata dall'attaccante, le sonde SSRF che si diramano nei range interni, il nuovo processo periodico che fa beaconing verso l'esterno — tutto questo è traffico, e il traffico è osservabile indipendentemente dal fatto che l'endpoint che lo genera sia ancora affidabile. Un attaccante può accecare una sorgente di log. Accecare la rete su cui si muove è molto più difficile, e di solito non ci prova nemmeno.

Cosa salta in silenzio il "basta patcharlo"

Aggiornare Splunk a 10.2.4 / 10.0.7 / 10.4.0 è necessario e va fatto oggi. Ma "patcha la CVE" è la risposta a una domanda che nessuno ha posto con precisione. Le domande operative che la CVE-2026-20253 solleva davvero sono:

• Sai di ogni istanza Splunk Enterprise che gestisci, inclusa la search head ombra su AWS che un team ha tirato su per una migrazione una tantum e non ha mai inventariato?
• Per ciascuna istanza, il sidecar PostgreSQL è presente e raggiungibile — cioè sei davvero esposto, o solo nominalmente su una versione vulnerabile?
• Se una di queste macchine fosse stata bucata due settimane prima del bollettino, se ne sarebbe accorto qualcosa di diverso dalla macchina stessa?

Un penetration test annuale o trimestrale non risponde a nessuna di queste per una CVE pubblicata quattro giorni fa. Il modello che lo fa è continuo, e deve trattare lo stack di sicurezza come un asset da attaccare — non come un osservatore fidato esente dai test.

Dove si inserisce Zero Hunt

È questo il varco che Zero Hunt è costruito per chiudere, e la CVE-2026-20253 ci si allinea quasi troppo bene. Lo swarm di 10 agenti AI della piattaforma — Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic e Report, sotto un AI Controller — gira in continuo contro il tuo parco, incluse le macchine che consideri difensive. L'agente Recon trova la search head AWS non inventariata; gli agenti Web ed Exploit verificano se il path /v1/postgres/recovery/ risponde davvero senza auth su *quell'*host, invece di dedurlo da un banner di versione. Gli exploit sono generativi: scritti per-bersaglio da un LLM locale, non prelevati da un PoC pubblico, così la validazione riflette la tua configurazione — sidecar presente o no, raggiungibile o no — invece di un sì/no generico. Ogni nuova skill offensiva viene ritestata nell'AI Gym contro corpora come Vulhub e i task black-box basati su CVE prima di toccare la produzione, e ogni finding confermato è firmato ECDSA con catena di custodia, così "abbiamo testato il SIEM ed ecco esattamente cosa era raggiungibile in quale data" è un record difendibile, non un ricordo.

La seconda metà del problema — il testimone che sopravvive al fatto che sia il SIEM la vittima — è il modello di AI Traffic Analysis. È un motore di deep learning proprietario con quattro teste di inferenza parallele (traffico sospetto, classificazione malware, identificazione del tipo di attacco, fingerprinting applicativo), addestrato su miliardi di sequenze PCAP, in esecuzione localmente sulla GPU dell'appliance a 2.7+ Gbit/s. Non chiede a Splunk cosa è successo. Osserva le POST di recovery non autenticate, la connessione in uscita verso un ASN mai visto e il fan-out SSRF mentre attraversano il filo — indipendentemente dal fatto che l'host che li genera stia ancora riportando onestamente. Quando la cosa attaccata è la cosa di cui normalmente ti fideresti per essere avvisato, un osservatore che non le deve nulla è la differenza tra intercettare l'intrusione e leggerla nel bollettino del trimestre prossimo.

Fonti: bollettino Splunk SVD-2026-0603 (10 giugno 2026); analisi tecnica di watchTowr Labs; Orca Security; catalogo CISA KEV.