samres27/cve-2026-25769---cve-2026-25770Proof-of-Concept-Exploits für Schwachstellen im Wazuh-Cluster CVE-2026-25769 und CVE-2026-25770, die Remote-Code-Ausführung und Privilegieneskalation über unsichere Deserialisierung und Dateiüberschreibung demonstrieren.
Warnung: Dieses Repository enthält Informationen und Code, die sich auf Sicherheitslücken beziehen. Verwenden Sie es ausschließlich zu Bildungszwecken oder in autorisierten Umgebungen.
Es wurden zwei kritische Schwachstellen in der Wazuh-Cluster-Konfiguration (Versionen ≥ 4.0.0) identifiziert. Diese Fehler betreffen Bereitstellungen, die mehrere Knoten für horizontale Skalierung, Lastverteilung und Hochverfügbarkeit nutzen. Diese Konfiguration ermöglicht die Verwaltung mehrerer Agenten, ohne dass der Wazuh-Server darunter leidet.
CVE-2026-25769
Ermöglicht die Kommunikation zwischen Master und Worker über eine DAPi-Anfrage. Der Worker sendet ein Objekt über das LocalClient-Modul des Workers; der Master akzeptiert die Nachricht und deserialisiert das Objekt mit der anfälligen Funktion as_wazuh_object(), was die Ausführung von Befehlen auf dem Master ermöglicht.
CVE-2026-25770
Diese Schwachstelle ergänzt die vorherige und ermöglicht die Ausführung von Befehlen über die Tags <command> und <localfile>. Ein Angreifer kann jedes Mal Befehle ausführen, wenn die Konfigurationsdatei geladen wird.
/var/ossec/etc/ossec.confBeide ermöglichen [allgemeine Auswirkungen: Privilegieneskalation, Remote-Ausführung usw.] in Umgebungen, die die Cluster-Funktionalität nutzen.
Wazuh manager ≥ 4.0.0 (bis zur gepatchten Version X.Y.Z)
Alle Knoten mit der Rolle master oder worker, die die Kommunikation zwischen Knoten aktiviert haben.
Die Cluster-Konfiguration wird in Bereitstellungen mit einer großen Anzahl von Agenten verwendet. Sie ermöglicht:
Horizontale Skalierung: Hinzufügen weiterer Worker-Knoten zur Lastverteilung.
Hochverfügbarkeit: Wenn ein Worker-Knoten ausfällt, arbeiten die anderen weiter, während der Knoten wiederhergestellt wird.
Lastverteilung: Die Agenten werden auf die Worker verteilt.
Diese Architektur kann, wenn sie nicht angemessen abgesichert ist, Angriffsvektoren wie die hier dokumentierten aussetzen.
Der Master ruft diese Funktion auf, die die Erstellung des Subprozesses ermöglicht, der beliebige Befehle ausführt.
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)
Das Wazuh-Cluster-Protokoll (TCP/1516) synchronisiert Dateien zwischen Knoten über den Prozess. Dieser Prozess läuft als nicht privilegierter Benutzer und akzeptiert relative Pfade.
"""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"
Mit dieser Konfiguration könnte der Angreifer das Konfigurationsverzeichnis überschreiben und Befehle ausführen.
Ein Angreifer könnte:
Vertraulichkeit, Integrität, Verfügbarkeit und Privilegieneskalation beeinträchtigen.
Die Integrität der gesamten überwachten Infrastruktur gefährden.
Die ursprünglichen PoCs wurden von vikman90 entwickelt und dienten als Grundlage für diese Analyse. Nachfolgend ein Beispiel für die Ausnutzung:
# 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