Wazuh DAPI RCE: da worker node compromesso a esecuzione codice come root sul

Il 2026-08-11 Trend Micro ha pubblicato l'advisory ZDI-26-528 su una vulnerabilità nel protocollo Cluster DAPI di Wazuh. La falla, tracciata come CVE-2026-28220 e corretta nella versione 4.14.5, permette a un attaccante network-adjacent con codice low-privileged su un worker node di eseguire codice arbitrario come root sul master node.

Il meccanismo: quando il deserializzatore diventa arma

La vulnerabilità risiede nella funzione as_wazuh_object, localizzata nel file framework/wazuh/core/cluster/common.py. Secondo l'analisi di GitHub Security Lab, il deserializzatore converte JSON contenente {"__callable__": {"__module__": "...", "__name__": "..."}} in un callable Python attivo, applicando una validazione limitata al solo top-level package — wazuh o api.

Come documenta l'advisory GHSA-w2jj-pfq9-mh9p, questo trasforma la "selezione di funzione" in input controllabile dall'attaccante, "rather than a fixed dispatch table / allowlist".

La seconda componente della catena d'attacco si trova in framework/wazuh/core/cluster/dapi/dapi.py. La funzione run_local() accetta un valore rbac_permissions fornito dal client, lo applica come contesto RBAC globale tramite common.rbac.set(rbac_permissions), quindi esegue data = f(**f_kwargs). Con rbac_mode: black e nessuna deny rule, la logica del decoratore @expose_resources espande le risorse richieste come consentite, bypassando i controlli di autorizzazione.

L'advisory ZDI-26-528 sintetizza così l'impatto: "An attacker can leverage this vulnerability to execute code in the context of root on the master node". La combinazione delle due debolezze trasforma un worker node compromesso in proxy per esecuzione arbitraria con massimi diritti sul centro di comando.

Dal PoC alla compromissione: tre scenari dimostrati

L'advisory GitHub Security Lab include un Proof-of-Concept verificato su Wazuh 4.14.3 e sul master branch al commit 98a142b. Il PoC dimostra tre azioni specifiche, codificate come P1, P2 e P3. P1 realizza scrittura arbitraria di file sotto /var/ossec/etc/, directory critica per la configurazione del prodotto. P2 crea un utente backdoor con generazione di token JWT funzionale. P3 manomette security.yaml, file di configurazione della sicurezza.

Il dato operativo rilevante: la comunicazione cluster di default avviene sulla porta 1516. Un attore network-adjacent che abbia già compromesso un worker, o che disponga della chiave cluster condivisa per autenticarsi al canale, può innescare la catena d'attacco.

Limiti delle fonti e verifiche effettuate

Le informazioni si basano su tre fonti primarie convergenti: l'advisory ZDI-26-528, il CVE Record ufficiale CVE-2026-28220, e l'advisory GitHub Security Lab GHSA-w2jj-pfq9-mh9p. La qualità complessiva delle fonti è elevata, con un'unica lacuna documentata: il CVSS score e il vettore non sono esplicitati nei testi estratti. Non risulta evidenza di exploit in-the-wild precedente alla pubblicazione coordinata del 2026-08-11.

"Two issues in Wazuh's Cluster Distributed API (DAPI) handling allow a cluster peer (or any actor who can authenticate to the cluster channel using the shared cluster key) to cause the master node to deserialize an attacker-controlled callable and execute it under an attacker-controlled RBAC context." — GitHub Security Advisory GHSA-w2jj-pfq9-mh9p

Cosa fare adesso

Il CVE Record ufficiale identifica la versione 4.14.5 come correttiva della vulnerabilità. Le organizzazioni che utilizzano Wazuh in configurazione cluster devono verificare la versione installata e pianificare l'aggiornamento. Il brief non specifica ulteriori azioni operative verificate.

Timeline e disclosure coordinata

La vulnerabilità è stata riportata al vendor il 2026-04-15. La pubblicazione coordinata dell'advisory è avvenuta il 2026-08-11. Il fix è disponibile nella versione 4.14.5.

Analisi: il paradosso della fiducia implicita

La seguente sezione contiene valutazioni editoriali basate sui fatti documentati.

Wazuh è progettato per rilevare intrusioni e anomalie negli endpoint, nei server e nei container. La sua architettura cluster riflette un modello gerarchico: worker node raccolgono dati, master node coordina analisi e policy. La vulnerabilità CVE-2026-28220 inverte questa gerarchia di protezione: un nodo periferico compromesso diventa veicolo di compromissione del centro.

Il pattern non è isolato. Piattaforme di sicurezza, SIEM e strumenti di monitoraggio condividono spesso questa struttura: i sensori periferici godono di fiducia implicita nei confronti del nodo centrale, e viceversa. La mancanza di validazione rigida sui dati serializzati — JSON che diventa callable — e l'assenza di isolamento del contesto RBAC sono sintomi della stessa radice: il cluster è stato progettato come entità unitaria, non come federazione di soggetti reciprocamente sospettosi.

Le fonti non qualificano questo come difetto sistemico del settore, ma il caso specifico di Wazuh illustra come la compromissione di un singolo worker node possa propagarsi al master con privilegi di root, attraverso meccanismi di comunicazione interna progettati per l'efficienza piuttosto che per la resilienza contro attori interni.

Fonti: ZDI Advisory ZDI-26-528; CVE Record CVE-2026-28220; GitHub Security Advisory GHSA-w2jj-pfq9-mh9p.