12 września holenderski Nationaal Cyber Security Centrum opublikował alert dotyczący dwóch krytycznych podatności w produktach VPN firmy Check Point. Sytuacja jest o tyle nietypowa, że nikt nie odnotował jeszcze ani jednego ataku, nie krąży też publiczny kod exploita. NCSC napisał wprost, że ocenia prawdopodobieństwo wykorzystania luk oraz ich potencjalne skutki jako wysokie i spodziewa się prób ataku w najbliższym czasie. To ostrzeżenie wyprzedzające — coś, co krajowe zespoły reagowania wydają rzadko i tylko wtedy, gdy wzorzec jest aż nadto czytelny.
Na czym polegają luki
Obie dotyczą obsługi certyfikatów przy zestawianiu połączenia VPN i obie mają ocenę 9.8 w skali CVSS. CVE-2026-85102 to nieprawidłowa walidacja danych certyfikatu podczas negocjacji tunelu — zdalny napastnik może dzięki niej wykonać dowolny kod na bramie bezpieczeństwa. CVE-2026-85103 to przepełnienie sterty w dekoderze ASN.1, który parsuje certyfikaty; ta prowadzi do wykonania kodu zarówno na bramie, jak i na serwerze zarządzania.
Kluczowe jest słowo „negocjacja”. Problem występuje na etapie przed uwierzytelnieniem, czyli zanim ktokolwiek poda login i hasło. Napastnik nie potrzebuje konta, nie potrzebuje wykradzionych poświadczeń, nie musi omijać dwuskładnikowego logowania. Wystarczy, że dotrze do portu, na którym urządzenie nasłuchuje — a brama VPN z definicji jest wystawiona do internetu, bo taka jest jej rola.
Check Point wydał poprawki 9 września (biuletyny sk1000117 i sk1000118). Podatne są wersje R81.20, R82, R82.10, R81.10.x i R82.00.x, a także wycofane już ze wsparcia R80 do R80.40, R81 oraz R81.10. Wersja R82.20 nie jest podatna.
Dlaczego akurat bramy VPN
Urządzenia brzegowe — bramy VPN, firewalle, koncentratory dostępu zdalnego — stały się w ostatnich latach ulubioną furtką grup ransomware. Powód jest prozaiczny. Taki sprzęt stoi na styku sieci firmowej z internetem, ma z definicji szerokie uprawnienia, rzadko bywa objęty monitoringiem EDR i równie rzadko jest łatany od ręki, bo aktualizacja oznacza przerwę w pracy dla wszystkich zdalnych pracowników. Przejęcie bramy daje napastnikowi pozycję, z której widzi ruch wewnętrzny i może swobodnie poruszać się po sieci.
Historia ostatnich miesięcy to potwierdza: Fortinet, Ivanti Sentry, SonicWall SMA 1000, Cisco SD-WAN, Citrix NetScaler, Palo Alto GlobalProtect. Za każdym razem schemat był podobny — publikacja poprawki, kilka dni ciszy, potem masowe skanowanie internetu i fala włamań do organizacji, które nie zdążyły zaktualizować. NCSC najwyraźniej uznał, że nie ma sensu czekać na powtórkę i ostrzegł od razu po wydaniu łatki.
Co zrobić
Priorytetem jest oczywiście aktualizacja. Obie luki naprawia LivePatch Take 24 dla R81.20, R82 i R82.10, a poprawki znalazły się też w pakietach Jumbo Hotfix Accumulator — Take 166 dla R81.20, Take 126 dla R82 i Take 44 dla R82.10 — oraz w buildach Spark R82.00.10 (2325) i R81.10.17 (4968).
Administratorzy korzystający z Check Point Live Patch powinni być chronieni automatycznie od 9 września, i to bez restartu urządzenia. Warto to jednak zweryfikować, a nie założyć: mechanizm nie działa dla wersji innych niż R82.10, R82 i R81.20 i nie obsługuje wszystkich konfiguracji.
Jeśli natychmiastowa aktualizacja nie wchodzi w grę, NCSC zaleca ograniczenie reguł VPN typu site-to-site do konkretnych, zaufanych adresów IP. To nie usuwa podatności, ale znacząco zawęża grono tych, którzy w ogóle mogą ją wywołać.
Osobny problem mają organizacje na wersjach po końcu wsparcia — R80 do R80.40, R81 i R81.10. Dla nich jedynym rozwiązaniem jest migracja na wspieraną gałąź, a im dłużej to trwa, tym większe ryzyko. Warto też przejrzeć logi bramy pod kątem nietypowych prób zestawienia tunelu i zweryfikować, czy urządzenie w ogóle musi być dostępne z całego świata.
Podsumowanie
Alert NCSC to przypadek, w którym okno na spokojne działanie jest jeszcze otwarte — łatka istnieje, exploita nie ma. Doświadczenie z ostatnich kilkunastu miesięcy pokazuje jednak, że ten stan rzeczy przy podatnościach klasy pre-auth RCE w sprzęcie brzegowym trwa zwykle dni, nie tygodnie. Dla administratora oznacza to prostą kalkulację: zaplanowane okno serwisowe teraz albo nieplanowane później, w znacznie gorszych okolicznościach.