CVE-2026-61802
ŚrednieCVSS 6.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 35 - wyżej niż 35% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Ujawnienie klucza klastra nieuprzywilejowanemu kontu stanowi warunek wstępny uwierzytelnienia dla zdalnego wykonania kodu w łańcuchach ataków między węzłami klastra, co może prowadzić do pełnego przejęcia systemu.
Rekomendacja
Należy natychmiast zaktualizować Wazuh do wersji 4.14.7 lub nowszej, która zawiera poprawkę, oraz sprawdzić logi dostępu do API pod kątem nieautoryzowanych odczytów konfiguracji klastra.
Inne podatności w Wazuh
Zobacz wszystkie- CVE-2026-74043Krytyczne
Wazuh od wersji 4.1.1 do 4.14.8 zawiera podatność na przechodzenie po ścieżkach w funkcjach upload_list_file, upload_rule_file i upload_decoder_file, umożliwiającą złośliwym pracownikom klastra zapisywanie plików w dowolnych lokalizacjach. Atakujący posiadający klucz klastra mogą wysyłać żądania DistributedAPI z sekwencjami ../ w nazwach plików, omijając walidację kontrolera REST, aby zapisywać pliki jako użytkownik wazuh.
- CVE-2026-74040Krytyczne
Wazuh od wersji 3.9.0 przed 4.14.8 zawiera podatność na nadpisanie dowolnych plików w funkcji MasterHandler.process_files_from_worker, umożliwiającą pracownikowi klastra nadpisanie chronionych plików mastera. Atakujący kontrolujący pracownika może wykorzystać obejście z ukośnikiem na końcu nazwy i brak egzekwowania extra_valid, aby nadpisać ossec.conf i agent.conf, osiągając zdalne wykonanie kodu jako root na menedżerze i wszystkich agentach.
- 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-93347Średnie
Wazuh w wersjach od 4.1.1 przed 4.14.8 zawiera lukę path traversal w helperze get_list_file, która pozwala złośliwym workerom klastra odczytywać dowolne pliki poprzez niezwalidowane wartości nazw plików. Atakujący posiadający klucz klastra może wysyłać żądania DistributedAPI z nazwami plików zawierającymi traversal, aby odczytać client.keys, ossec.conf z kluczem klastra oraz inne pliki czytelne dla Wazuh.
- CVE-2026-93346Średnie
Wazuh w wersjach od 4.0.0 do 4.14.8 zawiera wyścig w ograniczaniu prób logowania, który pozwala nieuwierzytelnionym atakującym ominąć limit max_login_attempts poprzez wysyłanie równoczesnych żądań. Atakujący mogą wysyłać serie logowań do endpointów authenticate i run_as, które przechodzą kontrolę blokady przed zliczeniem nieudanych prób, umożliwiając nieograniczone zgadywanie haseł.
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. In versions 4.14.0 through 4.14.6, a low-privilege API user can read the cleartext cluster key from a configuration endpoint that fails to redact it. The REST API provides a masking control, mask_sensitive_config, that redacts sensitive fields such as authd.pass and cluster.key from configuration responses for users who lack update-config permission, and every config-read endpoint carries this decorator except GET /cluster/local/config. That endpoint, backed by read_config_wrapper, is gated only by cluster:read and returns the local node's cluster configuration including the cleartext key, whereas its siblings return the same value masked. As a result, any account with the default readonly or cluster_readonly role, which is explicitly denied update-config precisely so it cannot view secrets, receives the real cluster key. Because the cluster key authenticates and encrypts traffic between cluster nodes, disclosing it to an unprivileged account provides the authentication precondition for the cluster-peer remote code execution chains established by prior advisories. This issue is fixed in version 4.14.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS