CVE-2026-112341

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 od wersji 3.9.0 przed 4.14.9 zawiera podatność braku weryfikacji nazwy hosta TLS w module fluent-forward (wm_fluent_ssl_ctx()), pozwalającą atakującym sieciowym podszyć się pod kolektor Fluentd za pomocą dowolnego certyfikatu łańcuchującego się do skonfigurowanego ca_file. Atakujący przekierowujący połączenie przez DNS, ARP lub pozycję on-path może odbierać przesyłaną telemetrię bezpieczeństwa oraz shared_key_hexdigest do złamania offline.

Wazuh od wersji 4.3.0 przed 4.14.9 zawiera podatność SSRF w module GitHub (wm_github.c), która ufa niezweryfikowanym adresom URL paginacji Link rel="next". Atakujący kontrolujący adres URL następnej strony może zmusić managera do wysłania żądań z tokenem API GitHub do hostów atakującego, ujawniając repozytoria i ustawienia organizacji.