CVE-2026-61811
ŚrednieCVSS 6.5Streszczenie
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.
Ocena ryzyka
Atakujący z uprawnieniami agenta może wywołać awarię procesu analizy logów, prowadząc do odmowy usługi i utraty widoczności bezpieczeństwa. Limit głębokości elementów w _ReadElem() nie ogranicza liczby atrybutów, więc nie zapobiega temu problemowi.
Rekomendacja
Zaktualizuj Wazuh do wersji 4.14.7 lub nowszej. Do czasu aktualizacji rozważ ograniczenie zaufania do agentów mogących wysyłać zdarzenia Windows EventChannel.
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-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-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.8.0 until 4.14.7, the _getattributes() function in src/os_xml/os_xml.c recursively processes every XML attribute without a depth limit while allocating two large local buffers in each stack frame. An enrolled agent can submit a Windows EventChannel event containing an element with enough attributes to exhaust the analysisd worker-thread stack, trigger a segmentation fault, and interrupt log ingestion. The element-depth limit in _ReadElem() does not constrain the number of attributes on one element, so it does not prevent this condition. This issue is fixed in version 4.14.7.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

