CVE-2026-76268: RCE non autenticato nella Patroni REST API di Splunk Enterprise

Splunk ha pubblicato l'advisory SVD-2026-1001 il 7 ottobre 2026 per correggere una falla critica nella Patroni REST API, interfaccia di gestione del clustering PostgreSQL nei search head cluster di Splunk Enterprise. La vulnerabilità CVE-2026-76268, con punteggio CVSS 9.8, consente a un attaccante con accesso di rete a un membro del cluster di eseguire comandi del sistema operativo senza credenziali.

I fatti: meccanismo e impatto

Secondo l'analisi tecnica di Horizon3.ai, la Patroni REST API orchestra il clustering PostgreSQL all'interno dell'architettura search head di Splunk Enterprise. L'advisory descrive il problema in termini precisi: l'API non richiede autenticazione per operazioni di configurazione considerate critiche. Un attaccante che raggiunga questa interfaccia su qualsiasi nodo del cluster può manipolare la configurazione per eseguire comandi del sistema operativo controllati dall'attaccante.

La classificazione CWE-306 (Missing Authentication for Critical Function) conferma la natura strutturale della falla. Non si tratta di un bypass di un meccanismo esistente, ma dell'assenza del meccanismo stesso. CVE.org e NVD concordano nella descrizione dell'impatto, con l'identificatore CVE-2026-76268 pubblicato il 7 ottobre 2026.

"an unauthenticated attacker with network access to the Patroni REST API on a search head cluster member could execute attacker-controlled operating-system commands"

Il vettore AV:N (Network) nel punteggio CVSS indica che l'exploit può essere condotto attraverso la rete. L'accesso di rete a un membro del search head cluster è condizione sufficiente; l'esposizione su Internet non è necessaria. Questo allarga la superficie di attacco a qualsiasi ambiente in cui un attaccante abbia ottenuto presenza laterale o in cui la segmentazione di rete permetta il raggiungimento dei nodi cluster.

I parametri AC:L (Attack Complexity: Low), PR:N (Privileges Required: None) e UI:N (User Interaction: None) completano il quadro di una vulnerabilità tecnicamente semplice da sfruttare una volta ottenuto l'accesso di rete. Horizon3.ai segnala l'esistenza di un repository pubblico con codice presentato come proof of concept. La fonte non conferma sfruttamento attivo in-the-wild al momento della pubblicazione dell'advisory.

Versioni e correzione

Il branch 10.4, il più recente, risulta vulnerabile dalle versioni 10.4.0 a 10.4.2, con correzione nella 10.4.3. Il branch 10.2 presenta una superficie più estesa: le versioni dalla 10.2.0 alla 10.2.6 sono interessate, con fix nella 10.2.7. Non emergono versioni affette nel branch 10.0.x o nel branch 9.4.x, esplicitamente non interessati secondo tutte e tre le fonti primarie.

Per ambienti in cui l'aggiornamento non è immediatamente attuabile, Horizon3.ai riporta un workaround documentato nel file server.conf: impostare enable_sidecar = false, con la condizione che l'organizzazione non utilizzi tre funzionalità specifiche — Edge Processor, OpAmp o pipeline dati SPL2 — che dipendono dal sidecar PostgreSQL.

Analisi DeafNews

La configurazione di Splunk Enterprise in search head cluster è diffusa in infrastrutture di sicurezza enterprise italiane, dove la piattaforma viene impiegata per l'analisi centralizzata di log e alert. La specificità di questa vulnerabilità risiede nella natura del componente vulnerabile: non un servizio esposto all'utente finale, ma un'API di gestione interna del database PostgreSQL orchestrato da Patroni.

Questa struttura riflette un pattern ricorrente in infrastrutture enterprise, dove componenti considerati interni vengono distribuiti con meccanismi di protezione incompleti. La redazione DeafNews non ha verificato indipendentemente la frequenza o la generalizzabilità di questo pattern al di fuori del caso Splunk documentato.

Per le organizzazioni italiane, il rischio potrebbe essere rilevante in ambienti con search head cluster distribuiti su più segmenti di rete, dove la segmentazione stessa potrebbe non isolare adeguatamente i nodi cluster da accessi laterali. La fonte non specifica dati di adozione geografica o settoriale, né fornisce indicazioni sulla tipica esposizione di rete di questi componenti.

Cosa fare adesso

Per le organizzazioni che operano Splunk Enterprise in configurazione search head cluster, le azioni prioritarie derivano direttamente dai dati documentati:

• Verificare la versione installata: se rientra nei range 10.4.0-10.4.2 o 10.2.0-10.2.6, pianificare l'aggiornamento rispettivamente alla 10.4.3 o 10.2.7.
• Se l'aggiornamento immediato non è fattibile e non si utilizzano Edge Processor, OpAmp o pipeline SPL2, applicare il workaround in server.conf impostando enable_sidecar = false.
• Verificare che i nodi del search head cluster siano accessibili solo da segmenti di rete autorizzati, limitando la superficie di esposizione dell'interfaccia Patroni.
• Monitorare gli accessi alle interfacce di gestione interne del cluster per rilevare connessioni anomale.

Limiti delle fonti

Questo articolo si basa principalmente sull'analisi tecnica di Horizon3.ai, integrata dai record ufficiali CVE.org e NVD. La redazione DeafNews non ha accesso a fonti indipendenti con analisi tecnica dettagliata di questa vulnerabilità. Le considerazioni di contesto per il mercato italiano sono inferenze editoriali basate sulla conoscenza generale delle architetture enterprise, non su dati specifici delle fonti citate.

La fonte primaria strutturata non conferma sfruttamento attivo in-the-wild, né fornisce stime di esposizione reale o dati di adozione delle versioni vulnerabili. Il funzionamento del proof of concept pubblico non è stato verificato indipendentemente.

Fonti

• horizon3.ai
• cve.org
• nvd.nist.gov