Dwunastego sierpnia wyszedł WordPress 7.0.4. Sześć dni po 7.0.3, dwadzieścia sześć dni po 7.0.2. Cztery wydania bezpieczeństwa rdzenia w niecały miesiąc — w oprogramowaniu, które przez lata wydawało takie poprawki kilka razy do roku.
Sama luka jest tym razem węższa niż poprzednie: uwierzytelnione wykonanie kodu przez wgranie złośliwego pliku, wymagające uprawnień co najmniej autora, na witrynach korzystających z Imagick i Ghostscriptu. Zgłaszający: pwn.ai— ten sam zespół, który tydzień temu dał nam XSS2Shell.
Ale nie luka jest tu tematem. Tematem jest to, dlaczego wydań jest cztery — i co pokazuje lista zgłaszających.
Kto zgłosił trzy ostatnie wydania
Prześledźmy autorstwo, bo dopiero zestawione razem układa się w obraz.
7.0.2 — łańcuch wp2shell, o którym pisaliśmy w lipcu. Według analizy Patchstack nie znalazł go człowiek przeczesujący linijka po linijce interfejs zbiorczy. Searchlight Cyber uruchomił model frontier na rdzeniu WordPressa i miał działający nieuwierzytelniony SQL injection, spięty aż do wykonania kodu, w dziesięć godzin. Koszt: około dwadzieścia pięć dolarów.
7.0.3 — dwanaście luk. XSS2Shell przypisany pwn.ai, firmie oferującej autonomiczny pentest, a osobna luka wstrzyknięcia CSS — bezpośrednio Anthropicowi.
7.0.4 — znów pwn.ai.
Patchstack nazywa to przesunięciem wartym uwagi i trudno się nie zgodzić. Trzy kolejne wydania bezpieczeństwa rdzenia, którym stoi połowa internetu, zgłoszone w większości przez podmioty zajmujące się automatycznym znajdowaniem luk przy pomocy modeli.
Sam pwn.ai opisuje przy tym swój proces w sposób, który warto zacytować, bo pokazuje coś więcej niż skanowanie. Przy wcześniejszym badaniu ImageMagicka zespół pisał, że agent zidentyfikował tę bibliotekę jako główny wektor, a ponieważ w aplikacji nie było nic innego, zrobił rzecz nietypową: pobrał ImageMagicka do własnego środowiska i rozpoczął wielodniowy, systematyczny audyt całego potoku przetwarzania. XSS2Shell odkryto, jak podaje firma, całkowicie autonomicznie.
Dwadzieścia pięć dolarów
Zatrzymajmy się przy tej liczbie, bo jest najważniejsza w całej tej historii.
Dwa tygodnie temu, pisząc o modelu cyber Microsoftu, postawiliśmy tezę, że ograniczeniem tego wyścigu nigdy nie była zdolność, tylko cena skanowania — a producent właśnie zmniejszył ją o połowę. Wtedy była to obserwacja o architekturze routingu. Teraz mamy konkretny cennik: pełny łańcuch od zera do zdalnego wykonania kodu w rdzeniu WordPressa kosztuje mniej niż obiad w mieście.
To wyjaśnia tempo wydań lepiej niż jakakolwiek hipoteza o pogorszeniu jakości kodu. WordPress nie stał się nagle mniej bezpieczny. Stał się tani do przeszukania — i wiele podmiotów robi to naraz, bo koszt spadł poniżej progu, przy którym trzeba się zastanawiać, czy warto.
To jest ta sama obserwacja, którą przy lipcowej zmianie doktryny łatania sformułowało amerykańskie środowisko prognostyczne: eksplozja liczby zgłaszanych podatności nie oznacza, że oprogramowanie się psuje, lecz że strukturalnie zmieniła się nasza zdolność znajdowania błędów. Pisaliśmy o tym, gdy CISA uchyliła własny nakaz łatania wszystkiego. WordPress jest teraz tego najlepiej widoczną ilustracją, bo ma jeden rdzeń, jeden kanał wydań i pół miliarda instalacji.
I warto powiedzieć wprost: to jest dobra wiadomość. XSS2Shell siedział w kodzie od 2016 roku i, jak zauważa sam odkrywca, został jakoś przeoczony przez wszystkie dotychczasowe audyty. Nie powstał w lipcu — tylko w lipcu ktoś go wreszcie zobaczył. Każda z tych czterech poprawek zamyka drogę, która była otwarta wcześniej, tylko nikt o niej nie wiedział.
Dlaczego akurat ImageMagick
Luka z 7.0.4 wpisuje się przy tym w wątek, który pwn.ai prowadzi od wiosny i który sam w sobie jest pouczający.
WordPress używa ImageMagicka — przez rozszerzenie Imagick — jako domyślnego silnika przetwarzania obrazów: do generowania miniatur, zmiany rozmiaru i podglądów plików PDF. Kluczowy szczegół, na który badacze zwracali uwagę już w marcu: WordPress nie ustawia żadnej własnej polityki bezpieczeństwa dla ImageMagicka, polegając w całości na tym, co skonfigurował administrator serwera.
Sam ImageMagick przekazuje zaś złożone pliki dalej, do Ghostscriptu. I tu pojawia się problem, który pwn.ai opisał zwięźle: granice bezpieczeństwa obu komponentów nie uwzględniają siebie nawzajem. Jeden dostarcza możliwość zapisu, drugi pozwala wyjść poza własne ograniczenia.
To jest dokładnie ten sam kształt co przy XSS2Shell, gdzie luka istniała wyłącznie w różnicy między dwoma mechanizmami sanityzującymi, z których każdy z osobna działał poprawnie. Dwa komponenty, każdy prawidłowy, granica między nimi niczyja.
Uczciwie: proporcje
Kilka rzeczy trzeba postawić, żeby nie zrobić z tego alarmu.
Luka z 7.0.4 jest znacznie węższa niż dwie poprzednie. Wymaga konta z uprawnieniami autora, czyli kogoś, kto może wgrywać pliki — a więc nie dotyczy witryn bez zewnętrznych współautorów. Wymaga też, by serwer korzystał z Imagicka i Ghostscriptu. Dla porównania XSS2Shell działał bez żadnego konta, a wp2shell prowadził do przejęcia domyślnej instalacji.
W chwili pisania nie ma publicznie przypisanego numeru CVE ani opublikowanej analizy technicznej tej konkretnej poprawki, a WordPress nie opisuje jej jako wykorzystywanej w atakach. Warto o tym pamiętać przy ocenie pilności — choć rekomendacja producenta jest jednoznaczna i brzmi „aktualizuj natychmiast".
Trzeba też zaznaczyć rzecz, która przy tym tempie wydań ma znaczenie praktyczne: firmy zgłaszające te luki sprzedają narzędzia do ich znajdowania. To nie podważa samych ustaleń — są potwierdzone przez WordPress, załatane i w części opisane numerami CVE — ale tłumaczy, dlaczego akurat teraz i akurat te podmioty dominują na liście podziękowań. Znajdowanie luk w najpopularniejszym oprogramowaniu świata jest dla nich zarazem badaniem i marketingiem.
I przypis, który powtarzamy przy każdym wydaniu WordPressa od lipca: CERT Polska ostrzegał wtedy, że wymuszona automatyczna aktualizacja w licznych przypadkach nie zadziałała. Przy czterech wydaniach w miesiącu to zastrzeżenie waży więcej niż zwykle.
Co z tego wynika dla obrońcy
Rzecz pierwsza jest natychmiastowa: sprawdź faktycznie zainstalowaną wersję, a nie to, czy automatyczne aktualizacje są włączone. Docelowo 7.0.4 lub odpowiednia załatana wersja ze starszej gałęzi.
Rzecz druga wynika z warunków tej konkretnej luki i jest tania. Jeśli twoja witryna ma współautorów z uprawnieniami pozwalającymi wgrywać pliki, przejrzyj tę listę — bo tu właśnie przebiega granica podatności. A jeśli nie potrzebujesz podglądów plików PDF, warto sprawdzić z administratorem serwera, czy polityka ImageMagicka blokuje moduły wywołujące Ghostscript. WordPress tej polityki za ciebie nie ustawi.
Rzecz trzecia jest procesowa i wynika z tempa. Cztery wydania w miesiącu to rytm, którego pół roku temu nie było — a jeśli teza o taniejącym skanowaniu jest trafna, będzie się utrzymywał. Warto to policzyć: ile realnie trwa u ciebie droga od ogłoszenia wydania bezpieczeństwa do potwierdzonej aktualizacji na wszystkich witrynach, łącznie z tymi zapomnianymi i testowymi. Jeśli odpowiedź brzmi „tydzień", to przy tym tempie oznacza, że przez większość miesiąca stoisz na wersji podatnej na coś, co jest już publicznie opisane.
Jedna myśl na koniec
Przez lata liczba wydań bezpieczeństwa była w naszej głowie miarą jakości oprogramowania: częste łatki znaczyły, że coś jest dziurawe. Ta intuicja właśnie przestała działać.
Cztery wydania WordPressa w miesiąc nie mówią nic o tym, jak dobrze napisano ten kod — bo wszystkie cztery luki były w nim wcześniej, część od dekady. Mówią o tym, ile teraz kosztuje ich znalezienie. Dwadzieścia pięć dolarów i dziesięć godzin za pełny łańcuch w rdzeniu najpopularniejszego oprogramowania świata to nie jest informacja o WordPressie. To jest informacja o tym, ile takich łańcuchów czeka w każdym innym projekcie, którego nikt jeszcze nie przeskanował — bo do niedawna było to za drogie, żeby próbować bez konkretnego powodu.
Źródła
WordPress — ogłoszenie wydania 7.0.4 z 12 sierpnia 2026 wraz z podziękowaniem dla zespołu pwn.ai za zgłoszenie uwierzytelnionego wykonania kodu przez wgranie złośliwego pliku na witrynach używających Imagick i Ghostscriptu: https://wordpress.org/news/2026/08/wordpress-7-0-4-release/
Patchstack — analiza wydania 7.0.3 z zestawieniem autorstwa trzech ostatnich wydań, w tym informacją o znalezieniu łańcucha wp2shell przy pomocy modelu frontier w dziesięć godzin za około dwadzieścia pięć dolarów: https://patchstack.com/articles/wordpress-7-0-3-released-12-vulnerabilities-found-and-fixed/
pwn.ai — badanie XSS2Shell z opisem autonomicznego odkrycia oraz stwierdzeniem, że podatność była obecna od najwcześniejszych wersji WordPressa i została przeoczona przez wszystkie dotychczasowe audyty: https://pwn.ai/blog/xss2shell
pwn.ai — wcześniejsze badanie ImageMagicka z opisem sposobu pracy agenta oraz ustaleniem, że WordPress nie ustawia własnej polityki bezpieczeństwa dla tej biblioteki, a granice bezpieczeństwa ImageMagicka i Ghostscriptu nie uwzględniają siebie nawzajem: https://pwn.ai/blog/imagemagick-from-arbitrary-file-read-to-rce-in-every-policy-zeroday



































































































































































































































Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł