Check Point CVE-2026-91843. Root na serwerze zarządzania bez hasła
Nie będzie tu payloadu ani PoC. Check Point i Censys opisali mechanizm na tyle, ile adminowi potrzeba. Interesuje mnie domknięcie wątku z tego miesiąca: MikroTik, Cisco FMC, vCenter, a teraz panel Quantum Security Management. Znowu nie gateway na brzegu, tylko skrzynka, która trzyma polityki i dostęp administratorów.
18 września 2026 temat wszedł szerzej do obiegu po advisory Censys (16 IX) i komunikacie Check Pointa. CVE-2026-91843, CVSS 9.8: nieuwierzytelniony atakujący może przez proces logowania dojść do wykonania kodu jako root na Security Management Server i Log Server (w tym warianty Multi-Domain). Producent nie potwierdza exploitation in the wild. Score i powierzchnia i tak wystarczają, żeby nie czekać na KEV.
Co pęka
Luka to stack overflow w ścieżce logowania, zanim dojdzie do prawdziwego uwierzytelnienia. Censys wskazuje wektor: żądanie logowania z ekstremalnie długą nazwą użytkownika. Skutek według vendora: zdalne wykonanie kodu z uprawnieniami roota.
Warunek praktyczny: ścieżka dotyczy dostępu przez Trusted Clients, czyli ustawienie kontrolujące, kto może gadać ze SmartConsole / serwerem zarządzania. To nie jest „każdy Check Point na świecie od razu”. To jest klasa instalacji, w których management przyjmuje klientów administracyjnych według tej konfiguracji. Jeśli Trusted Clients stoi szeroko albo management wisi bliżej internetu, niż powinien, rachunek się psuje.
Dotknięte linie obejmują m.in. R82.20, R82.10 / R82 / R81.20 poniżej określonych Jumbo Hotfix Take, starsze R81.10 i gałęzie R80 / R81 oznaczone jako end of support. Szczegóły take’ów są w sk1000155; tu nie kopiuję tabeli 1:1, bo Easy Update i tak wygrywa z ręcznym przepisywaniem z bloga.
LivePatch, nie czekanie na ransomware
Check Point wypuścił poprawkę kanałem LivePatch (opis w sk1000155). Kto ma automatyczne aktualizacje według ich wytycznych, powinien już dostać ochronę. Reszta: wgrać update na każdy Security Management, Multi-Domain Management i Log Server, nie tylko na ten „wystawiony na świat”.
Weryfikacja po stronie admina (Expert mode): cplp list i szukanie uzbrojonego wpisu związanego z fwm / CVE-2026-91843. Jeśli nie widzisz łatki, nie zakładaj, że „auto” zadziałało.
Dodatkowo: zawęzić Trusted Clients do znanych wewnętrznych IP / podsieci, nie zostawiać Client Type jako Any. Management nie powinien być publicznym logowaniem z internetu; hardening guide Check Pointa od lat mówi to samo. Restrict Trusted Clients to środek zmniejszający powierzchnię, nie zamiennik łatki.
Censys liczy ok. 3836 hostów na świecie z rolą Security Management / Log Server (tożsamość SIC), nie „3836 potwierdzonych podatnych”. Licznik mówi o skali produktu w skanie, nie o liczbie dziur do exploita.
Publicznego PoC na dzień publikacji Censys (16 IX) nie było. Check Point nie zgłasza aktywnych ataków. To odróżnia ten tekst od vCenter, gdzie CISA zdążyła dopisać ransomware. Okno przed skryptami i tak bywa krótkie przy CVSS 9.8 i root na panelu polityk.
Ten sam morał, czwarty panel
MikroTrick: edge z SSH. FMC: centrum nad firewallami, APT i Qilin. vCenter: hypervisor i szyfrowanie VM. Check Point: serwer, który podpisuje, kto wolno administrować siecią. Atakujący nie musi najpierw szukać stacji z Outlookiem. Wystarczy management plane bez łatki.
Tu jeszcze nie ma flagi ransomware ani klastrów Talos. Jest produkt kupowany po to, żeby obcy nie dostał roota na panelu polityk. Łatka jest tańsza niż czekanie na PoC.
Jeśli trzymasz SMS / Log Server Check Pointa: sk1000155 albo potwierdzenie LivePatch, cplp list, przegląd Trusted Clients, brak wystawiania zarządzania do internetu. Reszta to opsec płaszczyzny administracyjnej, nie magia marki na obudowie.