WordPress 7.0.2 łata dwie groźne podatności w rdzeniu

WordPress 7.0.2 to pilna aktualizacja bezpieczeństwa rdzenia systemu. Usuwa dwie podatności, które w określonych wersjach można połączyć w łańcuch prowadzący do Remote Code Execution (RCE), czyli potencjalnego wykonania kodu na serwerze. Jeśli utrzymujesz stronę, sklep lub portal oparty na WordPressie, sprawdź wersję i nie odkładaj aktualizacji.

Najważniejsze: WordPress 7.0.0 i 7.0.1 należy zaktualizować do 7.0.2. Dla starszych gałęzi udostępniono poprawki 6.9.5 oraz 6.8.6. Zespół WordPressa, ze względu na wagę problemu, uruchomił wymuszone aktualizacje automatyczne dla podatnych instalacji.

Co wydarzyło się w WordPressie 7.0.2?

17 lipca 2026 roku zespół WordPressa opublikował wersję 7.0.2. Oficjalny komunikat opisuje ją jako wydanie bezpieczeństwa usuwające jeden problem krytyczny i jeden wysokiej wagi.

Poprawki dotyczą rdzenia WordPressa, a nie pojedynczej wtyczki czy motywu. Oznacza to, że samo zaktualizowanie dodatków nie rozwiązuje problemu. Trzeba zainstalować bezpieczną wersję WordPress Core.

Dwie poprawione podatności to:

• CVE-2026-60137 — SQL injection związany z parametrem author__not_in w WP_Query;
• CVE-2026-63030 — niejednoznaczność obsługi tras w zbiorczych zapytaniach REST API, która w połączeniu z pierwszym błędem może prowadzić do RCE.

Krytyczny scenariusz nie wynika więc wyłącznie z jednego błędu. Powstaje wtedy, gdy atakujący może wykorzystać oba problemy jako łańcuch podatności.

Podatność 1: SQL injection w WP_Query — CVE-2026-60137

Pierwsza luka dotyczy parametru author__not_in używanego przez klasę WP_Query. Komponent ten odpowiada za budowanie zapytań pobierających wpisy, strony i inne treści z bazy danych WordPressa.

SQL injection oznacza, że nieprawidłowo obsłużona wartość może wpłynąć na zapytanie wysyłane do bazy. W praktyce skutki zależą od tego, czy strona, wtyczka albo integracja udostępnia atakującemu drogę do podatnego parametru.

Właśnie dlatego w nazwie komunikatu pojawia się określenie facilitated SQL injection. Nie oznacza ono, że każdą stronę można przejąć jednym prostym adresem URL. Oznacza jednak błąd w rdzeniu, który może stać się elementem znacznie poważniejszego ataku.

Advisory GitHub klasyfikuje samą lukę jako umiarkowaną. Nie należy jednak oceniać jej w oderwaniu od drugiej podatności: w WordPressie 6.9 i nowszym oba problemy mogą utworzyć krytyczny łańcuch.

Podatność 2: pomieszanie tras REST API i RCE — CVE-2026-63030

Drugi problem dotyczy zbiorczych zapytań WordPress REST API. Mechanizm batch pozwala przesłać kilka operacji w jednym żądaniu. Błąd w rozpoznawaniu i obsłudze tras mógł doprowadzić do sytuacji, w której żądanie było interpretowane w nieoczekiwanym kontekście.

Według oficjalnego advisory połączenie tego problemu z CVE-2026-60137 może prowadzić do Remote Code Execution. To jedna z najpoważniejszych klas podatności, ponieważ potencjalnie pozwala atakującemu wykonać kod na serwerze strony.

Możliwe konsekwencje skutecznego ataku obejmują między innymi:

• przejęcie kontroli nad witryną;
• dodanie złośliwego administratora;
• wstrzyknięcie malware lub przekierowań;
• kradzież danych z bazy;
• wykorzystanie serwera do dalszych ataków;
• podmianę treści i spam SEO;
• przestój sklepu lub serwisu firmowego.

Ilustracja upraszcza mechanizm: osobne słabości mogą mieć ograniczony zasięg, ale połączone w jeden łańcuch otwierają drogę do znacznie poważniejszego skutku. Aktualizacja przerywa ten łańcuch w rdzeniu systemu.

Które wersje WordPressa są podatne?

Zakres podatnych i poprawionych wersji wygląda następująco:

Używana wersja	CVE-2026-60137	CVE-2026-63030	Wersja z poprawką
WordPress 6.8.0–6.8.5	Tak	Nie	6.8.6
WordPress 6.9.0–6.9.4	Tak	Tak	6.9.5
WordPress 7.0.0–7.0.1	Tak	Tak	7.0.2
WordPress 7.1 Beta 1	Tak	Tak	7.1 Beta 2

Wersje wcześniejsze niż 6.8 nie są dotknięte tymi dwoma konkretnymi problemami. Nie oznacza to jednak, że stara, niewspierana instalacja jest bezpieczna. Może zawierać inne znane luki i nie powinna być traktowana jako alternatywa dla aktualizacji.

Jak bezpiecznie zaktualizować WordPressa?

W wielu instalacjach poprawka zostanie wdrożona automatycznie. Nie warto jednak zakładać, że proces zakończył się powodzeniem. Wersję trzeba sprawdzić.

1. Sprawdź aktualną wersję

W panelu administracyjnym przejdź do Kokpit → Aktualizacje. Informację o wersji znajdziesz również na ekranie „O WordPressie”.

Jeśli używasz WP-CLI, wykonaj:

wp core version

2. Wykonaj kopię zapasową

Przed ręczną aktualizacją przygotuj kopię bazy danych i plików. Najlepiej użyć migawki hostingu lub sprawdzonego systemu backupu, który pozwala szybko odtworzyć stronę.

Kopia nie powinna jednak stać się powodem wielodniowego odkładania poprawki. W przypadku tej aktualizacji czas ma znaczenie.

3. Zainstaluj poprawioną wersję

Najlepszym wyborem jest przejście na aktualną, wspieraną wersję WordPress 7.0.2, o ile środowisko i używane rozszerzenia są z nią zgodne.

Jeżeli krytyczna integracja chwilowo uniemożliwia zmianę gałęzi, zainstaluj co najmniej poprawkę bezpieczeństwa dla używanej serii:

• WordPress 7.0.x → 7.0.2;
• WordPress 6.9.x → 6.9.5;
• WordPress 6.8.x → 6.8.6.

Aktualizację można wykonać z panelu lub przez WP-CLI:

wp core update
wp core update-db
wp core verify-checksums

Ostatnie polecenie porównuje pliki rdzenia z oficjalnymi sumami kontrolnymi. Nie sprawdza ono wtyczek, motywów ani katalogu uploads, ale pomaga wykryć nieoczekiwane zmiany w WordPress Core.

4. Sprawdź stronę po aktualizacji

Po instalacji poprawki wykonaj krótki test najważniejszych funkcji:

• otwórz stronę główną i kilka podstron;
• sprawdź logowanie oraz panel administratora;
• przetestuj formularze, koszyk i płatności;
• wyczyść cache aplikacji, serwera i CDN;
• przejrzyj logi błędów PHP oraz odpowiedzi REST API;
• potwierdź, że backup i monitoring nadal działają.

Aktualizacja była automatyczna — czy trzeba coś jeszcze zrobić?

Tak. Wymuszona aktualizacja automatyczna zmniejsza skalę ryzyka, ale nie daje gwarancji, że na każdej instalacji zakończyła się poprawnie. Proces może zatrzymać brak miejsca, błędne uprawnienia plików, niestandardowa konfiguracja albo wyłączone aktualizacje w tle.

Po automatycznej aktualizacji:

1. potwierdź numer wersji;
2. sprawdź, czy strona działa poprawnie;
3. przejrzyj konta z rolą administratora;
4. zweryfikuj integralność plików rdzenia;
5. sprawdź logi pod kątem nietypowych żądań i zmian sprzed aktualizacji.

Firewall aplikacyjny i CDN mogą ograniczać część prób ataku, ale nie zastępują poprawki w kodzie. Traktuj je jako dodatkową warstwę ochrony.

Co zrobić, jeśli podejrzewasz wcześniejsze włamanie?

Sama aktualizacja usuwa podatność, ale nie usuwa skutków ataku, do którego doszło wcześniej. Jeśli widzisz nowe konta administratorów, nieznane pliki, przekierowania, spam w wynikach wyszukiwania albo nietypowy ruch wychodzący, potraktuj sytuację jak incydent.

W takiej sytuacji:

• zachowaj logi i wykonaj kopię środowiska do analizy;
• ogranicz publiczny dostęp do serwisu, jeśli jest to możliwe biznesowo;
• zmień hasła administratorów, hostingu, bazy i SFTP z zaufanego urządzenia;
• wymień klucze i sole bezpieczeństwa WordPressa;
• sprawdź pliki, bazę danych, zadania CRON, wtyczki oraz katalog uploads;
• usuń nieznane konta dopiero po zabezpieczeniu materiału do analizy;
• odtwarzaj stronę wyłącznie z kopii, której czystość potrafisz potwierdzić.

Brak widocznych zmian na stronie nie wyklucza włamania. Atakujący może pozostawić ukryty dostęp i wykorzystać go później.

Jak ograniczyć ryzyko podobnych podatności w przyszłości?

Jednorazowa aktualizacja jest konieczna, ale skuteczne bezpieczeństwo WordPressa wymaga stałego procesu:

• włącz aktualizacje bezpieczeństwa rdzenia;
• monitoruj komunikaty WordPress.org i używanego hostingu;
• aktualizuj wtyczki oraz motywy, a nieużywane usuń;
• ogranicz liczbę kont administratorów i stosuj MFA;
• utrzymuj regularne, testowane kopie zapasowe;
• monitoruj zmiany plików, logowania i nietypowe żądania;
• korzystaj z WAF jako dodatkowej, a nie jedynej ochrony;
• regularnie testuj procedurę odtwarzania strony.

Więcej o organizowaniu aktualizacji znajdziesz w poradniku dlaczego aktualizacje systemów i aplikacji są kluczowe dla bezpieczeństwa.

Podsumowanie

WordPress 7.0.2 usuwa dwa problemy bezpieczeństwa w rdzeniu: SQL injection oznaczone jako CVE-2026-60137 oraz krytyczny scenariusz związany z trasami REST API, opisany jako CVE-2026-63030. W WordPressie 6.9 i 7.0 podatności mogą zostać połączone w łańcuch prowadzący do zdalnego wykonania kodu.

Najważniejsze działanie jest proste: sprawdź wersję WordPressa i zainstaluj poprawkę natychmiast. Następnie zweryfikuj działanie strony, integralność rdzenia i logi z okresu poprzedzającego aktualizację.

Źródła

• WordPress 7.0.2 Release — oficjalny komunikat WordPress.org
• GHSA-fpp7-x2x2-2mjf / CVE-2026-60137 — WordPress Security Advisory
• GHSA-ff9f-jf42-662q / CVE-2026-63030 — WordPress Security Advisory
• Dokumentacja wydania WordPress 7.0.2