CVE-2026-28220
WysokieCVSS 8.4Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 9 - wyżej niż 9% wszystkich znanych CVE
Streszczenie
W Wazuh przed wersją 4.14.5 występują podatności w obsłudze klastrowego API (DAPI), które pozwalają uwierzytelnionemu węzłowi klastra lub atakującemu z kluczem klastra na deserializację złośliwego obiektu i wykonanie go w kontekście RBAC kontrolowanym przez atakującego, co umożliwia pełne przejęcie menedżera.
Ocena ryzyka
Atakujący może uzyskać pełną kontrolę nad menedżerem Wazuh, w tym zapisywać dowolne pliki, tworzyć nowych użytkowników API i modyfikować konfigurację bezpieczeństwa.
Rekomendacja
Zaktualizuj Wazuh do wersji 4.14.5 lub nowszej, która zawiera poprawkę.
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-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-61783Wysokie
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.
- CVE-2026-54084Średnie
Wazuh w wersjach 4.0.0 do 4.14.6 jest podatny na atak polegający na tym, że złośliwy menedżer rejestracji może doprowadzić do awarii agenta podczas rejestracji, zwracając odpowiedź z mniej niż czterema polami, co powoduje dereferencję wskaźnika NULL. Problem naprawiono w wersji 4.14.7.
- CVE-2026-54083Wysokie
Skrypt aktywnej odpowiedzi ip-customblock w Wazuh zawiera podatność na path traversal, która pozwala atakującemu tworzyć lub usuwać dowolne pliki w systemie jako root. Skrypt nie waliduje poprawności adresu IP w polu srcip, co umożliwia użycie sekwencji ../ do wyjścia poza katalog bazowy.
Oryginalny opis (angielski, źródło NVD)
Wazuh is a free and open source platform used for threat prevention, detection, and response. Prior to version 4.14.5, issues in the Cluster Distributed API (DAPI) handling allow a cluster peer, or any actor able to authenticate to the cluster channel using the shared cluster key, to make the master node deserialize an attacker-controlled callable and execute it under an attacker-controlled RBAC context. The cluster code in `framework/wazuh/core/cluster/common.py` deserializes JSON with `as_wazuh_object()`, which resolves any callable whose top-level package is wazuh or api (an overly broad allowlist controlled only by `ALLOWED_CALLABLES_PACKAGES`), and DAPI requests handled in framework/wazuh/core/cluster/dapi/dapi.py accept a client-supplied rbac_permissions value that `run_local()` applies as the global RBAC context, so supplying an rbac_mode of black causes authorization checks for expose_resources-protected functions to pass without any legitimate permission assignment. Combined, these allow privileged administrative actions on the master node such as arbitrary file writes under WAZUH_PATH, creation of new API users, and tampering with security.yaml, and can be chained into full manager compromise. This issue has been fixed in version 4.14.5.