Wprowadzenie
WordPress.org wstrzymuje dziś każde nowe wydanie wtyczki do sześciu godzin, zanim trafi ono do auto-aktualizacji. Patchstack mierzy medianę czasu od publicznego ujawnienia podatności do masowej eksploatacji na pięć godzin. Te dwie liczby żyją obok siebie w publicznym zapisie od lipca i nikt nie postawił ich obok siebie.
W skrócie
- Sześć godzin trwa dziś wstrzymanie wydania wtyczki lub motywu w ramach inicjatywy Protect the Shire. Start 5 czerwca 2026 z okresem do 24 godzin, skrócenie do sześciu przed 18 lipca 2026.
- Pięć godzin to mediana czasu do masowej eksploatacji podatności o wysokim wpływie, według raportu Patchstack State of WordPress Security in 2026 z 25 lutego 2026.
- 46 procent podatności nie ma łatki w momencie publicznego ujawnienia. Ta liczba pochodzi z tego samego raportu i zmienia sens obu poprzednich.
- Publiczny zapis nie mówi, czy łatka bezpieczeństwa jest z wstrzymania zwolniona. Ogłoszenie mówi o każdym nowym wydaniu i nie wprowadza rozróżnienia.
- Skrócenie do sześciu godzin zostało ogłoszone wyłącznie na Slacku. Autorzy wtyczek dowiadywali się o nim przy własnym wydaniu.
- 11 334 nowe podatności w ekosystemie w 2025 roku, o 42 procent więcej rok do roku, a tych łatwych do wykorzystania przybyło o 113 procent.
- 12 procent znanych ataków na WordPressa zatrzymują typowe zestawy hostingu i WAF-a. Ta liczba przycina radę, którą sam dalej daję.
Skąd się wzięło wstrzymanie
W kwietniu 2026 z katalogu wyleciało naraz trzydzieści jeden wtyczek jednej marki. Wszystkie miały backdoora. Nikt niczego nie złamał: ktoś kupił wtyczki na Flippie, dostał wraz z nimi dostęp do SVN i wypchnął jedną złośliwą aktualizację podpisaną jako łatka zgodności z WordPress 6.8.2.
Warto rozłożyć ten atak na etapy, bo każdy z nich jest legalny osobno i dopiero razem tworzą włamanie. Kupno wtyczki na giełdzie jest legalne. Przejęcie wraz z nią konta w repozytorium jest zgodne z regulaminem, bo tak właśnie wygląda zmiana właściciela. Wypchnięcie aktualizacji jest normalną czynnością autora. Podpisanie jej jako łatki zgodności z konkretnym wydaniem WordPressa jest wiarygodne, bo takie łatki faktycznie wtedy wychodziły. Zasięg opisywano na do czterystu tysięcy stron.
Żaden element tego łańcucha nie wygląda podejrzanie z osobna i to jest sedno. Kontrola oparta na tym, kto wypycha kod, nie miała czego wykryć, bo wypychał go prawowity właściciel. Wykryć dało się wyłącznie to, co było w środku.
To jest atak na łańcuch dostaw w najczystszej postaci i katalog nie miał na niego żadnej odpowiedzi, bo cały model zaufania opierał się na założeniu, że kto ma commit, ten jest tym, za kogo się podaje. Protect the Shire jest odpowiedzią na dokładnie ten scenariusz: między commitem a dystrybucją wstawia okno, w którym automat i człowiek mogą się przyjrzeć temu, co za chwilę pojedzie na miliony instalacji.
Jako odpowiedź na tamten atak wstrzymanie ma sens i chcę to powiedzieć wprost, zanim przejdę do zarzutu. Sześć godzin między złośliwym commitem a auto-aktualizacją to sześć godzin, których wcześniej nie było.
Gdzie te sześć godzin przestaje pomagać
Wstrzymanie jest neutralne wobec zawartości wydania. Nie wie, czy w środku jest nowa funkcja, poprawka literówki, czy łatka na aktywnie eksploatowaną podatność. Ogłoszenie z 5 czerwca mówi o każdym nowym wydaniu i nie wprowadza żadnego rozróżnienia. Nie znalazłem też źródła, które opisywałoby tryb przyspieszony dla wydań bezpieczeństwa.
Chcę być precyzyjny, bo to jest miejsce, w którym łatwo napisać nieprawdę. Nie twierdzę, że tryb przyspieszony nie istnieje. Twierdzę coś słabszego i sprawdzalnego: nie jest opisany tam, gdzie autor wtyczki mógłby go znaleźć, czyli w ogłoszeniu inicjatywy ani w kolejnych publicznych wpisach o niej. Dla autora, który właśnie dostał zgłoszenie o podatności i szykuje wydanie awaryjne, brak opisanej ścieżki jest praktycznie tym samym co brak ścieżki.
I tu wchodzi druga liczba. Patchstack mierzy medianę czasu do masowej eksploatacji podatności o wysokim wpływie na pięć godzin od publicznego ujawnienia. Mediana, nie średnia, więc połowa przypadków dzieje się szybciej.
Zestawienie tych dwóch liczb wymaga ostrożności, bo mierzą różne rzeczy. Sześć godzin to opóźnienie dystrybucji aktualizacji. Pięć godzin to czas od ujawnienia do skali ataku. Nie nakładają się na siebie idealnie i nie twierdzę, że każda łatka spóźnia się o godzinę. Twierdzę, że okno ochronne katalogu jest tego samego rzędu wielkości co okno ataku, a przy takiej relacji buforowanie wydania przestaje być darmowe.
Liczba, która zmienia obie poprzednie
Ten sam raport Patchstack podaje, że 46 procent podatności nie miało łatki w momencie publicznego ujawnienia.
To jest liczba, która przestawia całą dyskusję. Prawie połowa przypadków to sytuacja, w której nie ma czego wstrzymywać, bo nie ma jeszcze wydania. Wtedy wstrzymanie nie kosztuje nic, ale też nic nie daje, a jedyne co chroni stronę to warstwa, która nie czeka na katalog: reguła WAF, wyłączona funkcja, dezaktywowana wtyczka.
W praktyce oznacza to, że dyskusja o sześciu godzinach dotyczy nieco ponad połowy przypadków. Dla reszty pytanie brzmi zupełnie inaczej i katalog nie jest w nim stroną.
Skala, przez którą sześć godzin w ogóle ma znaczenie
Sześć godzin brzmi niegroźnie, dopóki nie zestawi się tego z liczbą wydarzeń, które przez to okno przechodzą.
Patchstack naliczył w ekosystemie WordPressa 11 334 nowe podatności w 2025 roku, czyli o 42 procent więcej niż rok wcześniej. To jest średnio ponad trzydzieści dziennie. Sam wzrost wolumenu byłby jeszcze do zniesienia, gdyby rósł równomiernie, ale nie rośnie: podatności zaklasyfikowane jako łatwe do wykorzystania wzrosły o 113 procent rok do roku, czyli ponad dwukrotnie.
Te dwie liczby razem zmieniają charakter problemu. Nie chodzi o to, że jest więcej dziur. Chodzi o to, że rośnie przede wszystkim ta ich część, którą da się wykorzystać bez wysiłku, a więc masowo i automatycznie. Przy takim profilu mediana pięciu godzin do masowej eksploatacji przestaje być ciekawostką statystyczną i staje się opisem normalnego dnia.
W tym kontekście wstrzymanie po stronie katalogu jest jedną z niewielu dźwigni, które w ogóle działają na skalę. Automat, który przygląda się każdemu wydaniu, skaluje się lepiej niż jakikolwiek proces oparty na tym, że autor wtyczki albo administrator strony zdąży zareagować. Dlatego uważam, że kierunek jest słuszny, a spór dotyczy wyłącznie tego, czy okno jest neutralne wobec zawartości wydania.
Poprawka do mojej własnej rady
Napisałem wyżej, żeby zbudować warstwę, która nie czeka na katalog, i wskazałem regułę WAF. Ten sam raport Patchstack zawiera liczbę, która tę radę mocno przycina, i nie zamierzam jej przemilczeć.
W testach penetracyjnych typowe zestawy hostingu i WAF-a zablokowały 12 procent znanych, aktywnie wykorzystywanych ataków specyficznych dla WordPressa oraz 26 procent szerszego zestawu testowego. Czyli osiem na dziesięć realnych ataków przechodzi przez to, co większość agencji uznaje za swoją warstwę ochronną.
Rozróżnienie, które to ratuje, jest konkretne i warto je nazwać. Generyczny WAF hostingowy filtruje wzorce ogólne, w rodzaju prostych prób SQL injection czy skanów ścieżek. Podatność w konkretnej wtyczce zwykle nie wygląda jak atak generyczny, tylko jak poprawne żądanie do poprawnego endpointu z jednym parametrem ustawionym inaczej, niż autor przewidział. Generyczna reguła tego nie widzi.
Co innego reguła pisana pod konkretne, ujawnione CVE, czyli to, co branża nazywa wirtualnym patchowaniem. Ona nie musi rozumieć klasy ataku, wystarczy że zna sygnaturę tego jednego. To jest ta warstwa, którą miałem na myśli, i chcę być precyzyjny: nie chodzi o to, żeby mieć WAF, tylko o to, żeby mieć proces dokładania reguły w godzinach od ujawnienia. Sam fakt posiadania WAF-a jest, według tych liczb, wart mniej niż powszechnie się zakłada.
Jest w tym też uczciwe zastrzeżenie wobec źródła. Patchstack sprzedaje wirtualne patchowanie, więc liczba pokazująca słabość generycznych WAF-ów jest dla niego korzystna. Nie znaczy to, że jest nieprawdziwa, bo metodologia jest opisana w raporcie i mówi o testach penetracyjnych na znanym zestawie exploitów. Znaczy, że warto ją czytać ze świadomością, kto ją publikuje. Podaję to, żeby nikt nie musiał tego odkrywać sam.
Slack to nie jest kanał ogłoszeń
Skrócenie z 24 godzin do sześciu weszło bez publicznego wpisu. Wykrył je Ajay D’Souza, wydając wtyczkę przed 18 lipca 2026. Enrico Battocchi zapytał wprost, jak w ogóle mieli się o tym dowiedzieć i czy będzie wpis. Deweloper Lopo opisał koszt operacyjny: dowiadywanie się po wydaniu, że trzeba przeorganizować dyżury, żeby dopilnować wdrożenia.
To jest osobny problem od samego wstrzymania i moim zdaniem poważniejszy. Autor wtyczki planuje wydanie awaryjne wokół znanego opóźnienia. Jeśli opóźnienie zmienia się bez ogłoszenia, planowanie przestaje działać w obie strony: raz czekasz dłużej niż myślałeś, raz krócej i nie ma cię przy monitorowaniu wdrożenia.
Istnieje szkic propozycji, żeby pominąć wstrzymanie, gdy skan Gandalf nie znajdzie nic podejrzanego. Wersja, którą przeskanował, przestaje wtedy czekać i zaczyna być serwowana. To rozwiązuje większość problemu, bo czysty skan to zdecydowana większość wydań. Propozycja jest na etapie przeglądu i nie została wdrożona.
Co z tym zrobić po stronie strony
Jeżeli utrzymujesz serwisy klienckie, wstrzymanie w katalogu jest zmienną, na którą nie masz wpływu. Masz wpływ na cztery inne.
Nie wyłączaj auto-aktualizacji w reakcji na tę zmianę. To najczęstszy odruch i jest odwrotnością tego, co pokazują liczby. Wstrzymanie kosztuje godziny. Ręczne klikanie kosztuje dni, a przy sześciu locale i kilkudziesięciu serwisach kosztuje tygodnie. Skoro połowa krytycznych błędów jest eksploatowana w pierwszej dobie, twój własny czas reakcji jest większym ryzykiem niż okno katalogu.
Warto zobaczyć, jak wygląda arytmetyka. Wstrzymanie dodaje najwyżej sześć godzin. Ręczna aktualizacja raz w tygodniu daje średnie opóźnienie około osiemdziesięciu czterech godzin, czyli czternaście razy więcej. Nawet ręczna aktualizacja codziennie daje średnio dwanaście godzin, wciąż dwa razy więcej niż okno katalogu. Jeśli więc ktoś argumentuje, że wstrzymanie jest zbyt ryzykowne i dlatego przechodzi na tryb ręczny, wymienia sześć godzin na kilkadziesiąt.
Zbuduj proces dokładania reguły, nie sam WAF. Po korekcie z poprzedniej sekcji ta rada brzmi inaczej niż zwykle. Samo posiadanie WAF-a hostingowego zatrzymuje, według testów Patchstack, dwanaście procent znanych ataków na WordPressa. Wartość ma dopiero zdolność dołożenia reguły pod konkretne, świeżo ujawnione CVE w ciągu godzin. To jest różnica między produktem a procedurą, i to procedura tu decyduje.
Miej listę wtyczek, które są dla klienta krytyczne, i wiedz, którą da się wyłączyć na godzinę. Dezaktywacja jednej wtyczki formularza na czas, aż łatka dojdzie, jest tania. Dezaktywacja bramki płatności nie jest. Ta różnica powinna być ustalona przed incydentem, nie w jego trakcie. W praktyce wystarczy jedna kolumna w arkuszu, którą wypełnia się raz przy przejmowaniu serwisu.
Wiedz, skąd dowiesz się o podatności, zanim dowiesz się z monitoringu. Kanał informacyjny jest tu równie ważny jak warstwa techniczna, bo przy medianie pięciu godzin różnica między dowiedzeniem się rano a wieczorem jest różnicą między łatką a incydentem. Feed podatności czytany codziennie jest tańszy niż jakiekolwiek narzędzie i to on wyznacza górną granicę tego, jak szybko w ogóle możesz zareagować.
Strona autora wtyczki, czyli druga połowa problemu
Dotąd pisałem z perspektywy kogoś, kto utrzymuje cudze serwisy. Autor wtyczki ma ten sam problem odwrócony i jego wersja jest trudniejsza, bo to on siedzi po stronie zegara.
Scenariusz wygląda tak. Dostajesz zgłoszenie o podatności, zwykle przez program bug bounty albo bezpośrednio od badacza. Ustalasz z nim datę publikacji, przygotowujesz łatkę, testujesz, wypychasz wydanie. Do czerwca 2026 od commitu do dystrybucji były minuty. Teraz jest do sześciu godzin i nie masz tego jak przyspieszyć w sposób, który byłby opisany publicznie.
Praktyczna konsekwencja jest taka, że data publikacji ustalona z badaczem musi mieć zapas. Jeżeli umawiasz się na ujawnienie w poniedziałek o dziewiątej, wydanie musi wyjść w niedzielę wieczorem, a nie w poniedziałek o ósmej. Przy medianie pięciu godzin do masowej eksploatacji ta godzina różnicy jest realna.
Druga konsekwencja dotyczy dyżurów. Deweloper Lopo opisał to najkrócej: dowiadywanie się po wydaniu, że trzeba przeorganizować zmiany, żeby dopilnować wdrożenia. Jeżeli wydajesz wtyczkę z pół milionem instalacji, ktoś musi patrzeć na zgłoszenia w godzinach, w których aktualizacja faktycznie się rozchodzi. Przy oknie ruchomym i nieogłaszanym publicznie tego się nie zaplanuje.
Trzecia rzecz jest subtelniejsza. Wstrzymanie zmienia sens numeru wersji. Do tej pory wypchnięcie 2.4.1 znaczyło, że 2.4.1 jest w obiegu. Teraz znaczy, że będzie za jakiś czas, a przez ten czas w obiegu jest 2.4.0, czyli wersja podatna, o której już wiadomo publicznie, że jest podatna. Komunikacja z użytkownikami musi to uwzględniać, bo inaczej wpis „naprawione w 2.4.1” jest prawdziwy i mylący jednocześnie.
Gandalf, czyli zaufanie przeniesione, nie usunięte
Wstrzymanie samo w sobie niczego nie sprawdza. Sprawdza to, co dzieje się w jego trakcie, a w ogłoszeniu ta rola przypada automatowi nazwanemu Gandalf.
Warto zauważyć, co się tu naprawdę wydarzyło z punktu widzenia modelu zaufania. Do kwietnia katalog ufał posiadaczowi dostępu do SVN. Po kwietniu wiadomo, że ten dostęp bywa kupowany razem z wtyczką, więc zaufanie zostało z tego miejsca zabrane. Nie zostało jednak zlikwidowane, tylko przeniesione na automat, który ocenia treść wydania.
To jest lepsze rozwiązanie i chcę to napisać wprost, bo automat nie da się kupić na Flippie. Ale wprowadza dwa nowe pytania, na które publiczny zapis nie odpowiada.
Pierwsze jest o pomyłki w drugą stronę. Skaner, który przepuszcza złośliwe wydanie, jest problemem oczywistym. Skaner, który blokuje wydanie poprawne, jest problemem cichszym i dla autora dotkliwszym, bo nie wiadomo, do kogo się odwołać ani jak długo to potrwa. Nie znalazłem opisu procedury odwoławczej.
Drugie jest o to, jak długo trwa sam skan. Jeżeli trwa dwadzieścia minut, to sześciogodzinne okno jest w dziewięćdziesięciu pięciu procentach buforem, a nie pracą, i propozycja pomijania wstrzymania przy czystym wyniku rozwiązuje właściwie cały problem. Jeżeli trwa pięć godzin, jest odwrotnie. Ta jedna liczba zmienia wnioski i nie jest podana publicznie.
Czego ta zmiana nie naprawia
Warto powiedzieć jasno, czego wstrzymanie nie dotyka, bo łatwo je przecenić.
Nie dotyka wtyczek spoza katalogu. Wtyczka premium, kupiona bezpośrednio u autora albo w marketplace, aktualizuje się własnym kanałem i żaden okres wstrzymania jej nie obejmuje. W typowym sklepie WooCommerce takich wtyczek jest zwykle kilka i to często te najbardziej wrażliwe, bo dotykają płatności, wysyłki i danych klienta.
Nie dotyka też motywów i wtyczek zainstalowanych ręcznie z pliku ZIP, ani kodu we wtyczce funkcjonalnej klienta. A to właśnie tam, w kodzie pisanym doraźnie i nieaktualizowanym latami, siedzi zwykle najwięcej długu.
Wreszcie nie dotyka sytuacji, w której to nie kod jest problemem, tylko konfiguracja: zbyt szerokie uprawnienia, konto administratora bez drugiego składnika, klucz API w repozytorium. Katalog nie ma tu żadnej roli, a udział takich przypadków w realnych incydentach jest wysoki.
Czego nie wiem
Trzy rzeczy zostawiam otwarte, bo nie mam na nie źródła i nie zamierzam zgadywać.
Nie wiem, czy wydania bezpieczeństwa mają tryb przyspieszony, którego nie opisano publicznie. Nie wiem, ile faktycznie trwa pełny skan Gandalf, więc nie wiem, ile z tych sześciu godzin jest pracą, a ile buforem. Nie wiem, kiedy propozycja pomijania wstrzymania przy czystym skanie zostanie wdrożona ani czy w ogóle.
Jeśli którakolwiek z tych rzeczy zostanie opisana publicznie, zaktualizuję ten wpis i odnotuję datę.
Źródła
- Protect The Shire, WordPress News, 5 czerwca 2026
- Patchstack, State of WordPress Security in 2026, 25 lutego 2026
- Skrócenie okresu wstrzymania do sześciu godzin i reakcje deweloperów
Ostatnia weryfikacja: 10 sierpnia 2026.
