Wazuh 4.14.7: wyciek klucza klastra może prowadzić do root RCE

Wazuh 4.14.7 naprawia zestaw podatności, które warto analizować jako łańcuch, a nie sześć odseparowanych numerów. CVE-2026-61802 i CVE-2026-61783 ujawniają współdzielony klucz klastra kontom o małych uprawnieniach. CVE-2026-61800 pozwala posiadaczowi tego klucza zapisywać, nadpisywać lub usuwać pliki pod /var/ossec na workerach, co może prowadzić do wykonania kodu jako root. CVE-2026-54083 i CVE-2026-54085 dotyczą uprzywilejowanych skryptów Active Response, a CVE-2026-54084 — awarii agenta podczas enrollmentu przez niezweryfikowanego managera.

Rekordy trafiły do NVD 28 sierpnia, podczas gdy biuletyny GitHub projektu opublikowano 18 sierpnia. Dzisiejsza data oznacza więc nową widoczność w katalogach podatności. Administratorzy powinni przejść do Wazuh 4.14.7 lub nowszego wspieranego wydania, a po możliwym ujawnieniu cluster.key również przeprowadzić kontrolowaną rotację sekretu.

To szczególnie istotne, ponieważ Wazuh jest narzędziem bezpieczeństwa z dostępem do logów, agentów i reakcji wykonywanych na hostach. Kompromitacja warstwy zarządzania może wyłączyć detekcję, zmienić dowody albo wykorzystać zaufany kanał obronny do działań na wielu systemach.

CVE-2026-61802: endpoint bez maskowania zwraca cluster.key

API Wazuh ma dekorator mask_sensitive_config, który ukrywa authd.pass i cluster.key przed użytkownikami bez prawa do aktualizacji konfiguracji. Większość endpointów odczytujących ustawienia stosowała tę kontrolę. Zabrakło jej przy GET /cluster/local/config.

Endpoint wymagał jedynie cluster:read. Domyślne role readonly i cluster_readonly spełniają ten warunek, choć celowo nie mają uprawnienia do modyfikowania konfiguracji. W odpowiedzi otrzymywały rzeczywisty klucz zamiast zamaskowanej wartości. Advisory ocenia sam wyciek na CVSS 3.1: 6,5 (Medium) i wskazuje wersje 4.14.0–4.14.6; poprawka jest w 4.14.7.

Sekret klastra uwierzytelnia i szyfruje ruch master–worker. Sam odczyt nie wykonuje kodu. Dostarcza jednak warunek uwierzytelnienia potrzebny do znanych ataków na protokół klastra, jeśli port klastra jest osiągalny. To przykład, w którym bazowa ocena pojedynczego CVE nie opisuje całego blast radius po połączeniu z inną luką.

CVE-2026-61783: reguła deny paradoksalnie wyłącza maskowanie

Drugi wyciek ma inny mechanizm. Funkcja sprawdzająca, czy użytkownik może aktualizować konfigurację, uznawała za wystarczającą samą obecność reguły manager:update_config lub cluster:update_config. Nie sprawdzała efektu reguły. Jawne deny, dodane po to, aby wzmocnić konto tylko do odczytu, było zatem interpretowane jak posiadanie uprawnienia.

Gdy kontrola uznawała użytkownika za uprawnionego do aktualizacji, dekorator nie maskował sekretów. Żądanie surowej konfiguracji mogło zwrócić cluster.key wprost. Podatne są wersje 4.14.0–4.14.6, wynik to CVSS 4.0: 7,0 (High), a naprawa znajduje się w 4.14.7.

Ten błąd zasługuje na osobny test regresji. Policy engine nie może odpowiadać tylko na pytanie „czy istnieje pasujący wpis?”. Musi oceniać akcję, zasób, efekt allow/deny, priorytet i wynik końcowy. Negatywna reguła jest decyzją odmawiającą, a nie dowodem szerszych praw.

CVE-2026-61800: klucz klastra otwiera zapis plików na workerze

Synchronizacja plików klastra używała safe_join(), aby docelowa ścieżka pozostała pod /var/ossec. To naprawiało ucieczkę poza katalog przez .., ale w gałęzi plików niemergowanych zabrakło drugiej kontroli: czy plik trafia do katalogu zadeklarowanego przez jego cluster_item_key.

W efekcie złośliwy lub przejęty master — albo podmiot dysponujący kluczem klastra i osiągalnością portu — mógł umieścić plik w dowolnym miejscu pod /var/ossec, nie tylko w dozwolonej podprzestrzeni synchronizacji. Ta sama luka dotyczyła usuwania. Ponieważ część plików w tym drzewie jest wykonywana przez procesy root, advisory opisuje drogę do root RCE na workerach.

Podatne są wersje 4.4.0–4.14.6, poprawka jest w 4.14.7, a wynik wynosi CVSS 3.1: 9,1 (Critical). Jest to niepełna naprawa CVE-2026-30893: wcześniejsza kontrola ograniczyła ścieżkę do /var/ossec, lecz nie wymusiła właściwego podkatalogu wewnątrz tej granicy.

Jak składa się łańcuch od roli readonly do roota

W realistycznym scenariuszu konto API z cluster:read pobiera klucz przez CVE-2026-61802. Jeżeli napastnik może połączyć się z portem klastra, sekret umożliwia uwierzytelnienie jako peer. Następnie CVE-2026-61800 pozwala skierować synchronizowany plik do lokalizacji wykonywanej z uprawnieniami root.

Nie jest to pojedyncze żądanie „pre-auth RCE z internetu”. Potrzebne są konto o małych uprawnieniach i sieciowa osiągalność usługi klastra. Segmentacja portu 1516 oraz restrykcyjne role zmniejszają ryzyko, ale nie zastępują poprawki: konto readonly nadal nie powinno znać sekretu, a peer nie powinien wybierać dowolnej ścieżki.

CVE-2026-61783 może dostarczyć ten sam klucz przy szczególnej konstrukcji polityki RBAC. Dlatego analiza ekspozycji musi sprawdzić oba endpointy i oba zestawy ról, a nie tylko domyślne cluster_readonly.

CVE-2026-54083: srcip staje się ścieżką dla procesu root

Skrypt ip-customblock budował nazwę pliku przez dołączenie wartości srcip z alertu do katalogu /ipblock/, ale nie potwierdzał, że wartość jest adresem IP. Sekwencje zmiany katalogu mogły wyprowadzić operację poza zamierzoną bazę. Akcja blokowania tworzyła plik, a odblokowania usuwała wskazaną ścieżkę; Active Response działa z uprawnieniami root.

Wynik to CVSS 3.1: 8,1 (High) i naprawa w 4.14.7. Osiągalność wymaga, aby atakujący mógł dostarczyć dane do logu lub alertu spełniającego regułę uruchamiającą ten konkretny skrypt. Nie każda instalacja korzysta z ip-customblock, dlatego inwentarz aktywnych reakcji jest ważniejszy niż sama obecność pliku na dysku.

CVE-2026-54085: dane alertu stają się argumentami poleceń

Pięć skryptów obsługujących srcip — między innymi dla route, pf, npf, ipfw i Windows netsh — nie używało walidacji formatu obecnej w innych skryptach. disable-account przekazywał natomiast dstuser do narzędzi zarządzania kontami, blokując jedynie literalną nazwę root. Dane pochodzące z alertu mogły w rezultacie wpłynąć na dodatkowe argumenty uprzywilejowanych poleceń.

Podatne są wersje 4.2.0–4.14.6, wynik to 7,1 (High), poprawka — 4.14.7. Źródłem może być na przykład kontrolowany wpis syslog, ale wykorzystanie wymaga dopasowania reguły i uruchomienia Active Response. To nie usprawiedliwia ufania polom alertu: SIEM przetwarza wrogie dane, a reakcja automatyczna podnosi ich wpływ.

CVE-2026-54084: enrollment bez CA pozwala rozbić agenta

Podczas enrollmentu agent dzieli odpowiedź z kluczem na cztery pola. W podatnych wersjach brakujące elementy mogły pozostać wartością NULL, a późniejszy walidator wywoływał na nich strlen(), powodując awarię. Złośliwy manager lub atakujący w pozycji MitM może deterministycznie zakończyć proces agenta.

Problem dotyczy wersji 4.0.0–4.14.6 i ma CVSS 3.1: 5,3 (Medium). Praktycznym warunkiem jest enrollment bez poprawnej weryfikacji managera certyfikatem CA. Aktualizacja usuwa błąd pamięci, ale poprawna walidacja TLS nadal jest potrzebna, aby agent nie ufał przypadkowemu serwerowi.

Plan naprawczy dla SOC i platformy

Zaktualizuj managery i agenty do 4.14.7 lub nowszego wspieranego wydania zgodnie z kolejnością zalecaną przez Wazuh. Przed zmianą zachowaj konfigurację, mapę ról, listę węzłów, stan klastra i niestandardowe Active Response. Po zmianie wykonaj test zdrowia klastra oraz kontrolowane testy negatywne endpointów konfiguracji.

Jeżeli choć jedno konto o małych uprawnieniach mogło odczytać cluster.key, potraktuj sekret jako potencjalnie ujawniony. Ogranicz port klastra, usuń nieautoryzowane konta, zaktualizuj wszystkie węzły, a potem przeprowadź rotację w zaplanowany sposób. Zmiana klucza tylko na części klastra spowoduje utratę komunikacji, więc nie może być impulsywnym pojedynczym poleceniem.

Zidentyfikuj skrypty Active Response faktycznie powiązane z regułami. Do czasu aktualizacji wyłącz te, które przetwarzają niezweryfikowane pola, albo ogranicz źródła danych i akcje. Po naprawie sprawdź zarówno prawidłowe adresy IPv4/IPv6, jak i wartości odrzucane; walidacja nie powinna blokować legalnej telemetrii.

Detekcja i analiza śladów

Przejrzyj wywołania /cluster/local/config i surowych endpointów konfiguracji wykonane przez role readonly. Sam odczyt przed poprawką nie dowodzi dalszego ataku, ale określa konta wymagające analizy. Koreluj je z połączeniami do portu klastra, zmianami mastera, nieznanymi węzłami i synchronizacją plików do nietypowych podkatalogów.

Na workerach porównaj pliki pod /var/ossec z pakietem i zatwierdzonym repozytorium konfiguracji. Zwróć uwagę na czas modyfikacji skryptów uruchamianych przez root, plików konfiguracyjnych i elementów Active Response. Nie usuwaj od razu podejrzanych obiektów; najpierw zbierz metadane i kopię do analizy.

Dla CVE-2026-54083 i 54085 wyszukaj alerty z nietypowym srcip lub dstuser, po których nastąpiła reakcja. Analizuj argumenty wykonanych programów, zmiany reguł firewalla, utworzone pliki i blokady kont. Dla enrollmentu szukaj awarii agenta bezpośrednio po odpowiedzi managera oraz instalacji bez skonfigurowanego CA.

Fakty źródłowe i wnioski Breachroad

Mechanizmy, zakresy wersji, oceny i naprawa 4.14.7 pochodzą z rekordów CNA i oficjalnych advisory repozytorium Wazuh. Złożenie CVE-2026-61802 z CVE-2026-61800 jest opisane również przez producenta jako osiągalny łańcuch przy dostępie do portu klastra. Kolejność rotacji, priorytety telemetrii i plan testów są wnioskami obronnymi Breachroad. Publiczne źródła nie potwierdzają aktywnego wykorzystania w konkretnej organizacji.

Źródła pierwotne

• GHSA-chmg-89pf-2q82 — brak maskowania cluster.key
• GHSA-vjcq-cf36-f5gx — błąd efektu deny w RBAC
• GHSA-3jff-488g-335f — zapis plików na workerze
• GHSA-m4mf-qmhf-8vj6 — path traversal w ip-customblock
• GHSA-mvh4-g699-984j — argument injection w Active Response
• GHSA-ppc7-hj9v-vx39 — awaria enrollmentu agenta

SIEM i XDR muszą traktować własne dane wejściowe jak dane przeciwnika. Na szkoleniach cyberbezpieczeństwa dla zespołów technicznych uczymy bezpiecznej automatyzacji reakcji, zarządzania sekretami i analizy łańcuchów podatności. Testy penetracyjne aplikacji i infrastruktury mogą zweryfikować RBAC, segmentację klastra i control plane w ustalonym zakresie.