samres27/cve-2026-25769---cve-2026-25770Proof-of-concept exploit per le vulnerabilità del cluster Wazuh CVE-2026-25769 e CVE-2026-25770, che dimostrano l'esecuzione remota di codice e l'escalation dei privilegi tramite deserializzazione non sicura e sovrascrittura di file.
Avvertenza: Questo repository contiene informazioni e codice relativi a vulnerabilità di sicurezza. Usalo esclusivamente per scopi educativi o in ambienti autorizzati.
Sono state identificate due vulnerabilità critiche nella configurazione del cluster di Wazuh (versioni ≥ 4.0.0). Questi difetti interessano i deployment che utilizzano più nodi per la scalabilità orizzontale, il bilanciamento del carico e l'alta disponibilità. Questa configurazione consente la gestione di più agenti senza che il server Wazuh ne risenta.
Consente la comunicazione tra master e worker tramite una richiesta DAPi. Il worker invia un oggetto utilizzando il modulo LocalClient del worker; il master accetta il messaggio e deserializza l'oggetto con la funzione vulnerabile as_wazuh_object(), consentendo l'esecuzione di comandi sul master.
Questa vulnerabilità è complementare alla precedente e consente l'esecuzione di comandi tramite i tag <command> e <localfile>. Un attaccante può eseguire comandi ogni volta che viene caricato il file di configurazione .
/var/ossec/etc/ossec.confEntrambe consentono [impatto generale: escalation dei privilegi, esecuzione remota, ecc.] in ambienti che utilizzano la funzionalità di cluster.
Wazuh manager ≥ 4.0.0 (fino alla versione patchata X.Y.Z)
Tutti i nodi con ruolo master o worker che hanno abilitata la comunicazione tra nodi.
La configurazione del cluster viene utilizzata nei deployment con un numero elevato di agenti. Consente:
Scalabilità orizzontale: aggiungere più nodi worker per distribuire il carico.
Alta disponibilità: se un nodo worker fallisce, gli altri continuano a operare mentre il nodo viene ripristinato.
Bilanciamento del carico: gli agenti vengono distribuiti tra i worker.
Questa architettura, se non adeguatamente protetta, può esporre vettori di attacco come quelli qui documentati.
Il master chiama questa funzione, che consente la creazione del processo subprocess che esegue arbitrariamente comandi.
def as_wazuh_object(dct: Dict):
try:
if '__callable__' in dct:
encoded_callable = dct['__callable__']
funcname = encoded_callable['__name__'] #getoutput
if '__wazuh__' in encoded_callable:
# Encoded Wazuh instance method.
wazuh = Wazuh()
return getattr(wazuh, funcname)
else:
# Encoded function or static method.
qualname = encoded_callable['__qualname__'].split('.') # getoutput
classname = qualname[0] if len(qualname) > 1 else None
module_path = encoded_callable['__module__'] # subprocess
module = import_module(module_path) # ARBITRARY IMPORT
if classname is None:
return getattr(module, funcname) # RETURNS ARBITRARY FUNCTION
else:
return getattr(getattr(module, classname), funcname)
Il Protocollo di Cluster Wazuh (TCP/1516) sincronizza i file tra i nodi utilizzando il processo. Questo processo viene eseguito come utente non privilegiato, accettando percorsi relativi.
"""Create a file descriptor to store the incoming file.
Parameters
----------
data : bytes
Relative path to the file.
Returns
-------
bytes
Result.
bytes
Response message.
"""
# VULNERABLE LINE: No validation of 'data', no checking for '../', direct file open.
self.in_file[data] = {'fd': open(common.WAZUH_PATH + data.decode(), 'wb'), 'checksum': hashlib.sha256()}
return b"ok ", b"Ready to receive new file"
Utilizzando questa configurazione, l'attaccante potrebbe sovrascrivere la directory di configurazione e arrivare a eseguire comandi.
Un attaccante potrebbe:
Compromettere la riservatezza, l'integrità, la disponibilità e l'escalation dei privilegi.
Compromettere l'integrità dell'intera infrastruttura monitorata.
I PoC originali sono stati sviluppati da vikman90 e hanno costituito la base per questa analisi. Di seguito viene mostrato un esempio di sfruttamento:
# 1. init docker compose
docker compose up -d
# 2. wait init all clusters
# 3. Verify cluster is connected
docker exec poc-master /var/ossec/bin/cluster_control -l
# Expected output should show worker01 connected:
# worker01 172.28.0.11 active
# 4. Execute exploit from worker
docker exec poc-worker /var/ossec/framework/python/bin/python3 /scripts/poc.py
# 5. Verify RCE on master
docker exec poc-master cat /var/ossec/etc/ossec.conf