A volte i problemi più seri arrivano da funzioni che sembrano innocue. Un’anteprima di file, ad esempio. Un gesto banale per chi usa una piattaforma di analisi dei dati, ma che in certi casi può trasformarsi in qualcosa di molto più pericoloso.
È proprio quello che è emerso con una nuova vulnerabilità che riguarda Splunk.
La falla, classificata con identificativo CVE-2026-20163, consente in determinate condizioni di eseguire comandi direttamente sul server. Non un dettaglio da poco, soprattutto negli ambienti aziendali dove Splunk è parte dell’infrastruttura di monitoraggio.
Il difetto riguarda la REST API utilizzata sia da Splunk Enterprise sia dalla Splunk Cloud Platform. In particolare entra in gioco la funzione che permette di visualizzare l’anteprima dei file prima che vengano indicizzati.
Qui succede qualcosa di curioso. Se un utente possiede un ruolo con un privilegio specifico chiamato edit_cmd, può sfruttare il parametro unarchive_cmd per eseguire comandi shell arbitrari. Non stiamo parlando di un accesso anonimo, sia chiaro. Serve un livello di autorizzazione elevato.
Ma la situazione resta delicata.
Un amministratore con accessi estesi – o un account compromesso con gli stessi privilegi – potrebbe sfruttare questa debolezza per eseguire comandi direttamente sulla macchina che ospita Splunk.
Il problema nasce da una gestione non corretta dei dati forniti in input durante il processo di anteprima dei file caricati. In pratica, il sistema non filtra in modo adeguato ciò che riceve prima della fase di indicizzazione.
L’attacco passa attraverso l’endpoint REST chiamato /splunkd/_upload/indexing/preview. È lì che un utente autorizzato ma male intenzionato può inserire comandi da eseguire sul server sottostante.
Non è una vulnerabilità teorica. Il meccanismo è chiaro e sfruttabile in scenari reali se le condizioni di privilegio sono soddisfatte.
Il problema riguarda diverse versioni delle piattaforme Splunk.
Per quanto riguarda Splunk Enterprise risultano vulnerabili le versioni precedenti alla 10.2.0, alla 10.0.4, alla 9.4.9 e alla 9.3.10.
| Product | Base Version | Component | Affected Version | Fix Version |
|---|---|---|---|---|
| Splunk Enterprise | 10.2 | REST API | Not affected | 10.2.0 |
| Splunk Enterprise | 10.0 | REST API | 10.0.0 to 10.0.3 | 10.0.4 |
| Splunk Enterprise | 9.4 | REST API | 9.4.0 to 9.4.8 | 9.4.9 |
| Splunk Enterprise | 9.3 | REST API | 9.3.0 to 9.3.9 | 9.3.10 |
| Splunk Cloud Platform | 10.2.2510 | REST API | Below 10.2.2510.5 | 10.2.2510.5 |
| Splunk Cloud Platform | 10.0.2503 | REST API | Below 10.0.2503.12 | 10.0.2503.12 |
| Splunk Cloud Platform | 10.1.2507 | REST API | Below 10.1.2507.16 | 10.1.2507.16 |
| Splunk Cloud Platform | 9.3.2411 | REST API | Below 9.3.2411.24 | 9.3.2411.124 |
La soluzione indicata è semplice almeno sulla carta. Aggiornare il software alle versioni corrette dove la vulnerabilità è stata risolta. Quando l’aggiornamento immediato non è possibile, esiste comunque una mitigazione temporanea. Gli amministratori possono ridurre la superficie di attacco rimuovendo la capability edit_cmd dai ruoli che la possiedono.
La segnalazione tecnica e le indicazioni di sicurezza sono state pubblicate da Splunk nel proprio advisory ed inoltre sono state pubblicate delle patch cumulative.
Per la community di Red Hot Cyber questa storia ricorda una lezione che torna sempre: quando una piattaforma gestisce dati e automazioni su larga scala, anche funzioni apparentemente innocue come un’anteprima file meritano lo stesso livello di attenzione delle componenti più esposte.
Spesso le vulnerabilità più interessanti nascono proprio lì, dove nessuno guarda davvero o dove tutti guardano poco.