Patchstack opisał ciekawy, ale średnio wygodny problem z polityką WordPress.org Protect The Shire. Mechanizm ma ograniczać ryzyko złośliwych aktualizacji wtyczek i motywów, zanim trafią masowo do stron. Tyle że według danych Patchstack ten sam bufor może opóźniać także poprawki bezpieczeństwa dla publicznie znanych podatności. Czyli w panelu WordPressa wszystko może wyglądać spokojnie, podczas gdy poprawiona wersja wtyczki już istnieje – tylko jeszcze nie jest podawana przez standardowy mechanizm aktualizacji.
Kluczowe wnioski
- Protect The Shire opóźniało aktualizacje o około 24 godziny, a od 16 lipca o około 6-7 godzin.
- Opóźnienie dotyczy zarówno automatycznych aktualizacji, jak i przycisku Aktualizuj teraz w WordPressie.
- Patchstack wskazuje, że poprawki bezpieczeństwa i zwykłe wydania czekały prawie tyle samo.
- W badanym okresie opóźnienie objęło 81 wydań łatających CVE w 79 wtyczkach z około 9,9 mln łącznych instalacji.
- Panel WordPressa może pokazywać brak aktualizacji, mimo że poprawiona wersja wtyczki istnieje już poza mechanizmem update-check.
Czym jest Protect The Shire
WordPress.org ogłosił Protect The Shire 5 czerwca 2026 roku jako inicjatywę zabezpieczającą katalog około 78 000 wtyczek i motywów. Pierwszy praktyczny efekt: nowe wydania nie trafiają od razu do mechanizmu aktualizacji. Dotyczy to zarówno auto-update, jak i ręcznego przycisku Aktualizuj teraz, bo oba korzystają z tego samego zegara po stronie update-check.
Sam pomysł nie jest absurdalny. Przejęcia wtyczek, sprzedaż projektów podejrzanym właścicielom i złośliwy kod wrzucany do aktualizacji to realny problem. Tylko że złośliwa aktualizacja i publicznie znana luka bezpieczeństwa to dwa różne przypadki.
Jak długo aktualizacje czekały w kolejce
Patchstack zmierzył rzeczywiste czasy opóźnienia, zamiast opierać się wyłącznie na deklaracjach. Według ich danych od 7 do 15 lipca mediana czasu oczekiwania wynosiła około 24,2-24,5 godziny. Od 16 lipca spadła do około 6,6-6,8 godziny.
To poprawa, ale niekoniecznie rozwiązanie problemu. Przy zwykłej aktualizacji kilka godzin różnicy rzadko robi dramat. Przy publicznie opisanej podatności, zwłaszcza krytycznej, kilka godzin to już całkiem sporo czasu dla botów, które nie piją kawy i nie czekają do poniedziałku.
Gdzie ten mechanizm faktycznie pomaga
Patchstack podaje przykład wtyczki Advanced Responsive Video Embedder, mającej około 20 000 instalacji. Wordfence wykrył złośliwy backdoor dwie godziny po tym, jak kod trafił do wydania. Luka CVE-2026-18072 miała ocenę CVSS 9.8 i pozwalała na pełne przejęcie administratora jednym żądaniem.
WordPress.org usunął problem tego samego dnia, a złośliwa wersja nie zdążyła szeroko rozejść się przez auto-update. To dokładnie taki scenariusz, w którym opóźnienie dystrybucji ma sens. Lepiej zatrzymać podejrzane wydanie przed masowym rozlaniem się po stronach.
Problem zaczyna się przy znanych podatnościach
Według Patchstack Protect The Shire nie rozróżniał wystarczająco między zwykłym wydaniem, złośliwą aktualizacją i poprawką bezpieczeństwa. W analizie 114 rozwiązanych wydań poprawki dla ujawnionych CVE czekały prawie tyle samo, co rutynowe aktualizacje: około 24,4 godziny przed 16 lipca i około 6,8 godziny po zmianie.
W 17-dniowym oknie Patchstack naliczył 81 wydań łatających ujawnione CVE, obejmujących 79 różnych wtyczek z około 9,9 mln łącznych instalacji. Trzydzieści poprawek miało CVSS 7.0 lub wyżej, a dziewięć miało CVSS 9.0 lub wyżej, w tym jedna podatność oceniona na 10.0.
Panel WordPressa nie zawsze mówi całą prawdę
Najbardziej praktyczny problem: administrator może patrzeć w kokpit WordPressa i widzieć, że aktualizacji nie ma. Patchstack wskazuje przypadki, w których strona wtyczki i metadane pokazywały już wersję poprawioną, ale update-check API nadal podawało starszą, podatną wersję.
Przykłady z tekstu to AcyMailing, gdzie poprawiona wersja 10.11.1 łatała nieuwierzytelnione SQL injection, oraz Page View Count, gdzie metadane pokazywały 2.9.2, a mechanizm aktualizacji nadal serwował 2.9.1. Dla właściciela strony wygląda to niewinnie: skoro WordPress nie pokazuje aktualizacji, to pewnie nic nie trzeba robić. No właśnie nie zawsze.
Co powinni zrobić właściciele stron, agencje i hostingi
Najważniejszy wniosek jest prosty: przy krytycznych alertach bezpieczeństwa nie warto polegać wyłącznie na komunikacie z kokpitu WordPressa. Jeśli wiarygodne źródło informuje, że dana wtyczka ma poprawioną wersję, trzeba sprawdzić, czy standardowy mechanizm aktualizacji faktycznie już ją widzi.
Dla agencji i hostingów temat jest jeszcze bardziej niewygodny, bo narzędzia do masowego zarządzania stronami często stoją na tym samym update-check API. Jeśli ono ma kilka godzin opóźnienia, szybki panel do utrzymania setek stron też może być szybki tylko na papierze. Patchstack sugeruje, że poprawki potwierdzonych podatności powinny być wyłączone z kolejki albo przepuszczane szybciej.
Pełną analizę z danymi i przykładami warto przeczytać u źródła: Patchstack – Protect The Shire solves one problem, but risks making another worse.
Najczesciej zadawane pytania
Czy Protect The Shire wpływa na przycisk Aktualizuj teraz?
Tak. Według Patchstack zarówno automatyczne aktualizacje, jak i ręczny przycisk Aktualizuj teraz korzystają z tego samego mechanizmu update-check, więc mogą być objęte tym samym opóźnieniem.
Jak długo według Patchstack czekały aktualizacje wtyczek?
Patchstack zmierzył medianę opóźnienia na około 24,2-24,5 godziny od 7 do 15 lipca 2026 roku. Od 16 lipca czas ten spadł do około 6,6-6,8 godziny.
Czy panel WordPressa może nie pokazać dostępnej poprawki bezpieczeństwa?
Tak. Patchstack opisał przypadki, w których strona wtyczki i metadane pokazywały już poprawioną wersję, ale update-check API nadal podawało starszą, podatną wersję.
Jakie przykłady wtyczek podał Patchstack?
Patchstack wymienił między innymi AcyMailing, gdzie poprawiona wersja 10.11.1 łatała nieuwierzytelnione SQL injection, oraz Page View Count, gdzie metadane pokazywały 2.9.2, a mechanizm aktualizacji nadal serwował 2.9.1.
Co powinien zrobić administrator przy krytycznym alercie bezpieczeństwa?
Nie powinien polegać wyłącznie na komunikacie z kokpitu WordPressa. Warto sprawdzić zaufane źródła bezpieczeństwa i upewnić się, czy standardowy mechanizm aktualizacji faktycznie widzi już poprawioną wersję.