Krytyczne CVE 2026: dlaczego exploit wyprzedza łatkę

Jeśli z krytycznych podatności 2026 roku miałby wynikać jeden wniosek, brzmi on tak: exploit coraz częściej wyprzedza łatkę. To nie jest wrażenie — to mierzalny trend, który zmienia sposób, w jaki trzeba budować obronę.

Exploitacja wyprzedza ujawnienie

Analizy danych z lat 2025–2026 pokazują, że średni czas do wykorzystania podatności stał się ujemny — luki bywają wykorzystywane w atakach jeszcze zanim producent oficjalnie je ujawni i wyda poprawkę. Widzieliśmy to na własne oczy: zero-daye w Ivanti EPMM były atakowane przed publikacją, a krytyczne błędy w Fortinet FortiClient EMS trafiały do CISA KEV jako aktywnie wykorzystywane.

Konsekwencja jest niewygodna: model „załatamy w najbliższym oknie serwisowym” przestaje wystarczać dla systemów wystawionych do internetu.

Urządzenia brzegowe to front

Wzorzec jest wyraźny. Wśród podatności powiązanych z ransomware i oznaczonych w KEV znaczącą część stanowią urządzenia brzegowe — bramy VPN, firewalle i serwery zarządzania od Citrix, Ivanti czy Fortinet. Powód jest prosty: są publicznie osiągalne i mają uprzywilejowany dostęp do reszty sieci. Jedno przejęcie daje atakującemu punkt zaczepienia i most do wnętrza.

To także najczęstsze drzwi wejściowe ataków ransomware — dlatego szybkie łatanie systemów brzegowych opisujemy jako jeden z filarów obrony przed ransomware.

Niski CVSS nie znaczy bezpiecznie

Rok 2026 przyniósł też dobitną lekcję o priorytetyzacji: 0-day w SharePoint miał w CVSS zaledwie 6.5, a i tak trafił do KEV z twardym terminem — bo był aktywnie wykorzystywany. Z drugiej strony luki „robakowe” jak CVE-2026-33827 w Windows TCP/IP pokazują, że niektóre podatności wymagają trybu awaryjnego niezależnie od reszty harmonogramu.

Jak nadążyć — praktyczny proces

1. Priorytetyzuj po aktywnej eksploatacji, nie po samym CVSS. Wpnij katalog CISA KEV i ocenę EPSS w swój proces — codzienne porównanie z listą tego, co jest realnie atakowane. Rozwijamy to przy priorytetyzacji podatności.
2. Miej pełną inwentaryzację systemów wystawionych do internetu — nie ochronisz tego, o czym nie wiesz.
3. Zbuduj ścieżkę awaryjnego łatania dla luk krytycznych — z góry ustaloną, przećwiczoną, z jasną odpowiedzialnością.
4. Ogranicz ekspozycję. Interfejsy zarządzania, VPN i portale trzymaj za listami dozwolonych adresów, nie w otwartym internecie.
5. Zakładaj kompromitację urządzeń brzegowych, które były wystawione i niezałatane — szukaj IOC, nie tylko łataj.

Trend „exploit przed łatką” nie cofnie się sam. Wygrywają organizacje, które zamieniły łatanie z corocznego projektu w ciągły proces oparty na realnym ryzyku. Jeśli chcesz taki proces ustawić lub sprawdzić swoją ekspozycję, skontaktuj się z nami.

Jak udokumentować decyzję o priorytecie

Dla każdej podatności zapisz cztery fakty: czy zasób jest osiągalny dla atakującego, czy dana wersja jest rzeczywiście podatna, czy istnieje dowód wykorzystania oraz jaki proces biznesowy ucierpi po kompromitacji. CVSS opisuje cechy techniczne, EPSS szacuje prawdopodobieństwo wykorzystania w określonym horyzoncie, a obecność w CISA KEV potwierdza znane wykorzystanie. Żaden z tych sygnałów nie zastępuje inwentaryzacji własnych systemów.

Po wdrożeniu poprawki zweryfikuj wersję lub stan konfiguracji z systemu docelowego, nie tylko status zadania w narzędziu. Gdy łatka jest niemożliwa, zapisz kontrolę kompensacyjną, właściciela i termin jej usunięcia. Retest powinien objąć także publiczną ekspozycję, bo pozostawiony węzeł, appliance zapasowy albo obraz maszyny może ponownie wprowadzić lukę.

Ustal też moment ponownej oceny. Nowy wpis KEV, kod proof-of-concept, zmiana EPSS albo odkrycie publicznego interfejsu może przesunąć zadanie z normalnego okna do trybu awaryjnego. Dashboard powinien pokazywać zarówno niezałatane zasoby, jak i niewiarygodne dane inwentaryzacyjne; brak wersji nie jest stanem bezpiecznym.

Źródła: CISA KEV, FIRST — EPSS, NVD.