CVE-2026-41089: krytyczna luka Netlogon

CVE-2026-41089 to krytyczna podatność usługi Windows Netlogon na kontrolerach domeny. Nieuwierzytelniony napastnik może wysłać specjalnie przygotowane pakiety przez sieć i doprowadzić do wykonania kodu z uprawnieniami SYSTEM. Luka ma wynik CVSS 9.8, a instytucje reagowania na incydenty potwierdziły jej aktywne wykorzystanie.

To zestaw faktów, który uzasadnia tryb awaryjny dla zespołów utrzymujących Active Directory. Nie uzasadnia natomiast nazwy „Zerologon 2”, przypisywania ataków konkretnej grupie ani łączenia ich z ransomware — dostępne komunikaty nie potwierdzają takich tez.

Na czym polega CVE-2026-41089

Według CERT-EU problem jest przepełnieniem bufora na stosie w Windows Netlogon. Atak nie wymaga wcześniejszego konta ani działania użytkownika. Jego celem musi być serwer Windows działający jako kontroler domeny; odpowiednio przygotowany ruch sieciowy może spowodować nieprawidłową obsługę danych przez usługę i wykonanie kodu jako SYSTEM.

To najwyższy lokalny poziom uprawnień w Windows. Na kontrolerze domeny oznacza dostęp do systemu, który uczestniczy w uwierzytelnianiu użytkowników i komputerów. Nie oznacza to, że każdy podatny kontroler został przejęty, ale potencjalny wpływ skutecznego ataku jest bardzo duży.

Microsoft Security Response Center opublikował poprawki, a Centre for Cybersecurity Belgium zaktualizował komunikat, wskazując aktywną eksploatację. Priorytetu nie należy więc wyznaczać wyłącznie na podstawie wyniku CVSS — mamy również informację, że luka jest realnie używana.

Które systemy są objęte

Zakres obejmuje wspierane i rozszerzenie wspierane wersje Windows Server używane jako kontrolery domeny:

• Windows Server 2012 i 2012 R2;
• Windows Server 2016;
• Windows Server 2019;
• Windows Server 2022, w tym gałąź 23H2;
• Windows Server 2025.

CERT-EU publikuje w advisory konkretne progi kompilacji dla poszczególnych wersji. Najbezpieczniej sprawdzać właściwy pakiet i stan instalacji bezpośrednio w tabeli Microsoft Update Guide, ponieważ numer wymaganej kompilacji zależy od gałęzi systemu.

Kluczowy warunek to rola kontrolera domeny. Nie należy jednak ograniczać inwentaryzacji do dwóch najbardziej oczywistych serwerów w centrali. Trzeba uwzględnić kontrolery w oddziałach, środowiska odtwarzania awaryjnego, starsze domeny, laboratoria połączone z siecią oraz serwery pozostawione na wydłużonym wsparciu.

Dlaczego kontroler domeny zmienia priorytet

Kontroler domeny jest jednym z najcenniejszych systemów w organizacji. Przechowuje i przetwarza informacje potrzebne do uwierzytelniania, obsługuje relacje zaufania i ma wpływ na działanie wielu usług. Wykonanie kodu jako SYSTEM na takim hoście nie jest zwykłą kompromitacją pojedynczej stacji.

Dlatego aktualizacja powinna wyprzedzić standardowe okno dla mniej istotnych serwerów. Jednocześnie trzeba zachować kontrolowany proces: przetestować pakiet na reprezentatywnym kontrolerze, sprawdzić replikację i kondycję domeny, a następnie wdrażać poprawkę etapami tak, aby nie aktualizować wszystkich kontrolerów jednocześnie. Więcej o warstwach ochrony takiego środowiska opisujemy w poradniku o bezpieczeństwie Active Directory.

Plan działania dla administratora

1. Zrób pełną listę kontrolerów domeny wraz z wersją systemu, numerem kompilacji, lokalizacją i właścicielem technicznym.
2. Pobierz właściwą aktualizację Microsoftu dla każdej wersji i przetestuj ją na kontrolerze, którego czasowe wyłączenie nie zatrzyma uwierzytelniania.
3. Wdróż poprawki w trybie pilnym, zachowując dostępność co najmniej jednego zdrowego kontrolera dla każdej domeny i lokalizacji.
4. Po restarcie zweryfikuj stan, w tym wersję systemu, usługi Netlogon, replikację Active Directory, DNS i zdarzenia systemowe.
5. Ogranicz drogi sieciowe do kontrolerów. Nie powinny być osiągalne z internetu ani z dowolnego segmentu użytkowników. Segmentacja zmniejsza ryzyko, ale nie zastępuje poprawki.
6. Udokumentuj wynik, aby lista „wdrożono” oznaczała potwierdzony poziom kompilacji, a nie tylko wysłane zadanie aktualizacyjne.

Takie podejście jest elementem dojrzałego zarządzania podatnościami: najpierw ustalamy ekspozycję i znaczenie zasobu, potem łatamy, a na końcu mierzymy faktyczny rezultat.

Aktualizacja nie zamyka analizy incydentu

Jeżeli kontroler był dostępny z niezaufanej sieci albo pozostawał bez poprawki w okresie aktywnej eksploatacji, samo zainstalowanie pakietu nie odpowiada na pytanie, czy ktoś wykorzystał lukę wcześniej. Należy zachować i przejrzeć logi z kontrolera, zapory, EDR oraz systemów uwierzytelniania.

Szukaj anomalii czasowo skorelowanych z ruchem do usług kontrolera: nieznanych procesów, nowych usług i zadań, nietypowych zmian kont uprzywilejowanych, wyłączenia zabezpieczeń lub nieoczekiwanych połączeń wychodzących. Pojedynczy sygnał nie jest dowodem wykorzystania CVE, ale może uzasadniać uruchomienie planu reagowania na incydent.

Najważniejszy wniosek

CVE-2026-41089 łączy trzy cechy wymagające szybkiej reakcji: atak bez uwierzytelnienia, kod jako SYSTEM na kontrolerze domeny i potwierdzoną aktywną eksploatację. Zaktualizuj wszystkie kontrolery od Windows Server 2012/2012 R2 do 2025, sprawdź replikację i wersje po restarcie, a w środowiskach narażonych przeprowadź również analizę śladów. Bez marketingowej nazwy i bez spekulacji — same potwierdzone fakty są wystarczająco poważne.

---

Źródła: Microsoft MSRC — CVE-2026-41089, Centre for Cybersecurity Belgium, CERT-EU Security Advisory 2026-007.