WordPress 7.0.2: pilna aktualizacja bezpieczeństwa, której nie wolno odkładać

Jeśli prowadzisz stronę lub sklep na WordPressie, przerwij na chwilę to, co robisz, i sprawdź, jaką masz wersję. 17 lipca 2026 wypuszczono WordPressa 7.0.2, aktualizację bezpieczeństwa, ktróe zamyka dwie luki, w tym jedną krytyczną. Taką, która pozwala komuś z zewnątrz przejąć kontrolę nad Twoją witryną bez hasła i bez logowania.

To nie jest kolejna aktualizacja „poprawiająca drobne błędy”. Tym razem stawką jest pełny dostęp do Twoich plików, bazy danych i serwera.

W tekście pokazuję konkrety: jakie to luki, co akatkujący może zrobić, jak sprawdzić, czy dotyczy to Ciebie, jak się zaktualizować, a na końcu tego, czego nie znajdziesz w większości innych artykułów, czyli jak sprawdzić, czy strona nie została już zhakowana, zanim zdążyłeś to przeczytać.

TL;DR: co masz zrobić w tej chwili

1. Zaloguj się do kokpitu i sprawdź wersję w Kokpit → Aktualizacje.
2. Jeśli masz 7.0, 7.0.1, 6.9.x (do 6.9.4) albo 6.8.x (do 6.8.5), aktualizuj natychmiast.
3. Zanim klikniesz „Aktualizuj”, zrób kopię zapasową plików i bazy.
4. Po aktualizacji sprawdź, czy strona działa, i przejdź przez listę sygnałów kompromitacji z punktu 7.
5. Nie czekaj. Atakujący może jednym kliknięciem pobrać całą zawartość Twojej strony: bazę klientów, zamówienia, treści, pliki. A potem ją dowolnie zmienić, ukryć w niej własny dostęp albo po prostu skasować.

WordPress uruchomił wymuszone aktualizacje automatyczne dla całej gałęzi 7.0. W teorii wiele stron zaktualizowało się samo. W praktyce, o tym za chwilę, ufanie auto-aktualizacji bez weryfikacji bywa pułapką.

Konkret: dwie luki z numerami CVE

Zwykle komunikaty WordPressa mówią ogólnikowo o „uwierzytelnianiu” albo „walidacji danych”. Tym razem dostajemy twarde dane.

CVE	CVSS	Co to za luka	Kto zgłosił
CVE-2026-60137	7.5 (wysoka)	SQL Injection bez logowania. Intruz może wstrzykiwać zapytania do bazy danych.	Tin Pham (TF1T), Trong Pham (dtro), haongo
CVE-2026-63030	9.8 (krytyczna)	Luka w REST API, tzw. batch-route confusion, którą można spiąć z SQL Injection w łańcuch prowadzący do zdalnego wykonania kodu (RCE).	Adam Kues (Assetnote / Searchlight Cyber)

Drugiej z nich nie da się przecenić. CVSS 9.8 to blisko maksimum skali.

Co haker może faktycznie zrobić z Twoją stroną?

Oznacza to dosłownie: baza klientów, historia zamówień, maile, treści wpisów i stron, media, pliki konfiguracyjne. Wszystko ląduje na dysku kogoś, kogo nigdy nie wpuszczałeś na stronę. A to dopiero początek. Mając pełny dostęp, intruz może w kilka minut dodać własne konto administratora, którego nie zauważysz, dopóki go nie poszukasz. Może wgrać złośliwy kod do motywu albo wtyczki, podmienić treść strony na własną, ustawić przekierowania dla Twoich klientów albo, jeśli zechce po prostu zaszkodzić, skasować wszystko do zera. Wg mnie to nie jest scenariusz z filmu. To standardowy scenariusz włamań, które widać na zainfekowanych WordPressach codziennie.

Luki w WordPressie często brzmią strasznie w nagłówkach, ale w praktyce wymagają konta albo wtyczki albo specyficznej konfiguracji. Nie tym razem.

Obie podatności są nieautoryzowane. Atakujący nie potrzebuje konta na Twojej stronie, nie potrzebuje hasła, nie potrzebuje wtyczki. Wystarczy, że strona jest włączona i dostępna z internetu.

Co może się stać, gdy połączy się obie luki w łańcuch:

• Wyciągnięcie bazy danych. SQL Injection daje dostęp do tabel: danych klientów, haseł (nawet zahashowanych), zamówień, maili.
• Utworzenie konta administratora. Atakujący może dodać nowego usera z uprawnieniami super-admina, którego nie zauważysz, dopóki go nie poszukasz.
• Modyfikacja treści i plików. Wstrzyknięcie przekierowań, ukrytych linków SEO, złośliwego kodu w stopce.
• Pełne przejęcie serwera (RCE). Końcowy efekt łańcucha. Intruz wgrywa własne pliki PHP, zakłada backdoor, a Twoja strona staje się częścią botnetu albo służy do ataków na innych.

WordPress jest najpopularniejszym systemem CMS na świecie. W ciągu pierwszych godzin po ogłoszeniu skanery masowo przeszukują internet w poszukiwaniu niezaktualizowanych instalacji. Nie musisz być znaną marką ani mieć dużego ruchu, żeby trafić na listę.

Czy ta luka dotyczy właśnie Ciebie?

Tak, jeśli używasz którejś z gałęzi poniżej. Poprawki backportowano do dwóch starszych linii, ale są różnice:

Twoja wersja	Co zrobić	Uwagi
7.0 albo 7.0.1	Aktualizuj do 7.0.2	Obie luki
6.9.x (do 6.9.4)	Aktualizuj do 6.9.5	Obie luki
6.8.x (do 6.8.5)	Aktualizuj do 6.8.6	Tylko pierwsza luka, ale wciąż zrób
7.1 beta/beta2 (RC)	Zaktualizuj do najnowszej RC	Obie luki
6.7.x i starsze	Nie są podatne na te konkretne luki	Lepiej nie zostawaj na starej wersji, zaplanuj migrację

Wersję sprawdzisz w Kokpit → Aktualizacje albo w stopce kokpitu, w prawym dolnym rogu. Jeśli masz hosting z panelem (DirectAdmin, cPanel, Installatron), zobaczysz ją tam.

Ważne: gałąź 6.8 dostała łatkę tylko na jedną z dwóch luk. Jeśli jesteś na 6.8, najrozsądniej przeskoczyć od razu na 7.0.2, zamiast zatrzymywać się na 6.8.6.

Przecież WordPress aktualizuje się sam. Dlaczego to za mało?

WordPress ma mechanizm aktualizacji w tle, tzw. background updates. Przy release bezpieczeństwa w gałęzi 7.0 zespół uruchomił awaryjne wymuszenie aktualizacji. Brzmi świetnie, ale wpraktyce polecam trzymać rękę na pulsie, bo auto-aktualizacja potrafi nie zadziałać w kilkunastu realnych scenariuszach:

• Hosting blokuje zapis plików. Niektórzy dostawcy trzymają pliki WordPressa jako read-only albo zablokowane dla procesu PHP.
• Stała DISALLOW_FILE_MODS w wp-config.php. Popularna u programistów. Wyłącza aktualizacje rdzenia i wtyczek z poziomu panelu.
• Deployment z Gita, kontener, Docker, custom pipeline. Wtedy pliki nadpisuje repozytorium, a auto-update nic nie zrobi albo zostanie cofnięty przy kolejnym deploymencie.
• FS_METHOD ustawione na ftpext z błędnymi danymi. Aktualizacja po prostu po cichu nie przejdzie.
• Modyfikacje rdzenia. Niektórzy klienci trzymają zmiany w plikach wp-includes/ albo wp-admin/. WordPress może odmówić nadpisania.
• Cron wyłączony albo zablokowany przez hosting. Auto-update opiera się o wp-cron.php. Wielu hostingodawców blokuje go domyślnie „dla wydajności”.
• Wersja bardzo stara. WordPress nie zawsze potrafi zaktualizować kilka głównych wersji naraz w tle.

Dlatego reguła jest prosta. Auto-update niech będzie dla Ciebie zabezpieczeniem awaryjnym. Główny plan to zawsze własnoręczne sprawdzenie wersji po release krytycznym.

Aktualizacja krok po kroku

1. Przez kokpit (najprostsza)

1. Zrób kopię zapasową plików i bazy.
2. Wejdź w Kokpit → Aktualizacje.
3. Kliknij Zaktualizuj WordPressa.
4. Poczekaj około 30 sekund i zaloguj się ponownie.

2. Przez WP-CLI (jeśli masz SSH)

wp core update
wp core verify-checksums

Druga komenda jest kluczowa. Weryfikuje, czy pliki rdzenia zgadzają się z oficjalnymi sumami kontrolnymi. Jeśli coś zostało podmienione przez włamywacza wcześniej, verify-checksums to wyłapie.

3. Ręcznie przez FTP/SFTP (gdy panel nie działa)

Pobierz paczkę z wordpress.org/download/, rozpakuj, wgraj katalogi wp-admin/ i wp-includes/ oraz zawartość wp-content/, ale nie nadpisuj wp-content/ w całości, bo masz tam swoje wtyczki, motyw i uploady. Następnie odwiedź /wp-admin/, żeby WordPress zrobił upgrade bazy.

Kopia zapasowa przed aktualizacją to nie opcja. Wystarczy konflikt z jedną wtyczką, żeby po aktualizacji zobaczyć biały ekran. Pełny backup plików i bazy, zrobiony przed kliknięciem „Aktualizuj”, pozwala wrócić w 5 minut.

Zanim klikniesz „Aktualizuj”, sprawdź, czy nie jest już za późno

To sekcja, której rzadko szukasz w typowych poradnikach, a jest najważniejsza. Luka była publicznie znana od chwili ogłoszenia 17 lipca, ale mogła być aktywnie wykorzystywana wcześniej, jako tzw. 0-day. Jeśli Twoja strona była online w dniach albo tygodniach przed wydaniem 7.0.2, masz realną szansę, że ktoś Cię już odwiedził.

Szybki test kompromitacji. Rzeczy, które możesz sprawdzić sam:

1. Nowi nieznani użytkownicy w Użytkownicy → Wszyscy użytkownicy. Szczególnie z rolą Administrator albo z dziwnym mailem.
2. Nowe, nieznane wtyczki w Wtyczki → Zainstalowane. Często nazywają się czymś w stylu „WP Helpers”, „System Tools” albo mają randomowe ciągi znaków.
3. wp core verify-checksums zwraca błędy. Pliki rdzenia zostały zmodyfikowane.
4. Pliki .php w katalogu wp-content/uploads/. WordPress nigdy nie trzyma tam plików wykonywalnych. Każdy .php w uploads/ to podejrzenie backdoora.
5. Nietypowe wpisy w .htaccess albo wp-config.php. Ukryte reguły przepisywania, eval(base64_decode(...)), dziwne define().
6. Nagłe skoki zużycia CPU albo transferu w statystykach hostingu z ostatnich dni.
7. Wyszukiwarka Google pokazuje Twoją stronę z dziwnymi frazami (japońskie znaki, „buy viagra”, apteki). To klasyczny atak Japanese keyword hack.
8. Mail z Google Search Console o zainfekowaniu strony albo ostrzeżenia o spamie w linkach zwrotnych.

Jeśli cokolwiek z tej listy pasuje, nie aktualizuj w ciemno. Najpierw skontaktuj się z kimś, kto zajmuje się czyszczeniem zainfekowanych WordPressów, zrobi to bezpieczniej niż samodzielne kombinowanie, a dopiero potem wgraj świeżą instalację.

Po aktualizacji: 60 sekund testów

Sama informacja „Aktualizacja zakończona” nie wystarczy. Otwórz stronę w trybie incognito i spawdź:

• stronę główną i 2 albo 3 najważniejsze podstrony (niech się załadują bez błędu 500),
• logowanie do panelu pod /wp-admin/,
• formularz kontaktowy, wyślij testowego maila,
• jeśli masz sklep (WooCommerce): koszyk, dodanie produktu, rozpoczęcie checkoutu, mail transakcyjny,
• wyszukiwarkę i menu,
• wersję mobilną,
• najważniejsze integracje (płatności, analityka, newsletter).

Jeśli coś się sypie, nie wracaj do starej, podatnej wersji WordPressa. Wyłącz kolejno wtyczki, aż znajdziesz winowajcę. Najczęściej to jakaś wtyczka nieaktualizowana od lat albo słabo napisany motyw premium z kafelkami.

Sama łatka to za mało. Co jeszcze warto mieć w głowie

Aktualizacja rdzenia zamyka te dwie luki, ale WordPress składa się z setek elementów i autorzy złośliwego kodu bardzo dobrze o tym wiedzą. Szybka lista sanity check:

• Wtyczki i motyw też muszą być aktualne. Najczęstszą drogą włamu do WordPressa nie jest core, tylko porzucona wtyczka.
• Usuń nieużywane wtyczki i motywy. Nawet wyłączone są zagrożeniem, bo ich pliki nadal leżą na serwerze.
• MFA dla konta administratora. Mniej istotne dla tej konkretnej luki, bo nie wymaga loginu, ale kluczowe dla pozostałych ataków na hasła.
• Hosting z izolacją. Jeśli masz kilka stron na jednym koncie, upewnij się, że są odizolowane (tzw. PHP user per site). W przeciwnym razie włam na jedną stronę oznacza włam na wszystkie.
• WAF (Cloudflare, Wordfence, Sucuri) jako warstwa dodatkowa. Nie zastąpi patcha, ale potrafi zablokować znane sygnatury ataków SQLi.
• Wyłącz xmlrpc.php oraz ekspozycję wp-config.php, jeśli nie używasz. Częste wektory w starszych instalacjach.

Nie czekaj

WordPress 7.0.2 to jedna z tych aktualizacji, których nie odkładamy na weekend. Dwie luki, z czego jedna krytyczna (CVSS 9.8), prowadząca do zdalnego wykonania kodu na serwerze. W tej kategorii problemów liczą się godziny.

Lista kontrolna w skrócie: zrób kopię, zaktualizuj, a potem zweryfikuj, czy strona działa i czy nie została zhakowana wcześniej. Auto-update potraktuj jako ciekawostkę.

Jeśli nie wiesz, jak to zrobić bezpiecznie, albo masz na stronie skomplikowaną konfigurację (własny deployment, dużo integracji, stary motyw premium), lepiej zlecić to komuś, kto aktualizuje WordPressy regularnie, niż kombinować na żywym organiźmie.

/