WordPress 7.0.3: dwanaście luk w jednym wydaniu, trzy tygodnie po wp2shell

6 sierpnia 2026 ukazał się WordPress 7.0.3. To wydanie wyłącznie bezpieczeństwa, które łata dwanaście podatności naraz, od XSS-a na ekranie logowania po podniesienie uprawnień w sieciach multisite. Poprawki cofnięto aż do wersji 4.7, więc obejmują prawie dziesięć lat wydań WordPressa. Trzy tygodnie wcześniej pisaliśmy o krytycznej luce wp2shell, przy której CERT Polska ostrzegał przed masowym atakiem. I tu jest sedno: to nie jest ta sama sytuacja, a różnicę warto zrozumieć, zanim ktoś Cię nastraszy.

Co dokładnie naprawiono

Dwanaście podatności to dużo jak na jedno wydanie, ale nie wszystkie ważą tyle samo. Najkrócej:

• jeden XSS na ekranie logowania, wykonalny bez posiadania konta,
• cztery przypadki trwałego XSS wymagające konta na poziomie współautora lub wyżej (bloki treści wpisu i daty, ustawienia emoji, szybka edycja),
• podniesienie uprawnień w multisite przy włączonej rejestracji użytkowników,
• trzy wycieki informacji: blok najnowszych komentarzy pokazywał komentarze z wpisów chronionych hasłem, dało się wyliczać adresy wpisów, a kanały komentarzy ujawniały prywatne notatki,
• wstrzyknięcie CSS przez obejście filtra bezpiecznych stylów,
• obejście potwierdzenia adresu e-mail,
• SSRF przy walidacji adresów URL, pozwalający kierować żądania do adresów lokalnych.

Najpoważniejsza luka i dlaczego to nie jest drugi wp2shell

Uwaga skupiła się na pierwszej pozycji z listy, czyli XSS-ie na ekranie logowania. Dostał identyfikator CVE-2026-64638 i ocenę 8.9 na 10, a więc poziom wysoki. WordPress opisuje go jako podatność, którą w sprzyjających okolicznościach da się rozwinąć do zdalnego wykonania kodu.

I tu potrzebne jest jedno zdanie, którego zwykle brakuje w obecnych nagłówkach. Fakt, że atakujący nie musi mieć konta, nie oznacza, że przejmie Twoją stronę sam z siebie. Do wykorzystania tej luki potrzebna jest udana socjotechnika: administrator musi dać się namówić na wejście na spreparowaną stronę napastnika i wykonać na niej konkretną czynność. Tak opisuje to samo repozytorium bezpieczeństwa WordPressa i tak podkreśla Search Engine Journal, wprost odróżniając ten przypadek od wp2shell.

Różnica jest rzekłbym fundamentalna. W lipcu mieliśmy nieuwierzytelnione zdalne wykonanie kodu na domyślnej instalacji, gotowy exploit w sieci i ostrzeżenie CERT Polska przed masowym skanowaniem. Atak szedł hurtem, na wszystko, co stało w zagrożonej wersji. Teraz mamy poważną lukę, która wymaga, żeby ktoś celowo wziął Cię na cel i żebyś dał się nabrać. To nadal jest powód, żeby zaktualizować stronę dziś, a nie w weekend. Więc to nie jest powód do paniki.

Ciekawostka: a jedno ze zgłoszeń przyszło od Anthropic

W podziękowaniach dla zgłaszających, obok zespołów bezpieczeństwa i badaczy z HackerOne, figuruje Anthropic, czyli firma stojąca za Claude’em. Zgłosiła wstrzyknięcie CSS przez obejście filtra bezpiecznych stylów.

To drobiazg, który dobrze pokazuje, dokąd zmierza cały rynek. Bezpieczeństwem WordPressa zajmuje się dziś nie tylko garstka wyspecjalizowanych badaczy, ale też firmy budujące modele językowe, które przy okazji przeczesywania kodu potrafią wyłapać błędy w rdzeniu. Kod otwarty zyskuje nową kategorię recenzentów, a tempo zgłoszeń będzie rosło.

Kogo to dotyczy

Praktycznie każdego, kto nie jest na najnowszej wersji. Poprawki objęły wszystkie gałęzie od 4.7.0 do 7.0.2, czyli prawie dekadę wydań. Jeśli Twoja strona stoi na wersji starszej niż 7.0.3 i nie dostała odpowiedniej łatki na swojej gałęzi, jest w grupie zagrożonej.

Sprawdzisz to w kilkanaście sekund: Kokpit, Aktualizacje w panelu WordPressa. Numer wersji jest na górze ekranu.

Co zrobić teraz

1. Sprawdź wersję i zaktualizuj. Jeśli widzisz 7.0.3, jesteś bezpieczny i możesz przestać czytać. Jeśli nie, kliknij aktualizację, zajmie to minutę.

2. Sprawdź, czy strona nie aktualizuje się już sama. Wydania bezpieczeństwa takie jak to instalują się automatycznie na witrynach, które mają włączone aktualizacje w tle. Ogłoszenie 7.0.3 mówi wprost, że takie strony zaczną się aktualizować same. Sporo osób jest już zaktualizowanych i o tym nie wie, a sporo ma ten mechanizm wyłączony i też o tym nie wie.

3. Zrób to raz, a porządnie. To drugie zdarzenie bezpieczeństwa w WordPressie w ciągu trzech tygodni i na pewno nie ostatnie. Zamiast za każdym razem czytać newsy i biec do panelu, włącz automatyczne aktualizacje rdzenia, wtyczek i motywów. Rozpisaliśmy to krok po kroku, razem z drugą drogą prosto z panelu hostingu, która przy okazji robi kopię zapasową przed aktualizacją: Jak włączyć automatyczne aktualizacje w WordPress.

Jeśli nie chcesz pilnować tego samodzielnie, na hostingu pod WordPressa aktualizacje i kopie zapasowe ustawisz raz z poziomu panelu. A jeśli wolisz mieć nad tym pełną kontrolę i własne środowisko, sprawdź serwery VPS z administracją.