Ing. Calogero Bono
9 listopada 2026 roku Agencja Cyberbezpieczeństwa Narodowego opublikowała alert dotyczący open source'owego SIEM-u Wazuh. Dostępne są Proof of Concept dla 8 podatności, z których 5 ma wysoką wagę, a dotyczą one Wazuh i jego Dashboard Plugins. Producent już załatał błędy, ale publiczne exploity demonstracyjne obniżają próg dla tych, którzy chcą je wykorzystać. Jeśli używasz Wazuh do kontroli bezpieczeństwa swojej infrastruktury, sprawdź zainstalowaną wersję.
Kilka pojęć, zanim przejdziemy do faktów. SIEM to system, który zbiera i analizuje logi, aby wykryć ataki. XDR rozszerza kontrolę na kilka warstw, od urządzeń po sieć. PoC (Proof of Concept) to kod demonstracyjny, który dowodzi, że podatność można wykorzystać. CVSS to punktacja od 0 do 10, która mierzy wagę podatności. SSRF to atak, który zmusza serwer do wysyłania żądań na adres wybrany przez napastnika.
Co ACN zgłosiła w sprawie Wazuh?
W alercie AL02/261109/CSIRT-ITA opisano 8 podatności, dla których opublikowano PoC. Wymienione typy to wykonanie dowolnego kodu, obejście uwierzytelniania, obejście zabezpieczeń, ujawnienie informacji, denial of service oraz spoofing.
W tabeli agencji wszystkie błędy mają obecny PoC, natomiast nie ma żadnej informacji o aktywnym wykorzystywaniu. Alert ma wersję 1.0.
Które wersje Wazuh są podatne?
Według ACN podatne są wersje Wazuh wcześniejsze niż 4.14.9 oraz Wazuh Dashboard Plugins od 4.9.0 do 4.14.9 wyłącznie. Zalecane zabezpieczenie to szybka aktualizacja do najnowszej dostępnej wersji.
Producent, jak podaje agencja, już naprawił błędy. Ryzyko dotyczy więc przede wszystkim tych, którzy jeszcze nie zastosowali aktualizacji.
Jakie są najpoważniejsze podatności?
Na czele jest CVE-2026-112340 z wynikiem CVSS v4.0 równym 8.8. Dotyczy endpointu /api/request wtyczek Dashboard. Uwierzytelniony użytkownik mógłby nadpisać token Bearer i działać jako inna tożsamość w Manager API.
Dalej są CVE-2026-112339 (8.2), wynikająca z braku weryfikacji nazwy hosta TLS w module fluent-forward, oraz CVE-2026-112338 (8.2), czyli SSRF w module GitHub. W pierwszym przypadku napastnik w pozycji on-path mógłby podszyć się pod kolektor Fluentd i odczytać telemetrię. W drugim Manager mógłby wysłać token GitHub na host kontrolowany przez napastnika.
Pięć wysokich podatności dopełniają CVE-2026-112341 i CVE-2026-112336, obie z wynikiem 7.1.
Co grozi systemom w przypadku pozostałych podatności?
CVE-2026-112341 to SQL Injection. Użytkownik z uprawnieniem agent – read dla przynajmniej jednego agenta mógłby wykonać dowolne zapytania i odczytać dane bazy Managera, w tym internal_key agentów. CVE-2026-112336 to natomiast wyciek pamięci w dekoderze JSON. Zdarzenia z powtarzającymi się statycznymi polami, wysłane przez zarejestrowanego agenta, mogłyby spowodować zatrzymanie wazuh-analysisd i przerwanie generowania alertów.
Pozostałe trzy mają wyniki od 6.3 do 6.9.
- CVE-2026-112334, zapis poza granicami bufora w wazuh-execd, z zatrzymaniem Active Response.
- CVE-2026-112335, przepełnienie bufora na stosie w logcollectorze, z możliwym wykonaniem kodu w określonych konfiguracjach.
- CVE-2026-112337, SSRF w module Azure, z zagrożonym tokenem Microsoft Graph.
Ograniczenia, o których warto wiedzieć
Alert nie wskazuje na aktywne wykorzystywanie, a kolumna dotycząca tego pozostaje pusta. Nie wiemy, ile polskich systemów jest narażonych ani od kiedy PoC krążą w sieci. Wiele ataków wymaga konkretnych warunków, takich jak uwierzytelniony użytkownik, kontrola nad plikiem logów albo uprzywilejowana pozycja w sieci. Niektóre identyfikatory CVE mogą zostać zaktualizowane w oficjalnych bazach danych.
Co się zmienia dla osób pracujących w cyfrowym świecie
Jeśli zarządzasz Wazuh, od razu sprawdź wersję Managera i Dashboard Plugins. Jeśli usługa działa na serwerze w hostingu, ustal, kto odpowiada za aktualizacje, bo właśnie do tego służy zarządzanie serwerami z aktualizacjami bezpieczeństwa. Ryzyko dotyczy także powiązanych tokenów, takich jak tokeny GitHub i Azure, które trzeba traktować jak dane uwierzytelniające wymagające ochrony. To nie pierwsze ostatnio zgłoszenie dotyczące narzędzi technicznych, o czym świadczy przypadek Apache OFBiz.
Nasza opinia
Zaskakuje, że celem jest narzędzie stworzone do obrony. SIEM widzi logi, dane logowania i telemetrię całej infrastruktury, więc jego podatność waży więcej niż podatność zwykłej aplikacji. Producent naprawił błędy, a ACN ostrzegła wyraźnie, ale open source nie zwalnia z obowiązku aktualizacji. Kto wdraża takie rozwiązanie w firmie, musi uwzględnić utrzymanie, na co zwraca uwagę przewodnik o open source w firmie.
Najczęstsze pytania
Czy Wazuh jest atakowany aktywnie?
Alert ACN tego nie wskazuje. Kolumna dotycząca wykorzystania ma myślnik przy każdym CVE, natomiast PoC są dostępne.
Jaką wersję Wazuh powinienem zainstalować?
Co najmniej 4.14.9. Podatne są wcześniejsze wersje Wazuh oraz Dashboard Plugins od 4.9.0 do 4.14.9 wyłącznie.
Ile jest podatności i jak poważne są?
Jest ich 8, z czego 5 ma wysoką wagę. Najwyższy wynik CVSS v4.0 to 8.8, a najniższy 6.3.
Czy do wykorzystania tych podatności trzeba być uwierzytelnionym?
Zależy od podatności. Niektóre wymagają uwierzytelnionego użytkownika albo zarejestrowanego agenta, inne napastnika w uprzywilejowanej pozycji sieciowej lub z dostępem do monitorowanych plików.
Co grozi tokenom GitHub i Azure?
Dwie podatności SSRF mogłyby sprawić, że Manager wyśle tokeny na hosty kontrolowane przez napastnika. Według ACN pozwoliłoby to uzyskać dostęp do repozytoriów GitHub lub zasobów Microsoft Graph powiązanych z systemem.
Na co zwrócić uwagę po aktualizacji Wazuh
Aktualizacja zamyka znane podatności, ale publiczne PoC pozostają dostępne i mogą zostać zaadaptowane. W najbliższych tygodniach warto sprawdzić, co wydarzyło się w międzyczasie.
- Sprawdź w logach Managera nietypowe żądania do zewnętrznych hostów lub nieoczekiwane restarty wazuh-analysisd.
- Zobacz, czy ACN zaktualizuje alert o informacje dotyczące aktywnego wykorzystania.
- Rozważ wymianę tokenów GitHub i Azure powiązanych z modułami Wazuh, jeśli systemy pozostawały nieaktualne.
