WordPress 7.0.2, 7.0.3 i 7.0.4 – co łatają te aktualizacje i co masz zrobić

Krótka wersja: tak, wszystkie trzy aktualizacje są prawdziwe i wszystkie są wydaniami bezpieczeństwa. WordPress 7.0.2 wyszedł 17 lipca 2026 i załatał dwie podatności, które w połączeniu dawały wykonanie kodu na czystej instalacji bez logowania. WordPress 7.0.3 wyszedł 6 sierpnia i załatał dwanaście kolejnych, w tym XSS na ekranie logowania działający przed zalogowaniem. WordPress 7.0.4 wyszedł 12 sierpnia i załatał jedną, za to poważną: zdalne wykonanie kodu przez wgrany plik.

Masz włączone automatyczne aktualizacje rdzenia? Prawdopodobnie siedzisz już na 7.0.4 i wystarczy to sprawdzić. Minuta roboty. Jeśli ktoś kiedyś wyłączył auto-update „żeby nic samo się nie zepsuło”, to jest ten moment, żeby zajrzeć.

I jedna rzecz na starcie, bo w sieci jest sporo paniki: nie każda z tych dwunastu dziur dotyczy Twojej strony. Większość wymaga konta w systemie albo multisite. Poniżej rozdzielamy to na czynniki pierwsze.

Oś czasu – co się właściwie wydarzyło

Data	Wersja	Typ	Co załatano
20.05.2026	7.0	wydanie główne	nowa gałąź
09.07.2026	7.0.1	utrzymaniowe	poprawki błędów
17.07.2026	7.0.2	bezpieczeństwa	2 podatności, łańcuch pre-auth RCE
06.08.2026	7.0.3	bezpieczeństwa	12 podatności
12.08.2026	7.0.4	bezpieczeństwa	1 podatność, zdalne wykonanie kodu przez upload

Trzy wydania bezpieczeństwa rdzenia w cztery tygodnie to nietypowo dużo. Dla porównania: w całym 2025 roku Patchstack odnotował w samym rdzeniu zaledwie 6 podatności, wszystkie niskiego priorytetu. Lato 2026 faktycznie odstaje od normy.

WordPress 7.0.2 – łańcuch WP2Shell

Wydanie z 17 lipca łatało dwie rzeczy:

• CVE-2026-60137 (GHSA-fpp7-x2x2-2mjf), SQL injection, severity krytyczna. Zgłosili TF1T, dtro i haongo.
• CVE-2026-63030 (GHSA-ff9f-jf42-662q), pomylenie tras w batchowym REST API plus SQL injection prowadzące do zdalnego wykonania kodu, severity wysoka. Zgłosił Adam Kues z Assetnote/Searchlight Cyber.

Osobno nieprzyjemne, razem groźne. Połączone w łańcuch, nazwany przez badaczy WP2Shell, dawały nieuwierzytelnione wykonanie kodu. Bez konta, bez wtyczek, na standardowej instalacji.

Podatne były wersje 6.8.0 do 6.8.5, 6.9.0 do 6.9.4 oraz 7.0.0 do 7.0.1. Wydania naprawcze: 6.8.6 (tylko pierwsza podatność), 6.9.5 (obie) i 7.0.2. Starsze niż 6.8 nie były podatne. Ze względu na skalę zespół WordPress.org uruchomił wymuszone aktualizacje przez system auto-update. To rzadki ruch i dobry wskaźnik, jak poważnie potraktowano sprawę.

To nie była teoria. Patchstack zaobserwował próby wykorzystania CVE-2026-63030 jeszcze tego samego dnia, kilka godzin po publikacji łatki. Honeypoty Hexastrike łapały ruch przez weekend, a w niedzielę trwały już pierwsze reakcje na incydenty.

WordPress 7.0.3 – dwanaście podatności, jedna naprawdę głośna

6 sierpnia przyszło wydanie z dwunastoma poprawkami. Oficjalna lista z dokumentacji wersji 7.0.3 wygląda tak:

Podatność	Kto może wykorzystać
Pre-auth reflected XSS na ekranie logowania, potencjalnie do wykonania kodu PHP	atakujący bez konta
Stored XSS w bloku Post Date	Contributor i wyżej
Stored XSS w bloku Post Content	Contributor i wyżej
Stored XSS przez element ustawień emoji	Contributor i wyżej
Stored XSS w Quick Edit na stronach z dużą liczbą użytkowników	Contributor i wyżej
CSS injection przez obejście filtra bezpiecznego CSS	Author i wyżej
Eskalacja uprawnień na multisite z otwartą rejestracją	zarejestrowany użytkownik multisite
Ujawnienie komentarzy z postów chronionych hasłem (blok Latest Comments)	dowolny odwiedzający
Obejście potwierdzania adresu e-mail	zależne od konfiguracji
SSRF w walidacji URL, żądania do zakresów link-local	zależne od konfiguracji
Ujawnienie notatek w kanałach komentarzy	dowolny odwiedzający
Enumeracja slugów postów	dowolny odwiedzający

Wszystkie zgłoszono odpowiedzialnie, między innymi przez pwn.ai, Aikido Security, Anthropic i HDWSec. Pełna lista jest w dokumentacji wydania.

XSS2Shell, czyli ta pierwsza pozycja

Pierwsza podatność dostała numer CVE-2026-64638, ocenę CVSS 8.9 w skali 4.0 i nazwę XSS2Shell. Warto wiedzieć, jak działa, bo od tego zależy, czy Twoja strona była realnie zagrożona.

Sam XSS wywołuje się banalnie: nieudana próba logowania ze spreparowaną nazwą użytkownika wstrzykuje kod na ekran wp-login.php. Bez żadnego konta. Podatne były wersje od 6.4 do 7.0.2.

Ale wstrzyknięcie skryptu to jeszcze nie przejęcie serwera. Po pierwsze, atak wymaga socjotechniki. Oficjalny wektor CVSS zawiera człon UI:A, czyli ofiara musi aktywnie coś zrobić: wejść w spreparowany link, zwykle podrzucony w phishingu. Sam atakujący nie odpali tego zdalnie na Twojej stronie.

Po drugie, pełny łańcuch do wykonania kodu PHP wymagał, żeby zbiegło się kilka warunków naraz: ofiarą musiał być zalogowany administrator instalacji jednostanowiskowej, na koncie musiały działać hasła aplikacji (Application Passwords), a serwer musiał pozwalać na wgranie wtyczki przez panel. Dopiero wtedy skrypt kradł hasło aplikacji, wgrywał wtyczkę z kodem i uruchamiał ją bezpośrednio.

Czyli: dziura realna i poważna, ale pełne przejęcie nie działało wszędzie i wymagało, żeby ktoś dał się nabrać na link. Na moment publikacji analiz technicznych nie było raportów o atakach na żywo z jej użyciem. To nie powód do zwłoki, tylko powód, żeby nie panikować.

Reszta listy

Sześć z dwunastu podatności wymaga konta w systemie: cztery na poziomie Contributor, jedna na poziomie Author, jedna na multisite z otwartą rejestracją. Prowadzisz stronę firmową, na której jesteś jedynym użytkownikiem? Te pozycje praktycznie Cię nie dotyczą. Masz bloga z zewnętrznymi autorami, sklep z kontami klientów albo multisite? Dotyczą bardzo.

Trzy kolejne to wycieki informacji dostępne dla dowolnego odwiedzającego (komentarze z postów chronionych hasłem, slugi postów, notatki w kanałach komentarzy). Nieprzyjemne, ale nie prowadzą do przejęcia strony. Dwie ostatnie, obejście potwierdzania e-maila i SSRF, zależą od konfiguracji serwera i wtyczek.

Backporty

Poprawki poszły też do starszych gałęzi, aż do 4.7. Wersja 6.9 była podatna na 11 z 12 dziur (łatka w 6.9.6), gałęzie od 6.8 do 5.8 na 8 z 12 (łatki w 6.8.7, 6.7.6, 6.6.6, 6.5.9, 6.4.9, 6.3.9, 6.2.10, 6.1.11, 6.0.13, 5.9.14 i 5.8.14), a od 5.7 do 4.7 na 7 z 12. WordPress 4.6 i starsze nie dostają już nic.

Siedzisz na WordPressie 4.x albo 5.x? Backport gasi ten konkretny pożar, ale nadal jesteś kilka lat za obsługiwaną wersją. To temat na osobną rozmowę.

WordPress 7.0.4 – jedna podatność, za to groźna

12 sierpnia przyszło trzecie wydanie bezpieczeństwa w tej serii. Tym razem chodzi o jedną rzecz, opisaną jako uwierzytelnione zdalne wykonanie kodu przez wgranie złośliwego pliku. Numer to CVE-2026-65640 (GHSA-8vr3-7mxf-gx8w), a zgłosił ją zespół pwn.ai, ten sam, który miesiąc wcześniej znalazł XSS2Shell.

Dwa warunki muszą zajść naraz, żeby to zadziałało, i warto je znać, zanim wpadniesz w panikę albo ją zlekceważysz.

Po pierwsze, atakujący musi mieć konto na poziomie Author lub wyżej. Autor może wgrywać pliki do biblioteki mediów i to jest wektor. Prowadzisz stronę firmową, gdzie jedynym użytkownikiem jesteś Ty? Ryzyko jest minimalne. Masz bloga z zewnętrznymi autorami, sklep z kontami klientów podniesionymi do Author albo portal z rejestracją? Sprawa wygląda inaczej.

Po drugie, serwer musi używać Imagick z Ghostscriptem do przetwarzania obrazów. To kombinacja spotykana głównie tam, gdzie strona obsługuje pliki PDF albo bardziej egzotyczne formaty graficzne. Jeśli hosting korzysta z GD zamiast Imagicka, ten konkretny wektor Cię nie dotyczy.

Nie znaczy to jednak, że można odpuścić aktualizację. Nie każdy wie, co dokładnie ma zainstalowane na serwerze, a konfiguracja hostingu potrafi się zmienić bez uprzedzenia. Sprawdzisz to w Narzędzia, Stan witryny, Informacje, w sekcji o obsłudze mediów.

Poprawka poszła backportem aż do gałęzi 4.7, więc starsze instalacje też ją dostały. Wydaniem kierował John Blackbourn, przy wsparciu Dennisa Snella i Jeremy’ego Felta.

Checklista – co zrobić w 10 minut

1. Sprawdź wersję. W panelu przejdź do Kokpit, potem Aktualizacje. Numer widać też w stopce panelu. Jeśli widzisz 7.0.4, jesteś na bieżąco.
2. Albo przez WP-CLI. Masz SSH? Jedna komenda: wp core version.
3. Albo z pliku. Otwórz wp-includes/version.php i znajdź zmienną $wp_version. To źródło prawdy, gdy panel nie działa.
4. Zrób kopię zapasową. Pliki i baza. Jeśli aktualizacja coś zepsuje, wracasz w pięć minut zamiast w pięć godzin.
5. Zaktualizuj. Kliknij aktualizację rdzenia w panelu. Przez WP-CLI: wp core update, zaraz potem wp core update-db.
6. Sprawdź, czy strona żyje. Strona główna, jedna podstrona, formularz kontaktowy, koszyk jeśli masz sklep. Zaloguj się i wyloguj.
7. Przejrzyj listę użytkowników. Konta administratora, których nie zakładałeś, to pierwszy sygnał, że ktoś zdążył przed Tobą.
8. Zaktualizuj wtyczki i motyw. Bo to one są prawdziwym problemem, o czym za chwilę.

Uwaga – sklep i strona z aktywnym ruchem

Prowadzisz WooCommerce albo stronę, na której coś dzieje się w tle (subskrypcje, integracje, płatności)? Nie klikaj aktualizacji w środku dnia. Zrób to w oknie najmniejszego ruchu i miej kopię pod ręką. Wydania bezpieczeństwa rzadko psują rzeczy, ale rzadko to nie nigdy.

Auto-update jest wyłączony? Sprawdź wp-config.php

Domyślnie istniejące instalacje dostają wydania pomniejsze i bezpieczeństwa automatycznie, a świeże instalacje od wersji 5.6 także wydania główne. Problem w tym, że wiele stron ma to wyłączone, bo ktoś kiedyś tak ustawił.

W pliku wp-config.php szukaj dwóch stałych:

// Steruje aktualizacjami rdzenia
define( 'WP_AUTO_UPDATE_CORE', true );   // wszystko: dev, minor, major
define( 'WP_AUTO_UPDATE_CORE', 'minor' ); // tylko pomniejsze i bezpieczeństwa
define( 'WP_AUTO_UPDATE_CORE', false );  // nic, wszystko ręcznie

// Wyłącza WSZYSTKIE automatyczne aktualizacje, także wtyczek i motywów
define( 'AUTOMATIC_UPDATER_DISABLED', true );

Znajdziesz false albo AUTOMATIC_UPDATER_DISABLED na true? Masz powód, dla którego strona siedzi na starej wersji. Dokumentacja WordPressa jest jednoznaczna: wyłączanie automatycznych aktualizacji bezpieczeństwa jest odradzane.

Rozsądny kompromis dla produkcji to 'minor'. Łatki lecą automatycznie, a wydania główne (te, które potrafią coś zepsuć) kontrolujesz ręcznie. Sprawdź jeszcze, czy wtyczka bezpieczeństwa albo panel hostingu nie blokuje aktualizacji niezależnie od wp-config.php.

Dlaczego same aktualizacje rdzenia to za mało

Tu jest najważniejsza część tego wpisu, choć nie ta, którą wypychają nagłówki.

Dane Patchstack za 2025 rok: 91% wykrytych podatności w ekosystemie WordPressa dotyczyło wtyczek, 9% motywów. Rdzeń? Sześć podatności, wszystkie niskiego priorytetu. Łącznie odnotowano wtedy 11 334 nowe podatności, o 42% więcej niż rok wcześniej, z czego 1 966 (17%) o wysokiej ocenie severity.

Jeśli aktualizujesz tylko rdzeń, pilnujesz kilku procent powierzchni ataku i zostawiasz otwarte pozostałe dziewięćdziesiąt kilka.

Do tego dochodzi tempo. Ważona mediana czasu od ujawnienia podatności do pierwszej próby jej wykorzystania wynosi według Patchstack 5 godzin. Około połowy podatności o wysokim wpływie jest atakowana w ciągu doby. Dokładnie to widzieliśmy przy lipcowym WP2Shell: łatka rano, exploity wieczorem tego samego dnia.

Praktyczny wniosek jest nudny i dlatego działa:

• Aktualizuj wtyczki i motyw równie regularnie co rdzeń, nie raz na kwartał.
• Usuwaj wtyczki, których nie używasz. Nieaktywna wtyczka z dziurą to nadal pliki na serwerze.
• Ogranicz konta Contributor i wyżej do osób, które ich naprawdę potrzebują. Połowa podatności z 7.0.3 wymagała właśnie takiego konta.
• Trzymaj działający backup i sprawdź kiedyś, czy da się z niego odtworzyć stronę.
• Miej alert, gdy coś się nie zaktualizuje. Sama możliwość auto-update nie znaczy, że auto-update zadziałał.

Scenariusz, w którym się nie zdążyło, opisaliśmy w dwóch wpisach z pola: poradnik po włamaniu oraz jak wygląda zaawansowana infekcja sklepu. Czyszczenie zainfekowanej strony kosztuje wielokrotnie więcej niż kliknięcie aktualizacji.

Co dalej

Nie wiesz, na jakiej wersji siedzi Twoja strona ani kiedy ostatnio robiono kopię zapasową? To nie problem WordPressa. To problem procesu.

Robimy opiekę nad WordPressem po to, żeby wydania jak 7.0.2 i 7.0.3 były dla właściciela strony niewidoczne. Aktualizacja idzie, backup jest, ktoś to sprawdza. Osobno opisaliśmy, co obejmuje opieka nad stroną.

A jeśli podejrzewasz, że coś już się wydarzyło, zacznij od audytu strony albo odezwij się. Zerkniemy i powiemy wprost, co widzimy.

FAQ

Czy WordPress 7.0.4 aktualizuje się sam?

Zwykle tak, bo wydania pomniejsze i bezpieczeństwa domyślnie instalują się automatycznie. Ale jeśli ktoś ustawił WP_AUTO_UPDATE_CORE na false albo włączył AUTOMATIC_UPDATER_DISABLED, aktualizacja nie przyjdzie. Sprawdź wersję ręcznie, zamiast zakładać.

Jak sprawdzić, jaką mam wersję WordPressa?

Najszybciej w panelu: Kokpit, potem Aktualizacje. Numer widać też w stopce panelu. Przez WP-CLI wystarczy wp core version. Bez panelu sprawdź zmienną $wp_version w pliku wp-includes/version.php.

Mam WordPressa 6.9, muszę przechodzić na 7.0.4?

Nie musisz przeskakiwać gałęzi. Poprawki wyszły też dla 6.9 (wersja 6.9.6) i 6.8 (wersja 6.8.7), a nawet dla starszych aż do 4.7, i to samo dotyczy łatki z 7.0.4. Ale aktywnie wspierana jest tylko najnowsza wersja, więc przejście na 7.0.x to kwestia czasu.

Czy moja strona została zaatakowana przez te dziury?

Podatności z 7.0.2 wykorzystywano w ciągu godzin od ujawnienia, więc strony niezaktualizowane w lipcu były realnie zagrożone. Sprawdź listę użytkowników, daty modyfikacji plików i logi serwera. Konta administratora, których nie zakładałeś, traktuj jako incydent.

Czy XSS2Shell (CVE-2026-64638) działa na każdej stronie?

Sam XSS na ekranie logowania działał na wersjach od 6.4 do 7.0.2. Ale pełne wykonanie kodu PHP wymagało zalogowanego administratora, aktywnych haseł aplikacji i możliwości wgrania wtyczki. Nie każda instalacja spełniała te warunki naraz.

Co zrobić, jeśli aktualizacja zepsuła stronę?

Przywróć kopię zapasową, potem zaktualizuj na kopii testowej i znajdź wtyczkę, która gryzie się z nową wersją rdzenia. Nie zostawiaj strony na starej, podatnej wersji jako „rozwiązania” problemu z kompatybilnością.

Czy podatność z 7.0.4 dotyczy mojej strony?

Tylko jeśli zachodzą dwa warunki naraz: ktoś ma u Ciebie konto na poziomie Author lub wyżej, a serwer używa Imagick z Ghostscriptem do przetwarzania obrazów. Przy stronie firmowej z jednym użytkownikiem ryzyko jest minimalne. Sprawdzisz konfigurację w Narzędziach, w Stanu witryny.

Czy wystarczy aktualizować sam WordPress?

Nie. W 2025 roku 91% podatności w ekosystemie dotyczyło wtyczek, a 9% motywów. Rdzeń to margines. Aktualizacja samego WordPressa daje złudne poczucie bezpieczeństwa, jeśli obok siedzi wtyczka bez wsparcia od dwóch lat.

Jak często sprawdzać aktualizacje?

Przy medianie 5 godzin od ujawnienia podatności do pierwszych prób ataku raz w miesiącu to za rzadko. Sensowne minimum to włączone automatyczne aktualizacje bezpieczeństwa plus cotygodniowy przegląd wtyczek.