Ing. Calogero Bono
Il 9 novembre 2026 l'Agenzia per la cybersicurezza nazionale ha pubblicato un alert sul SIEM open source Wazuh. Sono disponibili Proof of Concept per 8 vulnerabilità, 5 delle quali di gravità alta, che toccano Wazuh e i suoi Dashboard Plugins. Il vendor ha già corretto i difetti, ma gli exploit dimostrativi pubblici abbassano la soglia per chi vuole provarci. Chi usa Wazuh per controllare la sicurezza della propria infrastruttura deve verificare la versione installata.
Qualche termine, prima di entrare nei fatti. SIEM è un sistema che raccoglie e analizza i log per far emergere attacchi. XDR estende il controllo a più strati, dai dispositivi alla rete. Un PoC (Proof of Concept) è un codice dimostrativo che prova che la falla è sfruttabile. Il CVSS è il punteggio da 0 a 10 che misura la gravità. La SSRF è un attacco che induce un server a inviare richieste verso un indirizzo scelto dall'aggressore.
Cosa ha segnalato l'ACN su Wazuh?
L'alert AL02/261109/CSIRT-ITA riguarda 8 vulnerabilità con PoC resi pubblici. Le tipologie elencate sono esecuzione di codice arbitrario, bypass dell'autenticazione, bypass delle restrizioni di sicurezza, divulgazione di informazioni, denial of service e spoofing.
Nella tabella dell'agenzia tutte le falle risultano con PoC presente, mentre per lo sfruttamento attivo non c'è alcuna indicazione. L'alert è alla versione 1.0.
Quali versioni di Wazuh sono vulnerabili?
Secondo l'ACN sono interessati Wazuh nelle versioni precedenti alla 4.14.9 e i Wazuh Dashboard Plugins dalla 4.9.0 fino alla 4.14.9 esclusa. La mitigazione indicata è aggiornare tempestivamente all'ultima versione disponibile.
Il vendor, spiega l'agenzia, ha già sanato i difetti. Il rischio quindi pesa soprattutto su chi non ha ancora applicato l'aggiornamento.
Quali sono le falle più gravi?
In cima c'è CVE-2026-112340, con CVSS v4.0 di 8.8. Riguarda l'endpoint /api/request dei plugin Dashboard. Un utente autenticato potrebbe sovrascrivere il token Bearer e operare come un'altra identità della Manager API.
Seguono CVE-2026-112339 (8.2), dovuta alla mancata verifica dell'hostname TLS nel modulo fluent-forward, e CVE-2026-112338 (8.2), una SSRF nel modulo GitHub. Nel primo caso un attaccante in posizione on-path potrebbe impersonare il collector Fluentd e leggere la telemetria. Nel secondo il Manager potrebbe inviare il token GitHub a un host controllato dall'aggressore.
Completano le cinque alte CVE-2026-112341 e CVE-2026-112336, entrambe a 7.1.
Cosa rischiano i sistemi con le altre vulnerabilità?
CVE-2026-112341 è una SQL Injection. Un utente con permesso agent – read su almeno un agent potrebbe eseguire query arbitrarie e leggere dati del database del Manager, comprese le internal_key degli agent. CVE-2026-112336 è invece un memory leak nel decoder JSON. Eventi con campi statici duplicati, inviati da un agent registrato, potrebbero far arrestare wazuh-analysisd e fermare la generazione degli alert.
Le altre tre hanno punteggi tra 6.3 e 6.9.
- CVE-2026-112334, scrittura fuori dai limiti in wazuh-execd, con arresto dell'Active Response.
- CVE-2026-112335, stack buffer overflow nel logcollector, con possibile esecuzione di codice in particolari configurazioni.
- CVE-2026-112337, SSRF nel modulo Azure, con il token Microsoft Graph a rischio.
Limiti da conoscere
L'alert non indica sfruttamento attivo, e la colonna dedicata resta vuota. Non sappiamo quanti sistemi italiani siano esposti né da quando i PoC circolano. Molti attacchi richiedono condizioni precise, come un utente autenticato, il controllo di un file di log o una posizione di rete privilegiata. Alcuni identificativi CVE potrebbero ricevere aggiornamenti dai database ufficiali.
Cosa cambia per chi lavora con il digitale
Se gestisci Wazuh, controlla subito la versione di Manager e Dashboard Plugins. Anche chi ha il servizio su un server in hosting deve sapere chi si occupa degli aggiornamenti, e una gestione dei server con aggiornamenti di sicurezza serve proprio a questo. Il rischio riguarda anche i token collegati, come quelli di GitHub e Azure, che vanno trattati come credenziali da proteggere. Non è la prima segnalazione recente su strumenti tecnici, come mostra il caso di Apache OFBiz.
Il nostro parere
Colpisce che il bersaglio sia uno strumento nato per difendere. Un SIEM vede log, credenziali e telemetria di tutta l'infrastruttura, quindi una sua falla vale più di quella di un'applicazione qualunque. Il vendor ha corretto e l'ACN ha avvisato in modo chiaro, ma l'open source non esime dall'aggiornare. Chi l'adotta in azienda deve mettere in conto la manutenzione, come ricorda la guida su open source in azienda.
Domande frequenti
Wazuh è sotto attacco attivo?
L'alert dell'ACN non l'indica. La colonna dello sfruttamento riporta un trattino per tutte le CVE, mentre i PoC risultano presenti.
Quale versione di Wazuh devo installare?
Almeno la 4.14.9. Sono vulnerabili le versioni di Wazuh precedenti e i Dashboard Plugins dalla 4.9.0 alla 4.14.9 esclusa.
Quante sono le vulnerabilità e quanto sono gravi?
Sono 8, di cui 5 di gravità alta. Il punteggio CVSS v4.0 più alto è 8.8, quello più basso 6.3.
Serve essere autenticati per sfruttarle?
Dipende dalla falla. Alcune richiedono un utente autenticato o un agent registrato, altre un attaccante in posizione di rete privilegiata o con accesso a file monitorati.
Cosa rischiano i token di GitHub e Azure?
Due SSRF potrebbero far inviare al Manager i token verso host controllati dall'attaccante. Secondo l'ACN ciò consentirebbe l'accesso a repository GitHub o a risorse Microsoft Graph collegate.
Cosa guardare dopo l'aggiornamento di Wazuh
Aggiornare chiude le falle note, ma i PoC pubblici restano disponibili e possono essere adattati. Nelle prossime settimane conviene controllare cosa è accaduto nel frattempo.
- Verifica nei log del Manager richieste anomale verso host esterni o riavvii imprevisti di wazuh-analysisd.
- Controlla se l'ACN aggiorna l'alert con indicazioni di sfruttamento attivo.
- Valuta la rotazione dei token GitHub e Azure collegati ai moduli di Wazuh, se i sistemi sono rimasti non aggiornati.
