Kritische Wazuh-Schwachstelle erlaubt Dateischreibzugriff bis hin zu Codeausführung

Kurzfassung

Wazuh hat eine kritische Schwachstelle im Cluster-Mechanismus. Betroffen sind Versionen von 4.0.0 bis 4.14.5 sowie 5.0.0-beta3. Ein Cluster-Partner mit dem gemeinsamen Fernet-Schlüssel kann Dateien außerhalb des vorgesehenen Verzeichnisses schreiben. Im schlimmsten Fall lässt sich dadurch die Konfigurationsdatei so ersetzen, dass beim Neuladen der Dienste Code mit Root-Rechten ausgeführt wird.

Für Unternehmen mit Wazuh-Cluster ist das kein theoretisches Problem. Wer den Betrieb an einen Cluster gekoppelt hat, sollte die Version sofort prüfen und die Aktualisierung priorisieren. Für Einzelinstallationen ohne Cluster ist das Risiko nach der vorliegenden Beschreibung deutlich geringer.

Was ist passiert?

Die Schwachstelle steckt in der Verarbeitung von Synchronisationsdaten zwischen Wazuh-Clusterknoten. Der Cluster baut Dateipfade aus Feldern, die ein Peer beeinflussen kann. Gleichzeitig begrenzt die Weiterverarbeitung diese Pfade nicht sauber genug auf das erwartete Verzeichnis. Dadurch kann ein bösartiger oder kompromittierter Cluster-Partner per Pfadmanipulation Dateien an unerwünschte Stellen schreiben.

Die NVD bewertet das Problem als kritisch. Der Hersteller hat es in 4.14.6 und in 5.0.0-beta3 behoben. Ob weitere Nebenwirkungen über das Überschreiben von Dateien hinaus möglich sind, geht aus der Beschreibung nicht hervor.

Technische Details

Auslöser ist die Kombination aus zwei Schwächen im Cluster-Workflow. Erstens werden Werte wie merge_type und name beim Aufbau eines Pfads verwendet. Zweitens prüft die nachgelagerte Verarbeitung nicht hart genug, ob das Ziel wirklich im vorgesehenen Cluster-Item-Verzeichnis liegt. Das eröffnet einen klassischen Traversal-Pfad.

Der relevante Angriffspfad ist dabei nicht extern über das Netz ohne Weiteres offen. Ein Angreifer braucht laut Beschreibung einen Cluster-Peer und damit den gemeinsamen Fernet-Schlüssel. Das macht die Sache aber nicht harmlos. In einem realen Umfeld reicht oft schon ein kompromittierter Knoten, ein gestohlener Schlüssel oder eine unsaubere Trennung von Cluster-Partnern.

Besonders heikel ist das Szenario mit /var/ossec/etc/ossec.conf. Wird diese Datei überschrieben, können über die Konfiguration Befehle mit Root-Rechten angestoßen werden. Beim nächsten Reload der Wazuh-Dienste kann daraus Codeausführung werden. Das ist der Punkt, an dem aus einem Dateischreibfehler ein vollwertiges Systemproblem wird.

Wer ist betroffen?

Betroffen sind Wazuh-Installationen ab 4.0.0 bis einschließlich 4.14.5 sowie 5.0.0-beta3. Die Lücke betrifft den Cluster-Betrieb, nicht jede beliebige Wazuh-Installation im Alleingang. Wer Wazuh nur lokal oder ohne Cluster einsetzt, ist nach der aktuellen Beschreibung deutlich weniger exponiert.

Für Unternehmen im DACH-Raum ist vor allem die operative Seite relevant. Wazuh läuft oft in Umgebungen, in denen Logs, Agenten und Security-Automation zentral zusammenlaufen. Fällt der Cluster aus oder wird er manipuliert, leidet nicht nur die Sichtbarkeit. Im Ernstfall kann auch die Integrität der Sicherheitsplattform selbst kippen.

Privatnutzer sind hier kaum die Zielgruppe. Wazuh ist ein Enterprise- und Admin-Werkzeug. Wer die Software im Heimlabor betreibt, sollte die Lücke dennoch ernst nehmen, wenn ein Cluster im Spiel ist.

Empfohlene Maßnahmen

Erstens: Version prüfen. Wer noch auf 4.14.5 oder älter sitzt, sollte auf 4.14.6 gehen. Für den Beta-Zweig gilt laut Beschreibung 5.0.0-beta3 als gefixt. Alles darunter bleibt angreifbar.

Zweitens: Cluster-Architektur prüfen. Wenn ein Knoten kompromittiert sein könnte, muss der Fernet-Schlüssel als potenziell offengelegt gelten. Dann reicht ein reines Patchen unter Umständen nicht. Schlüsselrotation und eine Prüfung der Cluster-Teilnehmer gehören in so einem Fall auf die Liste.

Drittens: Konfigurationsdateien absichern und auf Manipulation prüfen. Besonders ossec.conf ist kritisch, weil daraus Root-Befehle folgen können. Wer Dateiintegritätskontrollen, zentrale Backups und saubere Wiederherstellungswege hat, reduziert den Schaden. Das ersetzt den Patch nicht, macht die Lage aber beherrschbarer.

Viertens: Logs auf ungewöhnliche Schreibvorgänge und Cluster-Aktionen prüfen. Auffällige Pfade, fremde Dateinamen oder unerwartete Änderungen an Wazuh-Konfigurationen sind ein Warnsignal. Admins sollten dabei nicht nur auf Malware-Indikatoren schauen, sondern auch auf Integritätsverletzungen.

Einschätzung von CyberSecurity-News.de

Die Schwachstelle ist ernst, weil sie direkt an der Vertrauenskette im Cluster ansetzt. Wer eine Sicherheitsplattform betreibt, erwartet gerade dort saubere Trennung und harte Pfadkontrollen. Beides fehlt hier offenbar an einer Stelle, an der ein Angreifer mit gültigem Cluster-Zugang sehr weit kommt.

Die Informationslage ist zugleich klar genug, um Prioritäten zu setzen, aber nicht so breit, dass man mehr hineinlesen sollte als vorhanden ist. Es geht um einen autorisierten Cluster-Peer mit Schlüssel, nicht um einen frei aus dem Internet ausnutzbaren Einzeiler. Manche Berichte werden solche Lücken reflexartig aufblasen. Das hilft niemandem. Für Betreiber mit Wazuh-Cluster bleibt die Lage trotzdem hochkritisch.

Praktisch heißt das: Wer Wazuh produktiv im Cluster fährt, patcht jetzt. Nicht beim nächsten Wartungsfenster, sondern vorgezogen. Und wer schon einen kompromittierten Knoten vermutet, muss das Problem als mögliche Systemübernahme behandeln.

Fazit

CVE-2026-48024 ist eine kritische Wazuh-Lücke mit realem Missbrauchspotenzial im Cluster-Betrieb. Ein Angreifer mit Cluster-Zugang kann Dateien an falscher Stelle ablegen und im Extremfall Codeausführung auslösen. Für DACH-Unternehmen mit Wazuh-Cluster ist das eine Priorität eins. Die Schwachstelle gehört sofort auf den Patch-Plan.