Kurzfassung

In den Wazuh-Workflows steckt eine kritische Schwachstelle in GitHub Actions. Angreifer können über manipulierte Pull Requests Befehle einschleusen und auf selbst gehosteten Runnern beliebigen Code ausführen. Kritisch ist vor allem der mögliche Abfluss von Secrets wie GITHUB_TOKEN oder AWS-Zugangsdaten.

Für Unternehmen im DACH-Raum ist das relevant, wenn sie Wazuh aus dem Quellcode bauen, eigene GitHub-Actions-Workflows betreiben oder Fork-/Pull-Request-Prozesse mit sensiblen Geheimnissen im Spiel haben. Wer Wazuh nur als fertiges Produkt nutzt, ist davon nicht automatisch betroffen. Entscheidend ist, ob die verwundbare Workflow-Logik in der eigenen CI/CD-Landschaft zum Einsatz kommt.

Was ist passiert?

Die Sicherheitslücke trägt die Kennung CVE-2026-67308 und wird als kritisch eingestuft. Betroffen sind Wazuh-Workflows vor dem Commit 44bf114. Der Fehler steckt in einer GitHub-Actions-Umgebung, in der Inhalte aus einer VERSION.json-Datei in Shell-Kontexte gelangen. Genau dort liegt das Problem: Ein Angreifer kann Zeichen einschleusen, die die Shell als Befehl interpretiert.

Praktisch läuft der Angriff über einen präparierten Pull Request. Wer so einen PR verarbeitet, kann unbeabsichtigt Kommandos ausführen lassen. Auf selbst gehosteten Runnern ist das besonders heikel, weil dort oft mehr Rechte, mehr Netzwerkzugang und mehr vertrauliche Umgebungsvariablen vorhanden sind als in isolierten Standard-Runnern.

Technische Details

Die Schwachstelle ist eine Shell-Injection. Das heißt: Daten, die eigentlich nur gelesen oder weitergereicht werden sollen, landen ungefiltert in einem run-Step. Wenn diese Daten Shell-Metazeichen enthalten, interpretiert die Ausführungsumgebung sie als Befehle. Aus einem harmlos wirkenden Versionswert wird so potenziell Codeausführung.

Der Angriffspfad ist laut Quelle klar umrissen: Ein manipuliertes VERSION.json-Feld reicht aus, um Umgebungseinträge zu beeinflussen, die direkt in Workflows interpoliert werden. Dadurch kann ein Angreifer Kommandos ausführen und Secrets auslesen. Genannt werden ausdrücklich GITHUB_TOKEN und AWS-Credentials. Ob noch weitere Geheimnisse betroffen sind, lässt die Quelle offen.

Wichtig ist der Kontext. Das Problem sitzt nicht in einer klassischen Server-Anwendung, sondern in der Build- und Automatisierungskette. Genau deshalb wird so etwas oft unterschätzt. Ein kompromittierter Workflow kann in der Praxis genauso gefährlich sein wie eine Schwachstelle im Produkt selbst, weil er an denselben Zugangsdaten und an derselben Lieferkette hängt.

Wer ist betroffen?

Direkt betroffen sind Wazuh-Setups, die die verwundbaren Workflows vor Commit 44bf114 einsetzen. Das betrifft vor allem Organisationen, die den Code selbst bauen, eigene CI-Pipelines pflegen oder Beiträge aus Pull Requests automatisiert testen lassen. Wer selbst gehostete Runner nutzt, hat das größere Risiko, weil dort Token, Cloud-Zugänge und interne Netze oft näher beieinander liegen.

Für reine Anwender der fertigen Wazuh-Distribution ist die Lage unklarer. Die Quelle sagt nichts dazu, ob auch veröffentlichte Pakete, Appliances oder spätere Release-Zweige betroffen sind. Wer Wazuh nur als installiertes Produkt betreibt, sollte trotzdem prüfen, ob die eigene Build- oder Integrationskette Workflows aus diesem Bereich verwendet.

Für Unternehmen in Deutschland, Österreich und der Schweiz ist das besonders dann relevant, wenn Security-Tooling im eigenen Git-Repository entwickelt oder angepasst wird. Das betrifft oft genau die Teams, die sich auf GitHub Actions verlassen und Secrets für Deployment, Monitoring oder Cloud-Zugriffe eingebunden haben. Dort reicht ein einziger unsauber behandelter PR, um mehr als nur einen Build zu kompromittieren.

Empfohlene Maßnahmen

Wer Wazuh-Workflows selbst betreibt, sollte zuerst auf den Commit 44bf114 oder eine neuere Version wechseln. Das ist der naheliegende Fix-Pfad. Danach gehört der Workflow auf den Prüfstand: keine ungeprüften Werte direkt in Shell-Befehle schreiben, Variablen strikt quoten und Eingaben vor der Verwendung validieren.

Für GitHub Actions gilt in der Praxis: Pull Requests aus fremden Quellen dürfen keinen Zugriff auf Secrets bekommen, solange der Code nicht geprüft ist. Self-hosted Runner absichern, Netzwerkzugriffe begrenzen, Token mit minimalen Rechten ausstatten. Wer AWS-Zugangsdaten im Workflow hinterlegt hat, sollte diese sofort auf notwendigen Umfang reduzieren und prüfen, ob sie schon rotiert werden müssen.

Zusätzlich lohnt ein Blick in die Historie der eigenen Workflows. Wurden in den letzten Wochen verdächtige PRs, unerwartete Job-Ausführungen oder ungewöhnliche Ausgaben auf Runnern beobachtet, sollte das Incident-Response-Team mit einem kurzen, aber sauberen Check beginnen: Logs sichern, Secrets bewerten, betroffene Tokens tauschen, Runner-Images neu aufsetzen.

Einschätzung von CyberSecurity-News.de

Die Schwachstelle ist ernst. Nicht wegen eines spektakulären Exploits, sondern weil sie an einer Stelle sitzt, an der viele Teams zu wenig hinschauen: in Automatisierung und Build-Pipelines. Wer dort Shell-Eingaben aus ungeprüften Dateien übernimmt, baut sich sein eigenes Risiko ein. Das ist kein exotischer Fehler, sondern ein klassischer Vertrauensbruch zwischen Daten und Ausführung.

Die Informationslage der Quelle ist allerdings begrenzt. Sie beschreibt den Angriffspfad und die betroffenen Secrets klar, sagt aber wenig dazu, wie breit Wazuh-Nutzer in der Praxis exponiert sind. Für die meisten Leser ist die Lage deshalb nicht pauschal kritisch, sondern abhängig von der eigenen CI/CD-Architektur. Wer keine selbst gehosteten Runner und keine verwundbaren Workflows nutzt, sollte betroffen sein können, ist es nach aktuellem Stand aber womöglich nicht.

Positiv ist: Die Gegenmaßnahmen sind bekannt und handhabbar. Negativ ist: Solche Lücken werden oft erst bemerkt, wenn jemand die Pipeline schon ausgenutzt hat. Wer GitHub Actions produktiv nutzt, sollte diese Meldung nicht als Wazuh-Detail ablegen, sondern als Anlass nehmen, die eigene Workflow-Härtung zu prüfen.

Fazit

CVE-2026-67308 zeigt, wie schnell eine CI/CD-Schwachstelle zum Geheimnis-Diebstahl wird. Das Risiko betrifft vor allem Teams, die Wazuh selbst bauen oder automatisiert aus Pull Requests verarbeiten. Für sie zählt jetzt Geschwindigkeit: Workflow anpassen, Runner absichern, Tokens prüfen.

Wer Wazuh nur als fertiges Produkt einsetzt, sollte die eigene Lage trotzdem kurz verifizieren. Die offene Frage bleibt, welche Distributions- oder Release-Varianten außerhalb des beschriebenen Workflow-Zweigs betroffen sind. Ohne diesen Check ist Entwarnung nur geraten.

Quellenangabe

Weiterführende Quelle: NVD – CVE-2026-67308