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

Jeśli prowadzisz stronę lub sklep na [WordPressie](https://jaworowi.cz/wordpress-cms-19518.php), 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

- Zaloguj się do kokpitu i sprawdź wersję w **Kokpit → Aktualizacje**.

- 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.

- Zanim klikniesz „Aktualizuj”, zrób kopię zapasową plików i bazy.

- Po aktualizacji sprawdź, czy strona działa, i przejdź przez listę sygnałów kompromitacji z punktu 7.

- **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.

CVECVSSCo to za lukaKto zgłosiłCVE-2026-601377.5 (wysoka)SQL Injection bez logowania. Intruz może wstrzykiwać zapytania do bazy danych.Tin Pham (TF1T), Trong Pham (dtro), haongoCVE-2026-630309.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ą?

Jeśli zapamiętasz z tego tekstu jedną rzecz, niech będzie to: jednym kliknięciem atakujący może pobrać całą zawartość Twojej strony i dowolnie ją zmodyfikować.

 ![definicja wiedza](https://cdn.jaworowi.cz/wp-content/uploads/2024/02/owl-3.png)

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 wersjaCo zrobićUwagi7.0 albo 7.0.1Aktualizuj do 7.0.2Obie luki6.9.x (do 6.9.4)Aktualizuj do 6.9.5Obie luki6.8.x (do 6.8.5)Aktualizuj do 6.8.6Tylko pierwsza luka, ale wciąż zrób7.1 beta/beta2 (RC)Zaktualizuj do najnowszej RCObie luki6.7.x i starszeNie są podatne na te konkretne lukiLepiej 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)

- Zrób kopię zapasową plików i bazy.

- Wejdź w **Kokpit → Aktualizacje**.

- Kliknij **Zaktualizuj WordPressa**.

- 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:

- Nowi nieznani użytkownicy w **Użytkownicy → Wszyscy użytkownicy**. Szczególnie z rolą Administrator albo z dziwnym mailem.

- Nowe, nieznane wtyczki w **Wtyczki → Zainstalowane**. Często nazywają się czymś w stylu „WP Helpers”, „System Tools” albo mają randomowe ciągi znaków.

- `wp core verify-checksums` zwraca błędy. Pliki rdzenia zostały zmodyfikowane.

- Pliki `.php` w katalogu `wp-content/uploads/`. WordPress nigdy nie trzyma tam plików wykonywalnych. Każdy `.php` w `uploads/` to podejrzenie backdoora.

- Nietypowe wpisy w `.htaccess` albo `wp-config.php`. Ukryte reguły przepisywania, `eval(base64_decode(...))`, dziwne `define()`.

- Nagłe skoki zużycia CPU albo transferu w statystykach hostingu z ostatnich dni.

- Wyszukiwarka Google pokazuje Twoją stronę z dziwnymi frazami (japońskie znaki, „buy viagra”, apteki). To klasyczny atak Japanese keyword hack.

- 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.

/

**Więcej informacji:**

- [WordPress 7.0.2 Release, wordpress.org](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/) (oficjalny komunikat)

- [WordPress 7.0.2 Security Release, WP VIP Customer Hub](https://customerhub.wpvip.com/lobby/2026/07/17/wordpress-7-0-2-security-release/)

- [WordPress 7.0.2 Security Release: Why You Should Update Now, SysopGuy](https://www.sysopguy.com/wordpress-7-0-2-security-release-why-you-should-update-now/)

- [GHSA-fpp7-x2x2-2mjf oraz GHSA-ff9f-jf42-662q, GitHub Security Advisory](https://github.com/WordPress/wordpress-develop/security/advisories)