CVE-2026-49392

Wazuh od wersji 4.1.1 do 4.14.8 zawiera podatność na przechodzenie po ścieżkach w funkcjach upload_list_file, upload_rule_file i upload_decoder_file, umożliwiającą złośliwym pracownikom klastra zapisywanie plików w dowolnych lokalizacjach. Atakujący posiadający klucz klastra mogą wysyłać żądania DistributedAPI z sekwencjami ../ w nazwach plików, omijając walidację kontrolera REST, aby zapisywać pliki jako użytkownik wazuh.

Wazuh od wersji 3.9.0 przed 4.14.8 zawiera podatność na nadpisanie dowolnych plików w funkcji MasterHandler.process_files_from_worker, umożliwiającą pracownikowi klastra nadpisanie chronionych plików mastera. Atakujący kontrolujący pracownika może wykorzystać obejście z ukośnikiem na końcu nazwy i brak egzekwowania extra_valid, aby nadpisać ossec.conf i agent.conf, osiągając zdalne wykonanie kodu jako root na menedżerze i wszystkich agentach.

Wazuh w wersjach 4.4.0 do 4.14.6 zawiera podatność, która pozwala posiadaczowi klucza klastra na zapisywanie, nadpisywanie lub usuwanie dowolnych plików w katalogu /var/ossec na węzłach roboczych, co może prowadzić do zdalnego wykonania kodu jako root. Problem wynika z niepełnej weryfikacji ścieżek podczas synchronizacji plików klastra. Luka została naprawiona w wersji 4.14.7.

W platformie Wazuh od wersji 4.3.0 do 4.14.6 oraz 5.0.0-beta3, funkcja process_files_from_worker() w framework/wazuh/core/cluster/master.py ufa kontrolowanemu przez peera kluczowi file_path z pliku files_metadata.json. Ścieżka docelowa jest łączona z WAZUH_PATH bez sprawdzenia, czy pozostaje w wybranym katalogu. Peer klastra posiadający wspólny klucz Fernet może przesłać spreparowane archiwum i nadpisać wrażliwe pliki, takie jak /var/ossec/etc/ossec.conf, co może prowadzić do wykonania kodu po przeładowaniu usług.

W platformie Wazuh od wersji 4.0.0 do 4.14.6 oraz 5.0.0-beta3, funkcja DistributedAPI.send_tmp_file() w framework/wazuh/core/cluster/dapi/dapi.py łączy kontrolowaną przez atakującego wartość tmp_file z WAZUH_PATH bez kanonizacji lub ograniczenia. Peer klastra posiadający wspólny klucz Fernet może użyć traversal lub ścieżki bezwzględnej, aby zmusić mastera do zwrócenia dowolnego czytelnego pliku przez kanał klastra. Odczytanie /var/ossec/api/configuration/security/private_key.pem pozwala na sfałszowanie tokenów administratora REST API i wykonywanie uprawnień administracyjnych bez tworzenia konta.

W platformie Wazuh od wersji 4.0.0 do 4.14.6 oraz 5.0.0-beta3, funkcja cluster.unmerge_info() w framework/wazuh/core/cluster/cluster.py konstruuje ścieżki z kontrolowanych przez peera wartości merge_type i name w scalonym archiwum synchronizacji. Funkcja process_files_from_worker() w framework/wazuh/core/cluster/master.py nie ogranicza odpowiednio wynikowej ścieżki do zadeklarowanego katalogu elementu klastra. Peer klastra posiadający wspólny klucz Fernet może użyć traversal w files_metadata.json lub nagłówku scalonego pliku, aby zapisać pliki takie jak /var/ossec/etc/ossec.conf, co może prowadzić do wykonania kodu po przeładowaniu usług Wazuh.

Workflows Wazuh przed commit 44bf114 zawierają podatność na wstrzyknięcie poleceń powłoki w GitHub Actions, która umożliwia atakującym wykonanie dowolnych poleceń poprzez przesłanie pull requestów ze spreparowanymi plikami VERSION.json. Atakujący mogą wstrzyknąć metaznaki powłoki do zmiennych środowiskowych, które są bezpośrednio interpolowane w krokach run, umożliwiając wykonanie poleceń i eksfiltrację sekretów, w tym GITHUB_TOKEN i poświadczeń AWS na samoobsługowych runnerach.

Wazuh w wersjach od 4.1.1 przed 4.14.8 zawiera lukę path traversal w helperze get_list_file, która pozwala złośliwym workerom klastra odczytywać dowolne pliki poprzez niezwalidowane wartości nazw plików. Atakujący posiadający klucz klastra może wysyłać żądania DistributedAPI z nazwami plików zawierającymi traversal, aby odczytać client.keys, ossec.conf z kluczem klastra oraz inne pliki czytelne dla Wazuh.

Wazuh w wersjach od 4.0.0 do 4.14.8 zawiera wyścig w ograniczaniu prób logowania, który pozwala nieuwierzytelnionym atakującym ominąć limit max_login_attempts poprzez wysyłanie równoczesnych żądań. Atakujący mogą wysyłać serie logowań do endpointów authenticate i run_as, które przechodzą kontrolę blokady przed zliczeniem nieudanych prób, umożliwiając nieograniczone zgadywanie haseł.