CVE-2026-56699

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, open-source platforma bezpieczeństwa XDR i SIEM, w wersjach od 3.9.0 do 4.14.7 zawiera podatność w wazuh-clusterd w pliku framework/wazuh/core/cluster/common.py, gdzie bufor ładunku jest alokowany na podstawie rozmiaru zadeklarowanego w 20-bajtowym nagłówku protokołu klastra przed walidacją przez deszyfrowanie Fernet. Nieuwierzytelniony peer sieciowy może zadeklarować ładunek do 256 MiB, przerwać wysyłanie po nagłówku i utrzymać alokację do zamknięcia połączenia TCP. Nasłuch klastra nie ma limitu połączeń na źródło, co pozwala równoległym gniazdom zwielokrotnić zużycie pamięci i potencjalnie zakończyć proces klastra, zakłócając synchronizację i przekazywanie API. Problem naprawiono w wersji 4.14.7.

W platformie Wazuh od wersji 3.8.0 do 4.14.7 funkcja _getattributes() w src/os_xml/os_xml.c rekurencyjnie przetwarza każdy atrybut XML bez limitu głębokości, alokując przy tym dwa duże bufory lokalne w każdej ramce stosu. Zarejestrowany agent może wysłać zdarzenie Windows EventChannel z elementem o dużej liczbie atrybutów, wyczerpując stos wątku roboczego analysisd i powodując błąd segmentacji oraz przerwanie zbierania logów.

W Wazuh w wersjach 4.14.0 do 4.14.6, użytkownik API z niskimi uprawnieniami może odczytać klucz klastra w postaci jawnego tekstu z punktu końcowego konfiguracji, który nie maskuje go. Punkt końcowy GET /cluster/local/config zwraca konfigurację klastra lokalnego węzła, w tym klucz w postaci jawnej, podczas gdy inne punkty końcowe zwracają tę samą wartość zamaskowaną. Każde konto z domyślną rolą readonly lub cluster_readonly, które jest jawnie pozbawione uprawnień update-config, otrzymuje prawdziwy klucz klastra.

Wazuh w wersjach 4.14.0 do 4.14.6 umożliwia uwierzytelnionemu użytkownikowi o niskich uprawnieniach odczytanie sekretu klastra z konfiguracji menedżera. Dzieje się tak, ponieważ logika maskująca wrażliwe wartości jest wyłączana przez dowolną regułę RBAC typu update-config, nawet jeśli jest to reguła deny.