// 1 CRITICAL · 5 ZERO-DAY · 8 CVE · 7 EXPLOIT · 2 ADVISORY NELLE ULTIME 24H
CVE-2026-20253 in Splunk Enterprise ha CVSS 9.8 e RCE pre-autenticazione. CISA ha fissato deadline di 3 giorni con il nuovo BOD 26-04, segnando un precedente

Splunk ha pubblicato l'advisory SVD-2026-0603 il 10 giugno 2026 per CVE-2026-20253, una vulnerabilità critica con punteggio CVSS 9.8 che consente esecuzione remota di codice pre-autenticazione. Otto giorni dopo, il 18 giugno, il Product Security Incident Response Team di Splunk ha confermato exploitation limitata in-the-wild. CISA ha reagito inserendo il CVE nel catalogo Known Exploited Vulnerabilities con una deadline di tre giorni per le agenzie federali: il 21 giugno 2026. Questa celerità non è casuale: è il primo test operativo del Binding Operational Directive 26-04, che sostituisce il precedente sistema di scadenze standardizzate con un tiering basato sul rischio effettivo.

Punti chiave
  • CVE-2026-20253 ha CVSS 9.8 (Critical) con vettore AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H secondo il record ufficiale CVE.org; il bug risiede in endpoint del servizio sidecar PostgreSQL privi di autenticazione
  • CISA ha fissato deadline di tre giorni (18-21 giugno 2026) per le agenzie FCEB sotto il BOD 26-04, che introduce criteri SSVC con tiering dinamico basato su exploitation attiva, automazione e impatto tecnico totale
  • Le versioni vulnerabili sono Splunk Enterprise 10.2.0-10.2.3 e 10.0.0-10.0.6; le release 10.2.4, 10.0.7 e 10.4.0 correggono la vulnerabilità secondo l'analisi di penligent.ai
  • Il workaround di disabilitazione del sidecar PostgreSQL interrompe Edge Processor, OpAmp e pipeline SPL2, con impatto funzionale misurabile sui deployment che utilizzano questi componenti

Il meccanismo: da endpoint PostgreSQL senza auth a RCE completa

La vulnerabilità è classificata CWE-306: Missing Authentication for Critical Function. Il record CVE-2026-20253 descrive il problema con precisione tecnica: "The vulnerability exists because the PostgreSQL sidecar service endpoint lacks authentication controls, allowing any network-reachable user to invoke file operations without credentials." Secondo l'analisi condotta da watchTowr Labs e documentata da tech-insider, gli endpoint /v1/postgres/recovery/backup e /v1/postgres/recovery/restore accettano connessioni senza verifica d'identità.

La catena di exploit dimostrata dai ricercatori procede attraverso quattro stadi. Il primo è l'hostaddr injection nel parametro di connessione PostgreSQL, che permette di reindirizzare il sidecar verso un server controllato dall'attaccante. Il secondo sfrutta la funzione lo_export di PostgreSQL per scrivere file arbitrari sul filesystem locale. Il terzo legge il file .pgpass contenente credenziali del database interno. Il quarto sovrascrive il modulo Python ssg_enable_modular_input.py, eseguito da Splunk con privilegi elevati, ottenendo così esecuzione remota di codice senza interazione utente.

Come ha riportato tech-insider citando i ricercatori Piotr Bazydlo e Yordan Ganchev: "From that single unauthenticated POST request, the rest of the chain, credential theft, file overwrite, and code execution, runs without further interaction from a legitimate user." Il sidecar PostgreSQL risulta abilitato di default sui deployment AWS, amplificando la superficie di esposizione per le istanze cloud-hosted.

Il BOD 26-04: quando la severità CVSS incontra il profilo di rischio operativo

La deadline di tre giorni imposta da CISA rappresenta una discontinuità normativa rispetto al precedente Binding Operational Directive 22-01. Il BOD 26-04, titolato "Prioritizing Security Updates Based on Risk", introduce un criterio di prioritizzazione dinamico che combina quattro parametri SSVC: exploitation attiva (active), automatizzabilità dell'attacco (automatable:yes), e impatto tecnico totale (technicalImpact:total). Quando questi fattori convergono, come nel caso di CVE-2026-20253, la finestra di remediation si comprime drasticamente.

Security Affairs ha riportato la formulazione operativa: "CISA orders federal agencies to fix the vulnerability by the end of this week, on June 21, 2026." La scelta lessicale — "orders" piuttosto che "recommends" — segnala il carattere vincolante del provvedimento per le agenzie Federal Civilian Executive Branch. Per le organizzazioni private, la deadline non è giuridicamente obbligatoria, ma la velocità della reazione governativa funge da segnale di mercato: i fornitori di servizi critici e i contractor federali devono allineare i propri SLA di patching a questa nuova scala temporale.

L'NVD entry per CVE-2026-20253 include i metadati SSVC che hanno attivato il tiering più aggressivo: exploitation:active, automatable:yes, technicalImpact:total. Questa tripla convergenza ha generato la deadline più breve mai applicata sotto il nuovo framework.

"In June 2026, the Splunk Product Security Incident Response Team (PSIRT) became aware of limited exploitation of this vulnerability. Splunk strongly recommends that customers upgrade to a fixed software release to remediate this vulnerability."

Versioni affette, fix e costi del workaround

Il record CVE-2026-20253 delimita con precisione il perimetro delle versioni vulnerabili: Splunk Enterprise 10.2 da 10.2.0 a 10.2.3, e il branch 10.0 da 10.0.0 a 10.0.6. Le release 9.4 e precedenti non risultano affette. Secondo l'analisi di penligent.ai, le versioni corrette sono 10.2.4, 10.0.7 e 10.4.0. Splunk Cloud Platform è esplicitamente fuori dal perimetro di rischio: non utilizza il sidecar PostgreSQL che ospita il bug.

Per le organizzazioni che non possono applicare immediatamente la patch, esiste un workaround documentato da più fonti: l'inserimento di [postgres] disabled = true nel file server.conf. La limitazione è sostanziale: questa modifica disabilita funzionalità di control-plane che supportano Edge Processor, OpAmp e le pipeline SPL2. Su deployment che sfruttano questi componenti per l'ingestione e la trasformazione dei dati, il workaround equivale a una riduzione di capacità operativa, non a una mitigazione indolore.

Tech-insider segnala che il sidecar nel branch 10.2 utilizza PostgreSQL 17.6, un dato che aiuta a localizzare il problema nello stack tecnologico specifico ma che non modifica la superficie di attacco: la vulnerabilità è nel layer di esposizione dell'endpoint, non nella versione del motore database.

Cosa fare adesso

  • Verificare la versione di Splunk Enterprise in produzione: i branch 10.2.x e 10.0.x entro i range vulnerabili richiedono aggiornamento prioritario alle release 10.2.4, 10.0.7 o 10.4.0
  • Valutare l'esposizione del sidecar PostgreSQL sui deployment AWS, dove è attivo di default, verificando la raggiungibilità di rete degli endpoint /v1/postgres/recovery/*
  • Se l'applicazione della patch è ritardata e il deployment non utilizza Edge Processor, OpAmp o SPL2, considerare il workaround di disabilitazione con consapevolezza dell'impatto funzionale sui componenti di control-plane
  • Allineare le procedure interne di vulnerability management al nuovo paradigma del BOD 26-04: le scadenze governative diventano variabili dipendenti dal profilo di rischio combinato, non più statiche basate solo sulla severità CVSS

Cisco e il test di stress sulla governance della sicurezza

L'advisory SVD-2026-0603 arriva meno di due anni dopo l'acquisizione di Splunk da parte di Cisco per circa 28 miliardi di dollari. La gestione di uno zero-day con exploitation confermata nel portfolio acquisito costituisce un caso di studio sulla capacità di integrazione operativa del più grande acquisto nella storia di Cisco. Il tempo di risposta — otto giorni tra advisory iniziale e conferma pubblica di exploitation — e la qualità del comunicato tecnico sono elementi misurabili di questa capacità.

Per le aziende che operano nei mercati di vendor enterprise, c'è un insegnamento più ampio. Splunk è spesso il sistema di raccolta e analisi dei log al centro del Security Operations Center; la sua compromissione non aggiunge semplicemente un server vulnerabile alla superficie di attacco, ma cancella la visibilità su altre intrusioni. Un attaccante che ottiene RCE su Splunk può modificare query, sopprimere alert e manipolare evidenza forense. L'impatto sulla triade CIA è totale non solo per il sistema diretto, ma per l'intero ecosistema di sicurezza che dipende da esso.

Cosa resta da verificare

Il dossier non specifica il numero esatto di istanze Splunk Enterprise esposte su Internet, né riporta dati provenienti da servizi di scansione come Shodan o Censys. Non emergono sovrapposizioni infrastrutturali che colleghino gli attacchi in-the-wild alla proof-of-concept pubblicata da watchTowr Labs: gli operatori potrebbero utilizzare metodologie indipendenti o adattare il codice dei ricercatori. L'entità precisa della "limited exploitation" — sistemi coinvolti, settori colpiti, obiettivi degli attaccanti — non è documentata nelle fonti disponibili. Lo stato di patch effettivo delle agenzie federali alla deadline del 21 giugno 2026 non è riportato.

Fonti

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. tech-insider.org
  2. securityaffairs.com
  3. advisory.splunk.com
  4. penligent.ai
  5. cve.org
  6. nvd.nist.gov
  7. cisa.gov