Kurzfassung

Wazuh hat eine kritische Schwachstelle in der Cluster-Synchronisation. Betroffen sind die Versionen 4.4.0 bis 4.14.6. Wer den Cluster-Key besitzt, kann auf Worker-Nodes Dateien unter /var/ossec schreiben, überschreiben oder löschen. Im schlimmsten Fall läuft darüber Code mit Root-Rechten.

Für Unternehmen mit Wazuh-Cluster ist das ernst. Ohne Patch bleibt ein interner Angriffspfad offen, der direkt auf die Integrität von Sicherheitskomponenten zielt. Version 4.14.7 schließt die Lücke.

Was ist passiert?

Die Schwachstelle steckt in der Art, wie Wazuh Dateien zwischen Master- und Worker-Nodes abgleicht. Ein Teilnehmer mit Cluster-Key kann dabei Pfade innerhalb von /var/ossec gezielt beeinflussen. Das System prüft zwar, ob der Pfad unterhalb dieses Verzeichnisses bleibt. Es prüft aber nicht sauber genug, ob die Datei am vorgesehenen Ziel der jeweiligen Cluster-Komponente landet.

Genau dieser Fehler reicht aus, um Dateien an Stellen abzulegen, die später als Root verarbeitet werden. Auch der Löschpfad hat dieselbe Lücke. Laut NVD ist das ein unvollständiger Fix für CVE-2026-30893: Die frühere Schwachstelle blockierte den Weg aus /var/ossec heraus, ließ aber Umleitungen innerhalb des Verzeichnisses zu.

Technische Details

CVE-2026-61800 ist als kritisch eingestuft. Der Fehler betrifft die Funktion update_master_files_in_worker() im nicht zusammengeführten Branch der Cluster-Dateisynchronisation. Dort verschiebt Wazuh gestagte Dateien an ein Ziel, das nur über safe_join() begrenzt wird. Das verhindert zwar Traversal außerhalb von /var/ossec, reicht hier aber nicht aus.

Der entscheidende Punkt: Die zusätzliche Zielprüfung, die auf dem Primary Node und im zusammengeführten Worker-Zweig vorhanden war, fehlt in diesem Pfad. Dadurch kann ein Peer Dateien an vom Angreifer gewählte Orte innerhalb von /var/ossec platzieren. Wenn diese Pfade später mit Root-Rechten genutzt werden, wird daraus Remote Code Execution als Root.

Die Schwachstelle ist in Version 4.14.7 behoben. Ob andere, nicht genannte Branches oder Backports betroffen sind, lässt die Quelle offen.

Wer ist betroffen?

Betroffen sind Wazuh-Installationen in den Versionen 4.4.0 bis 4.14.6, sofern Cluster-Funktionen genutzt werden und ein Angreifer den Cluster-Key kennt oder erbeutet hat. Für Einzelinstallationen ohne Cluster-Setup dürfte das Risiko deutlich geringer sein. Die Schwachstelle lebt vom internen Vertrauensmodell zwischen den Knoten.

Für Unternehmen im DACH-Raum ist das relevant, wenn Wazuh zentral für XDR-, SIEM- oder Endpoint-Überwachung läuft. Dann reicht ein kompromittierter Cluster-Zugang, um die Sicherheitsplattform selbst anzugreifen. Das ist kein Massenproblem für Privatnutzer, sondern ein klarer Admin-Fehlerpfad in professionellen Umgebungen.

Empfohlene Maßnahmen

Wer Wazuh im Einsatz hat, sollte zuerst prüfen, ob Version 4.14.7 oder neuer läuft. Wenn nicht, hat das Update Priorität. Patchen Sie nicht nur den Manager, sondern alle Cluster-Knoten, die an der Synchronisation beteiligt sind.

Danach gehört der Cluster-Key auf den Prüfstand. Tauschen Sie ihn aus, wenn Sie nicht sicher ausschließen können, dass er offengelegt wurde. Begrenzen Sie außerdem den Zugriff auf Cluster-Kommunikation strikt auf die nötigen Systeme und Netze. Ein sicherer Schlüssel nützt wenig, wenn ihn zu viele Server oder Segmente sehen.

Für den Betrieb heißt das auch: Dateirechte und Pfade unter /var/ossec kontrollieren, ungewöhnliche Dateibewegungen prüfen und Logs auf Auffälligkeiten in der Cluster-Synchronisation auswerten. Wer Anzeichen für Manipulation findet, sollte den Vorfall wie einen möglichen internen Kompromiss behandeln.

Einschätzung von CyberSecurity-News.de

Die Lücke ist technisch sauber beschrieben und in ihrer Wirkung unangenehm klar. Kritisch ist hier weniger ein exotischer Exploit, sondern die Kombination aus Vertrauen im Cluster und Root-Kontext auf den Worker-Nodes. Genau solche Fehler landen oft erst spät im Fokus, weil sie nur in produktiven Mehrknoten-Setups wehtun.

Für die meisten Leser ohne Wazuh-Cluster ist das Thema überschaubar. Für Betreiber einer solchen Umgebung ist es dagegen ein echter Handlungsfall. Die Kommunikation über den unvollständigen Fix zu CVE-2026-30893 wirkt außerdem wie ein Hinweis darauf, dass die erste Korrektur nicht tief genug ging. Das sollte Admins bei ähnlichen Fällen wachsam machen: Patchen allein reicht nicht immer, wenn die Architektur weiter Angriffsflächen offen lässt.

Fazit

CVE-2026-61800 ist eine kritische Wazuh-Schwachstelle mit echtem Impact auf die Systemintegrität. Wer Wazuh 4.4.0 bis 4.14.6 in einem Cluster betreibt, sollte zügig auf Version 4.14.7 wechseln und den Cluster-Key sowie die Synchronisationspfade prüfen. Für produktive Security-Plattformen gehört das auf die Sofortliste.

Quellenangabe

Weiterführende Quelle: NVD: CVE-2026-61800