CVE-2026-61783
ŚrednieCVSS 6.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 15 - wyżej niż 15% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Ujawnienie sekretu klastra może pozwolić atakującemu na przejęcie komunikacji między węzłami i eskalację uprawnień w całej infrastrukturze Wazuh. Naruszenie poufności konfiguracji może prowadzić do dalszych ataków.
Rekomendacja
Zaleca się natychmiastową aktualizację do wersji 4.14.7, która naprawia ten problem. Należy również przejrzeć reguły RBAC i upewnić się, że reguły deny są poprawnie egzekwowane.
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, an authenticated low-privilege user can read the cluster secret from the manager configuration because the logic that masks sensitive values is disabled by any update-config RBAC rule, including an explicit deny. The mask_sensitive_config() decorator applies masking only when _has_update_permissions() returns false, but that gate treats a user as able to update the config whenever a manager:update_config or cluster:update_config rule exists, without ever checking whether the rule's effect is allow or deny. Because a deny rule is stored as a real entry, a read-only account that is hardened by explicitly denying config edits is counted as having update permission, which turns masking off. A single authenticated GET request to the configuration endpoint with raw=true then returns the verbatim ossec.conf XML with cluster.key in clear, whereas an otherwise identical account without the deny rule sees the value masked. This issue is fixed in version 4.14.7.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS