CVE-2026-71540
WysokieCVSS 7.5Streszczenie
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.
Ocena ryzyka
Nieuwierzytelniony atakujący może wywołać wyczerpanie pamięci i zatrzymanie procesu klastra Wazuh, co prowadzi do zakłócenia synchronizacji i przekazywania API. Może to sparaliżować działanie klastra i wpłynąć na monitorowanie bezpieczeństwa.
Rekomendacja
Zaktualizuj Wazuh do wersji 4.14.7 lub nowszej. Do czasu aktualizacji ogranicz dostęp sieciowy do portu nasłuchu klastra i rozważ wdrożenie limitów połączeń na poziomie zapory.
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-48024Krytyczne
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.
- 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-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 an open-source security platform providing unified XDR and SIEM protection for endpoints and cloud workloads. From 3.9.0 until 4.14.7, wazuh-clusterd in framework/wazuh/core/cluster/common.py allocates a payload buffer using the size declared in a 20-byte cluster protocol header before Fernet decryption validates the peer. An unauthenticated network peer can declare a payload of up to 256 MiB, stop sending after the header, and retain that allocation until the TCP connection closes. The cluster listener has no application-level per-source connection budget in affected versions, allowing concurrent sockets to multiply memory consumption and potentially terminate the cluster process, disrupt synchronization, and interrupt distributed API forwarding. This issue is fixed in version 4.14.7.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

