Rekordowy Patch Tuesday: 570 luk i 3 zero-daye

Lipcowy Patch Tuesday 2026 przeszedł do historii jako największy w dziejach Microsoftu: 570 załatanych podatności, w tym trzy zero-daye — dwa aktywnie wykorzystywane w atakach i jeden ujawniony publicznie przed wydaniem poprawki. Dla porównania: typowy miesiąc to od stu do dwustu błędów. Lipiec był kilkukrotnością tej normy.

Zanim przejdziemy do wniosków, jedno wyjaśnienie liczbowe, bo w mediach krążyły dwie różne wartości. Część źródeł podawała 622 CVE — ta szersza liczba obejmuje również poprawki dla przeglądarki Edge opartej na Chromium, które wychodzą w osobnym cyklu, powiązanym z wydaniami Google. Liczba odnosząca się do samego Patch Tuesday i produktów Microsoftu to 570. Poniżej trzymamy się tej wartości.

Ten wpis nie jest listą CVE — takie listy publikuje producent i są aktualne przez tydzień. Jest odpowiedzią na pytanie, które faktycznie stoi przed zespołami: jak podejść do 570 poprawek, gdy okno serwisowe masz na 40 z nich.

Dlaczego liczba sama w sobie jest myląca

Nagłówek „rekord wszech czasów” wywołuje odruch paniki, a panika jest złym doradcą przy łataniu. Trzy rzeczy warto od razu uporządkować.

Wzrost liczby CVE nie oznacza wprost wzrostu ryzyka. Na rosnące statystyki wpływa wiele czynników niezwiązanych z jakością kodu: szersze programy bug bounty, więcej narzędzi do automatycznego wyszukiwania błędów (w tym opartych na modelach AI), rozrost portfolio produktów oraz zmiany w tym, co producent w ogóle klasyfikuje jako osobne CVE. Więcej znalezionych błędów to również sygnał, że więcej ich się szuka.

Rozkład istotności jest silnie skośny. Z 570 podatności zdecydowana większość to błędy wymagające lokalnego dostępu, interakcji użytkownika albo dające ograniczony skutek. W lipcowej puli dominowały podniesienie uprawnień (ok. 41%), zdalne wykonanie kodu (ok. 27%) i ujawnienie informacji (ok. 18%). Realnie pilnych pozycji jest kilkanaście, nie pięćset.

Ryzyko koncentruje się w kilku pozycjach. Trzy zero-daye ważą więcej niż pozostałe 567 razem wzięte — bo dla nich istnieje potwierdzone wykorzystanie lub publiczny kod, czyli warunek, przy którym prawdopodobieństwo ataku przestaje być teoretyczne.

Trzy zero-daye — dlaczego to one wyznaczają priorytet

Rozróżnienie między typami zero-dayów ma konsekwencje operacyjne, więc warto je nazwać precyzyjnie:

Typ	Co oznacza	Priorytet
Aktywnie wykorzystywany (2 pozycje)	Istnieją potwierdzone ataki na realne cele	Najwyższy — łataj natychmiast
Ujawniony publicznie (1 pozycja)	Szczegóły techniczne są jawne przed łatką	Wysoki — exploit powstaje zwykle w dni
Pozostałe	Brak dowodów wykorzystania	Standardowy cykl

Aktywna eksploatacja jest najsilniejszym sygnałem, jaki może otrzymać obrońca. Oznacza, że nie rozważamy już scenariusza hipotetycznego — ktoś to robi, a skanowanie internetu w poszukiwaniu podatnych systemów jest zautomatyzowane i tanie. Dlatego obecność w katalogu CISA KEV powinna przebijać wynik CVSS w Twoim procesie decyzyjnym. Rozwijamy tę zasadę w tekście o priorytetyzacji krytycznych podatności.

Publiczne ujawnienie przed łatką jest kategorią pośrednią, ale niedocenianą. Gdy szczegóły techniczne są jawne, droga od analizy do działającego exploita bywa bardzo krótka — pisaliśmy o tym przy luce w Adobe ColdFusion, gdzie ataki ruszyły w godziny po publikacji analizy.

Triage: jak podejść do 570 poprawek

Poniżej praktyczna kolejność, którą stosujemy przy dużych paczkach aktualizacji. Zasada nadrzędna: nie łatamy „wszystkiego”, tylko właściwe rzeczy we właściwej kolejności.

Krok 1: Zacznij od tego, co widać z internetu

Systemy osiągalne publicznie mają najkrótszy czas od ujawnienia luki do próby ataku, bo skanery przeczesują internet nieprzerwanie. Serwery pocztowe, portale, bramy VPN, serwery aplikacyjne, wszystko z publicznym adresem — to pierwsza fala, niezależnie od tego, jak wygląda reszta listy.

Warunkiem wstępnym jest wiedza o tym, co w ogóle jest widoczne. Jeśli nie masz aktualnej mapy ekspozycji, zacznij od niej — to rola zarządzania zewnętrzną powierzchnią ataku (EASM). Zaskakująco często największym znaleziskiem nie jest niezałatany serwer, lecz serwer, o którym nikt nie wiedział.

Krok 2: Nałóż filtr aktywnej eksploatacji

Z pełnej listy wyodrębnij pozycje obecne w katalogu CISA KEV oraz te, które producent oznaczył jako wykorzystywane lub publicznie ujawnione. To zwykle redukuje pięćset pozycji do kilkunastu. Ta lista jest Twoim priorytetem numer jeden po systemach brzegowych.

Krok 3: Zestaw podatności z rzeczywistą architekturą

Tu odpada większość pozycji — i tu popełnia się najwięcej błędów. Zadaj trzy pytania do każdej krytycznej luki:

Czy w ogóle mamy ten komponent? Rola serwerowa, której nie zainstalowałeś, nie jest Twoim problemem.
Czy warunki wykorzystania są u nas spełnione? Wiele CVE wymaga konkretnej konfiguracji — włączonej funkcji, określonego trybu uwierzytelniania, dostępu lokalnego.
Co osiągnie napastnik, jeśli to wykorzysta? Podniesienie uprawnień na izolowanej stacji testowej to inna sprawa niż to samo na kontrolerze domeny.

Ostatni punkt zasługuje na rozwinięcie. Podatności typu elevation of privilege — najliczniejsza kategoria w lipcowej puli — bywają lekceważone („napastnik musi już być w systemie”). To błąd. W typowym łańcuchu ataku napastnik już jest w systemie: wszedł przez phishing lub przejęte poświadczenia, a brakuje mu wyłącznie uprawnień, by przejść dalej. Luka podnosząca uprawnienia jest dokładnie tym brakującym elementem. Świetnie ilustruje to Certighost w AD CS, gdzie zwykłe konto domenowe prowadziło do przejęcia całej domeny.

Krok 4: Łataj falami, nie jednym uderzeniem

Sprawdzona kolejność:

Fala 0 (do 48 godzin): systemy wystawione do internetu z aktywnie wykorzystywanymi lukami.
Fala 1 (do 7 dni): kontrolery domeny, serwery tożsamości, systemy zarządzania (a więc wszystko, czego kompromitacja daje efekt masowy).
Fala 2 (do 14 dni): pozostałe serwery i stacje robocze — najlepiej automatycznie, przez system dystrybucji aktualizacji.
Fala 3 (kolejny cykl): systemy o niskim ryzyku, środowiska testowe, sprzęt wymagający długiego okna serwisowego.

Uwaga o kolejności testowania: przy pakiecie tej wielkości rośnie ryzyko regresji. Nie oznacza to jednak, że można odkładać falę 0 „do czasu przetestowania”. Rozsądny kompromis to równoległość: fala 0 idzie na produkcję po skróconym teście dymnym, a szeroka reszta przechodzi normalny cykl walidacji.

Krok 5: Zweryfikuj, że poprawka faktycznie działa

Najczęstszy błąd w tym procesie to uznanie zadania za zamknięte w momencie wypchnięcia aktualizacji. Sprawdź trzy rzeczy: czy poprawka jest zainstalowana, czy system został zrestartowany (wiele poprawek jądra i bibliotek działa dopiero po restarcie) i czy zgadza się numer wersji na hoście. Raportuj stan z centralnego systemu zarządzania, nie z ankiety wśród administratorów. Ten cykl — inwentaryzacja, wdrożenie, potwierdzenie — jest sercem procesu zarządzania podatnościami.

Czego rekordowa liczba uczy o samym procesie

Jeśli 570 poprawek wywołuje w organizacji kryzys, problemem nie jest lipiec — problemem jest proces, który działa tylko przy małych paczkach.

Automatyzacja przestaje być opcjonalna. Ręczne przeglądanie kilkuset CVE co miesiąc jest niewykonalne. Potrzebujesz narzędzia, które automatycznie zestawi listę podatności z inwentarzem Twoich systemów i pokaże wyłącznie przecięcie tych zbiorów. Bez inwentarza żadne narzędzie nie pomoże — dlatego to inwentaryzacja, a nie skaner, jest fundamentem.

Okno serwisowe raz na kwartał to za rzadko. Przy tej dynamice organizacja potrzebuje ścieżki szybkiej (dni) dla poprawek krytycznych i ścieżki standardowej (tygodnie) dla reszty. Jeden sztywny cykl kwartalny gwarantuje, że przez większość roku pozostajesz podatny na rzeczy, o których wiadomo publicznie.

Mierz czas, nie odsetek. Metryka „98% systemów załatanych” niewiele mówi, jeśli w brakujących 2% siedzi serwer wystawiony do internetu. Znacznie użyteczniejsza jest mediana czasu od wydania poprawki do jej wdrożenia dla systemów krytycznych — bo to właśnie ten czas napastnik wykorzystuje.

Uwzględnij to, czego system aktualizacji nie obejmuje. Największe zaległości zwykle nie są na serwerach Windows, tylko na urządzeniach brzegowych, appliance’ach i systemach, których „nie można restartować”. Pisaliśmy o tym przy aktywnie wykorzystywanych lukach we FortiSandbox — tam poprawki były dostępne od kwietnia, a ataki trwały w lipcu.

Pięć błędów, które kosztują najwięcej

Przy dużych paczkach aktualizacji te same pomyłki powtarzają się w większości organizacji. Warto je nazwać, bo każda z nich ma prostą kontrę.

Łatanie po numerze CVSS zamiast po ekspozycji. Sortowanie listy malejąco po punktacji wygląda racjonalnie, ale prowadzi do sytuacji, w której załatasz lukę 9.8 na wewnętrznym serwerze testowym, zanim zajmiesz się luką 7.5 na bramie wystawionej do internetu. Kolejność powinna wynikać z kombinacji ekspozycja × dowody wykorzystania × krytyczność systemu, a nie z jednej liczby.

Pomijanie restartów. Poprawka zainstalowana, ale niezaaplikowana, jest w raportach widoczna jako sukces, a w rzeczywistości nie chroni. Przy komponentach jądra i bibliotekach systemowych restart jest częścią wdrożenia, nie opcjonalnym dodatkiem. Raportuj stan po restarcie, nie po instalacji.

Zapominanie o systemach poza cyklem. Największe zaległości rzadko dotyczą stacji roboczych objętych automatyczną dystrybucją. Siedzą w urządzeniach brzegowych, maszynach wirtualnych wyłączonych w momencie wdrożenia, systemach w izolowanych segmentach i sprzęcie „którego nie wolno restartować”. Każda z tych kategorii potrzebuje osobnej ścieżki, inaczej wypadnie z procesu na stałe.

Traktowanie testów jako wymówki. Testowanie przed wdrożeniem jest właściwą praktyką, ale przy podatnościach aktywnie wykorzystywanych staje się wymówką, jeśli oznacza opóźnienie liczone w tygodniach. Rozwiązaniem jest podział: skrócona ścieżka dla fali 0, pełny cykl walidacji dla reszty.

Brak zamknięcia pętli. Wdrożenie bez weryfikacji to nie proces, tylko intencja. Za każdym razem, gdy raport mówi „100% zgodności”, warto wyrywkowo sprawdzić kilka hostów niezależnym narzędziem. Rozbieżność między raportem a stanem faktycznym jest regułą, nie wyjątkiem.

Perspektywa mniejszej organizacji

Jeśli nie masz zespołu bezpieczeństwa, powyższy proces brzmi jak opis z innej ligi. W praktyce sprowadza się do czterech decyzji, które można podjąć raz i utrzymywać:

Włącz automatyczne aktualizacje na stacjach roboczych i wszędzie, gdzie ryzyko regresji jest akceptowalne. Dla większości małych firm ryzyko niezałatanego systemu jest wyraźnie większe niż ryzyko nieudanej aktualizacji.
Zrób listę tego, co widać z internetu, i pilnuj tych systemów priorytetowo. Jeśli to tylko strona WWW i poczta w chmurze — Twoja powierzchnia ataku jest mała i łatwa do utrzymania.
Śledź jedno źródło o aktywnej eksploatacji (np. katalog CISA KEV) zamiast czytać wszystkie biuletyny. Interesuje Cię kilkanaście pozycji rocznie, nie kilka tysięcy.
Zaplanuj restarty. Zainstalowana, ale nieaktywna poprawka to najczęstsza cicha luka w małych środowiskach.

Szerszy zestaw priorytetów dla mniejszych organizacji opisujemy w tekście o cyberbezpieczeństwie małej firmy i w monitoringu bezpieczeństwa dla MŚP.

Najczęstsze pytania (FAQ)

570 czy 622 podatności — która liczba jest prawdziwa? Obie opisują co innego. 570 to podatności w produktach Microsoftu objęte lipcowym Patch Tuesday. Szersza liczba 622 doliczała poprawki dla Edge opartego na Chromium, które wychodzą w osobnym cyklu powiązanym z wydaniami Google. Przy planowaniu prac operacyjnych używaj 570, ale nie zapominaj o aktualizacji przeglądarki — to osobny, równie istotny tor.

Czy musimy załatać wszystkie 570 w tym miesiącu? Nie i prawdopodobnie się nie da. Musisz natomiast świadomie zdecydować, czego nie łatasz i dlaczego. Różnica między dojrzałym a niedojrzałym procesem nie polega na tym, że wszystko jest załatane, lecz na tym, że zaległości są znane, uzasadnione i mają termin.

Dlaczego zero-day jest groźniejszy niż luka z CVSS 9.8? Bo CVSS opisuje potencjał, a aktywna eksploatacja to fakt. Luka o ocenie 9.8, dla której nikt nie napisał exploita, jest mniej pilna niż luka 7.8 wykorzystywana dziś w kampanii. Dlatego dane o realnym wykorzystaniu powinny mieć w Twoim procesie wagę wyższą niż sama punktacja.

Co zrobić, jeśli nie możemy zrestartować serwera? Potraktuj to jako ryzyko do zarządzania, nie jako stan trwały. Ustal okno serwisowe, zaplanuj przełączenie na system zapasowy albo zastosuj kontrolę kompensującą (ograniczenie dostępu sieciowego, wirtualna łatka na WAF). Zapisz decyzję i termin — niezałatany system bez terminu to dług, który zawsze wypłynie w najgorszym momencie.

Jak sprawdzić, czy nasz proces łatania rzeczywiście działa? Najprościej: wybierz jedną krytyczną podatność sprzed miesiąca i policz, ile systemów nadal jest podatnych. Wynik zwykle różni się od raportu. Jeśli chcesz zewnętrznej weryfikacji tego, co widać z internetu i jak szybko domykasz okna — sprawdźmy to razem.

Podsumowanie

Lipcowy rekord — 570 podatności i trzy zero-daye — to mniej opowieść o wyjątkowo złym miesiącu, a bardziej sprawdzian dojrzałości procesu. Liczba poprawek będzie rosła: znajdowanie błędów jest coraz tańsze, m.in. dzięki narzędziom automatycznym, a portfolio oprogramowania coraz szersze. Organizacje, które nadal opierają łatanie na ręcznym przeglądzie biuletynów i kwartalnym oknie serwisowym, będą coraz bardziej w tyle.

Praktyczny wniosek jest prosty: skup się na przecięciu trzech zbiorów — co jest wystawione do internetu, co jest aktywnie wykorzystywane i co faktycznie masz w swojej infrastrukturze. To zwykle kilkanaście pozycji z pięciuset. Resztę załatw normalnym cyklem i mierz czas, nie procenty. Jeśli chcesz wiedzieć, jak Twoja organizacja wypada pod względem realnego czasu domykania krytycznych okien — zacznijmy od rozpoznania powierzchni ataku.

Źródła i dalsza lektura: Microsoft Security Update Guide, Krebs on Security, BleepingComputer, Zero Day Initiative, CISA KEV.