CVE-2026-48024
KrytyczneCVSS 9.1Prawdopodobieństwo exploitacji (EPSS)
Podwyższone ryzykoPercentyl 52 - wyżej niż 52% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Ryzyko obejmuje nadpisanie krytycznych plików konfiguracyjnych i wykonanie kodu z uprawnieniami roota, co może prowadzić do pełnego przejęcia systemu.
Rekomendacja
Zaleca się aktualizację Wazuh do wersji 4.14.6 lub 5.0.0-beta3 oraz ograniczenie zaufania do peerów klastra.
Inne podatności w Wazuh
Zobacz wszystkie- CVE-2026-61800Krytyczne
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.
- CVE-2026-49441Krytyczne
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.
- CVE-2026-48162Krytyczne
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.
- CVE-2026-67308Krytyczne
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.
- CVE-2025-24016KrytyczneAktywnie exploitowane
Wazuh to platforma do zapobiegania zagrożeniom, wykrywania i reagowania. Od wersji 4.4.0 do 4.9.1 występuje niebezpieczna deserializacja, która pozwala na zdalne wykonanie kodu na serwerach Wazuh. Atakujący może wstrzyknąć niesanityzowany słownik w żądaniu/odpowiedzi DAPI, aby wykonać dowolny kod Python.
- CVE-2026-71540Wysokie
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.
- CVE-2026-61811Średnie
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.
- CVE-2026-61802Średnie
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.
- CVE-2026-61783Średnie
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.
- CVE-2026-54085Wysokie
Wazuh w wersjach 4.2.0 do 4.14.6 ma wiele skryptów aktywnej odpowiedzi, które przekazują pola alertów kontrolowane przez atakującego do uprzywilejowanych poleceń systemowych bez walidacji formatu, umożliwiając wstrzykiwanie argumentów do narzędzi działających jako root.
Oryginalny opis (angielski, źródło NVD)
Wazuh is a free and open source platform used for threat prevention, detection, and response. From 4.0.0 until 4.14.6 and 5.0.0-beta3, cluster.unmerge_info() in framework/wazuh/core/cluster/cluster.py constructs paths from peer-controlled merge_type and name values in a merged synchronization archive. process_files_from_worker() in framework/wazuh/core/cluster/master.py does not adequately confine the resulting path to the declared cluster item directory. A cluster peer holding the shared Fernet key can use traversal in files_metadata.json or a merged-file header to write files such as /var/ossec/etc/ossec.conf. Replacing ossec.conf can configure root-executed commands and lead to code execution when Wazuh services reload. This issue is fixed in versions 4.14.6 and 5.0.0-beta3.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

