zero-day

Zero-day (także 0-day, 0day) to podatność wykorzystywana albo ujawniona, zanim producent udostępnił poprawkę. Google Threat Intelligence Group definiuje ją jako lukę złośliwie wykorzystaną w realnych atakach, zanim łatka (patch) stała się publicznie dostępna ^[2]. NIST opisuje atak zero-day jako atak wykorzystujący wcześniej nieznaną podatność sprzętu, oprogramowania układowego albo oprogramowania ^[1]. Potocznie „zero-day” oznacza też sam exploit na taką lukę.

Jak działa

Nazwa odnosi się do liczby dni, które obrońcy mieli na przygotowanie: w chwili ataku producent albo nie wie o błędzie, albo nie zdążył wydać poprawki. Nie da się więc ochronić systemu zwykłą aktualizacją, bo aktualizacja z poprawką nie istnieje. Obrona musi opierać się na obejściach zaleconych przez producenta, na ograniczeniu dostępu do podatnej usługi i na wykrywaniu śladów ataku.

Cykl życia podatności pokazuje schemat poniżej. Okres zero-day trwa od pierwszego wykorzystania do publikacji poprawki; potem luka staje się błędem n-day, groźnym dla wszystkich, którzy nie zaktualizowali systemu.

RYS. 1Cykl życia podatności

Odmiany

Sekurak zestawia trzy określenia, które opisują, jak dawno znana jest luka i exploit ^[4]. Pojęcie 1-day oznacza błąd załatany, ale w pierwszych dniach po wydaniu poprawki wielu użytkowników jeszcze jej nie wdrożyło; n-day to exploit znany od wielu dni ^[4].

Z punktu widzenia właściciela strony granica jest praktyczna: przed publikacją łatki zostają obejścia i detekcja, po publikacji najważniejsza jest szybkość wdrożenia.

W WordPressie

Strona WordPress składa się z rdzenia, motywu i wtyczek, a każdy z tych elementów może mieć nieznaną jeszcze lukę; zob. podatność we wtyczce. Piotr Konieczny z Niebezpiecznika pisał w 2010 roku, że serwis oparty na popularnym systemie CMS, takim jak WordPress, jest podatny na atak od chwili znalezienia w nim pierwszego błędu ^[5]. Wnioskiem z tego tekstu jest nacisk na ograniczanie skutków włamania, a nie na obietnicę, że do niego nie dojdzie ^[5].

Przypadek z września 2026 roku pokazuje, jak krótka jest droga od poprawki do ataku. WordPress wydał 22 września wersję 7.1.2 z poprawką luki CVE-2026-87902, którą nieuwierzytelniony atakujący mógł w pewnych warunkach wykorzystać do zdalnego wykonania kodu (RCE) ^[7]. Autor zgłosił lukę w trybie odpowiedzialnego ujawnienia ^[7], a doniesienia o atakach pojawiły się dopiero po wydaniu poprawki: dwa dni później Help Net Security informował o aktywnym wykorzystywaniu luki ^[8]. Był to więc przypadek 1-day, a nie zero-day. Strony z włączoną automatyczną aktualizacją otrzymały poprawkę bez udziału właściciela ^[7].

Zagrożenia i skutki

Luki zero-day są trudne do zatrzymania, bo w chwili ataku brakuje poprawki. GTIG naliczyła 90 podatności zero-day wykorzystanych w 2025 roku, wobec 78 w 2024 roku i rekordowych 100 w 2023 roku ^[2]. 43 z 90 luk z 2025 roku, czyli 48 procent, dotyczyły technologii dla przedsiębiorstw ^[2]. Połowę z nich stanowiły produkty bezpieczeństwa i sieciowe, a 14 luk dotyczyło urządzeń brzegowych ^[2]. GTIG zauważa, że na większości takich urządzeń nie działa oprogramowanie EDR (Endpoint Detection and Response), co tworzy martwe pola dla obrońców ^[2].

Według GTIG urządzenia brzegowe są częstym celem grup sponsorowanych przez państwo (APT), które chcą utrzymać trwały dostęp do strategicznych sieci ^[2]. Grupom powiązanym z Chinami raport przypisuje co najmniej 10 luk zero-day z 2025 roku, a grupom motywowanym finansowo, w tym operatorom ransomware, 9 ^[2]. Po raz pierwszy więcej luk zero-day przypisano komercyjnym dostawcom narzędzi inwigilacji niż grupom szpiegowskim sponsorowanym przez państwa ^[2].

Jak się bronić

GTIG w raporcie za 2025 rok zaleca obrońcom trzy grupy działań ^[2]. Pierwsza to ograniczanie powierzchni ataku, w tym niewystawianie portów sieciowych do internetu, jeśli nie jest to konieczne. Druga to wykrywanie nietypowego zachowania systemów, na przykład przez pułapki typu canary token. Trzecia to przygotowanie reakcji: wykaz komponentów SBOM, który pozwala szybko ustalić, gdzie działa podatna biblioteka, oraz tymczasowe wyłączenie usługi albo zablokowanie portu, gdy poprawki jeszcze nie ma ^[2]. Dla strony WordPress przekłada się to na następujące kroki.

• Stosować obejścia wskazane przez producenta od razu po komunikacie, a łatkę wdrożyć w dniu publikacji.
• Utrzymywać WAF z aktualnymi regułami; reguła blokująca znany wzorzec ataku działa jak wirtualne patchowanie (virtual patching).
• Ograniczać powierzchnię ataku: usuwać nieużywane wtyczki i zamykać publiczny dostęp do paneli.
• Prowadzić monitorowanie integralności plików, by wykryć skutki ataku, którego nie dało się zatrzymać.
• Mieć sprawdzoną kopię zapasową (backup) i plan reagowania na incydenty.

Historia i przykłady

W grudniu 2022 roku Sekurak opisał lukę CVE-2022-42475 w FortiOS SSL-VPN, przepełnienie bufora na stercie, które pozwalało zdalnemu, nieuwierzytelnionemu atakującemu wykonać dowolny kod ^[6]. Fortinet w komunikacie przyznał, że wie o przypadku wykorzystania luki w realnym ataku ^[6].

15 maja 2026 roku CERT Polska poinformował o podatności typu 0-day w serwerach Microsoft Exchange 2016, 2019 i Subscription Edition, oznaczonej CVE-2026-42897 ^[3]. W chwili publikacji komunikatu aktualizacja nie była dostępna, a Microsoft zalecał tymczasowe środki zaradcze ^[3]. Na serwerach z usługą Exchange Emergency Mitigation Service środek zaradczy był wdrażany automatycznie ^[3].