WordPress 7.0.2: pilna aktualizacja po potwierdzeniu aktywnej eksploatacji

Jeżeli Twoja strona działa na WordPressie 6.8.0–6.8.5, 6.9.0–6.9.4 albo 7.0.0–7.0.1, potraktuj aktualizację jako zadanie bezpieczeństwa o wysokim priorytecie. Najpierw potwierdź rzeczywistą wersję instalacji i wykonaj odtwarzalną kopię, następnie zaktualizuj co najmniej do poprawionej wersji swojej gałęzi i sprawdź działanie strony. Jeżeli występują oznaki wcześniejszego naruszenia, sama zmiana numeru wersji nie kończy reakcji na incydent.

WordPress opublikował wydanie bezpieczeństwa 7.0.2 17 lipca 2026 roku. Cztery dni później, 21 lipca 2026 roku, CISA dodała CVE-2026-60137 do katalogu Known Exploited Vulnerabilities i oznaczyła eksploatację jako aktywną.

TL;DR

• WordPress 7.0.2, 6.9.5 i 6.8.6 zawierają poprawki bezpieczeństwa dla podatnych gałęzi.
• CVE-2026-60137 dotyczy wersji 6.8.0–6.8.5, 6.9.0–6.9.4 oraz 7.0.0–7.0.1.
• CVE-2026-63030 dotyczy wersji 6.9.0–6.9.4 oraz 7.0.0–7.0.1.
• W wersjach 6.9 i 7.0 obie podatności mogą zostać połączone w łańcuch prowadzący do zdalnego wykonania kodu. Oficjalne wpisanie CVE-2026-60137 do KEV nie powinno być jednak rozszerzane na nieudokumentowane twierdzenie o aktywnym wykorzystaniu całego łańcucha.
• WordPress.org włączył wymuszone aktualizacje automatyczne dla podatnych instalacji, ale właściciel strony nadal powinien sprawdzić faktycznie zainstalowaną wersję.
• Wersje starsze niż 6.8 nie są według komunikatu WordPress objęte tymi dwiema podatnościami, lecz pozostają niewspierane. Nie należy nazywać ich bezpiecznymi.
• Kopia zapasowa musi nadawać się do odtworzenia. Sam fakt istnienia archiwum na serwerze nie wystarcza.
• Aktualizacja usuwa podatny kod, ale nie dowodzi, że wcześniej nie doszło do włamania.
• Termin 4 sierpnia 2026 roku wskazany przez CISA dotyczy amerykańskich agencji federalnych. Nie jest terminem prawnym dla polskich firm.

Co wydarzyło się 17 i 21 lipca 2026 roku?

17 lipca: WordPress publikuje wydanie bezpieczeństwa

17 lipca WordPress udostępnił wersję 7.0.2 oraz poprawki dla starszych gałęzi: 6.9.5 i 6.8.6. Oficjalny komunikat zaleca natychmiastową aktualizację i informuje, że ze względu na wagę problemów zespół WordPress.org włączył wymuszone aktualizacje przez mechanizm automatycznych aktualizacji dla stron działających na podatnych wersjach.

Wydanie usuwa dwie odrębne podatności:

• CVE-2026-60137 — problem związany z SQL injection w parametrze author__not_in klasy WP_Query;
• CVE-2026-63030 — problem związany z interpretacją tras zbiorczych REST API, który w połączeniu z CVE-2026-60137 może prowadzić do zdalnego wykonania kodu.

WordPress 6.8 jest objęty pierwszą podatnością. Gałęzie 6.9 i 7.0 są objęte obiema.

21 lipca: CISA potwierdza aktywną eksploatację CVE-2026-60137

21 lipca CVE-2026-60137 została dodana do katalogu CISA Known Exploited Vulnerabilities. W danych NVD uzupełnionych przez CISA-ADP status eksploatacji zmieniono z none na active. To jest mocniejszy sygnał niż sama możliwość technicznego wykorzystania podatności: oznacza, że luka jest znana jako wykorzystywana w rzeczywistych atakach.

Nie daje to jednak podstaw do dopisywania informacji, których wskazane źródła nie potwierdzają. Na ich podstawie nie należy podawać:

• liczby zaatakowanych stron;
• skali ani geografii kampanii;
• metod utrzymania dostępu;
• konkretnych wskaźników kompromitacji;
• informacji, że CISA potwierdziła aktywne wykorzystanie pełnego łańcucha prowadzącego do RCE.

Praktyczny wniosek jest prosty: podatną instalację trzeba zaktualizować pilnie, ale bez niszczenia danych, które mogą być potrzebne do późniejszej analizy.

Dwie luki, dwa zakresy podatnych wersji

CVE-2026-60137 i CVE-2026-63030 nie obejmują dokładnie tych samych wydań. Dlatego sama informacja „mam WordPress 6.x” albo „mam siódemkę” nie wystarcza.

Zakresy podatnych i poprawionych wersji wynikają z oficjalnych advisory WordPress. WordPress.org zaznacza jednocześnie, że aktywnie wspierana jest wyłącznie najnowsza wersja systemu.

Minimalna poprawka nie zawsze jest najlepszym celem długoterminowym

Wersje 6.8.6 i 6.9.5 usuwają opisane podatności w swoich gałęziach. Nie oznacza to jednak, że warto pozostawać na nich bezterminowo.

Minimalna wersja poprawiona odpowiada na pytanie: „jaka najniższa wersja tej gałęzi zawiera poprawkę?”. Rekomendacja WordPressa pozostaje szersza: używać najnowszej wersji. Przy bardzo starej, niestandardowej albo silnie zmodyfikowanej instalacji przejście powinno zostać poprzedzone kopią, testem zgodności i — jeżeli to możliwe — próbą na środowisku testowym.

CVE-2026-60137 a CVE-2026-63030: dlaczego nie wolno ich mieszać?

CVE-2026-60137 jest podatnością SQL injection dotyczącą parametru author__not_in w WP_Query. Obejmuje gałęzie od 6.8 wzwyż w wersjach wymienionych w advisory.

CVE-2026-63030 dotyczy interpretacji tras zbiorczych REST API. Obejmuje WordPress 6.9.0–6.9.4 i 7.0.0–7.0.1. Oficjalne advisory wyjaśnia, że w tych gałęziach połączenie obu problemów może prowadzić do zdalnego wykonania kodu.

Poprawna komunikacja wygląda więc następująco:

• WordPress 6.8.0–6.8.5 jest podatny na CVE-2026-60137;
• WordPress 6.9.0–6.9.4 oraz 7.0.0–7.0.1 są podatne na obie luki;
• vendor potwierdza techniczną możliwość połączenia obu problemów w łańcuch prowadzący do RCE;
• wpis KEV przywołany w tym materiale potwierdza aktywne wykorzystanie CVE-2026-60137;
• na podstawie samego tego wpisu nie należy twierdzić, że CISA potwierdziła aktywne wykorzystanie całego łańcucha RCE.

Dla właściciela strony różnica ta nie zmniejsza pilności aktualizacji. Chroni jednak przed tworzeniem sensacyjnych wniosków szerszych niż źródła.

Jak sprawdzić wersję WordPressa?

Najprostsza droga dla właściciela strony prowadzi przez panel administracyjny:

1. Zaloguj się do WordPressa.
2. Otwórz Kokpit → Aktualizacje.
3. Sprawdź wyświetlaną wersję i dostępność aktualizacji.
4. Po zakończeniu aktualizacji ponownie otwórz ten ekran i potwierdź, że system pokazuje poprawioną wersję.

WordPress opisuje aktualizację jednym kliknięciem właśnie z poziomu ekranu Dashboard → Updates. Administratorzy serwerów mogą dodatkowo potwierdzić wersję przez narzędzia hostingu lub narzędzia wiersza poleceń, ale wynik powinien zostać zapisany w rejestrze wykonanych prac.

Jeżeli nie możesz się zalogować, nie zakładaj automatycznie, że problem wynika z ataku. Jednocześnie nie ignoruj sytuacji. Skontaktuj się z administratorem lub hostingiem, aby potwierdzić wersję z poziomu serwera i zabezpieczyć dostępne logi.

Co zrobić teraz: plan 30–60–120 minut

Poniższy plan jest autorską ramą operacyjną Samurai SEO, a nie gwarancją, że każdą aktualizację lub każdy incydent da się zamknąć w dwóch godzinach. Czas zależy od wielkości serwisu, jakości kopii, hostingu, liczby integracji i ewentualnych oznak kompromitacji.

Pierwsze 30 minut: wersja, ekspozycja i odtwarzalna kopia

1. Potwierdź wersję WordPressa.

Nie opieraj się na pamięci, mailu o automatycznej aktualizacji ani założeniu, że hosting „na pewno zrobił update”.

1. Zapisz stan początkowy.

Zanotuj domenę, wersję, godzinę kontroli, osobę wykonującą działania i dostępność panelu.

1. Ustal, czy strona jest publicznie dostępna.

Witryna dostępna z internetu wymaga szybkiego priorytetu. Nie wykonuj jednak chaotycznych zmian bez kopii i zapisu działań.

1. Wykonaj kopię plików i bazy danych.

Dokumentacja WordPress zaleca utworzenie kopii przed aktualizacją, aby możliwe było odtworzenie witryny w razie problemów.

1. Sprawdź, czy kopię da się odtworzyć.

Minimum to potwierdzenie, że archiwum istnieje, ma prawidłowy rozmiar, obejmuje bazę oraz pliki i jest przechowywane poza katalogiem aktualizowanej instalacji. W przypadku ważnego sklepu preferowany jest test odtworzenia na oddzielnym środowisku.

1. Zabezpiecz dostępne logi.

Nie usuwaj ich i nie uruchamiaj „czyszczenia”, które może nadpisać dane potrzebne do analizy.

Jeżeli już na tym etapie widzisz nieoczekiwane konta administratorów, zmiany plików, nietypowe błędy lub brak kontroli nad panelem, przejdź do procedury incydentowej. Nie traktuj strony jak zwykłej, czystej instalacji oczekującej jedynie na aktualizację.

Do 60 minut: aktualizacja i testy podstawowe

1. Zaktualizuj do poprawionej wersji.

- 6.8.0–6.8.5 → minimum 6.8.6; - 6.9.0–6.9.4 → minimum 6.9.5; - 7.0.0–7.0.1 → minimum 7.0.2.

1. Preferuj najnowszą wspieraną wersję, jeżeli zgodność instalacji została wcześniej sprawdzona.
2. Nie zamykaj panelu przed potwierdzeniem zakończenia aktualizacji.
3. Sprawdź ponownie numer wersji.
4. Wyczyść cache WordPressa, wtyczki cache, hostingu i CDN, jeżeli są stosowane. Oficjalna dokumentacja WordPress wskazuje, że bez wyczyszczenia cache użytkownicy mogą nadal oglądać starszą wersję strony.
5. Sprawdź podstawowe funkcje:

- stronę główną; - kluczowe podstrony; - wersję mobilną; - logowanie i wylogowanie; - panel administracyjny; - formularze kontaktowe; - wyszukiwarkę wewnętrzną; - działanie menu i linków; - komunikaty błędów.

1. Sprawdź błędy serwera i aplikacji powstałe bezpośrednio po aktualizacji.

Aktualizacja jednym kliknięciem jest opisana przez WordPress jako standardowa i najłatwiejsza metoda dla większości użytkowników. Jeżeli proces nie działa, nie wyłączaj losowo zabezpieczeń ani nie zmieniaj pochopnie uprawnień plików. Eskaluj problem do osoby rozumiejącej konfigurację serwera.

Do 120 minut: kontrola bezpieczeństwa i decyzja o eskalacji

Po potwierdzeniu działania strony wykonaj drugą warstwę kontroli:

• sprawdź, czy nie pojawiły się nieoczekiwane konta użytkowników, szczególnie z uprawnieniami administratora;
• porównaj istotne pliki z oczekiwanym stanem, jeżeli posiadasz wiarygodny punkt odniesienia;
• sprawdź nieoczekiwane zmiany w plikach core, motywach i wtyczkach;
• przejrzyj dostępne logi serwera, WordPressa, WAF i hostingu;
• sprawdź zadania cron i inne automatyczne procesy pod kątem nieoczekiwanych zmian;
• zweryfikuj, czy formularze, wysyłka wiadomości i integracje zewnętrzne działają;
• zanotuj wszystkie odchylenia i osobę podejmującą decyzję.

Brak widocznych objawów nie jest dowodem, że wcześniej nie doszło do kompromitacji. Jest jedynie wynikiem ograniczonej kontroli w określonym czasie.

WooCommerce: co sprawdzić po aktualizacji?

W sklepie nie wystarczy sprawdzić, czy otwiera się strona główna. Aktualizacja bezpieczeństwa może przebiec prawidłowo na poziomie core, a jednocześnie ujawnić konflikt z wtyczką, motywem, cache lub integracją płatniczą.

Minimalny test sprzedażowy WooCommerce

• Strona kategorii produktów otwiera się prawidłowo.
• Karta produktu pokazuje cenę, warianty, dostępność i zdjęcia.
• Produkt można dodać do koszyka.
• Zmiana liczby produktów aktualizuje podsumowanie.
• Kod rabatowy działa, jeżeli sklep z niego korzysta.
• Można przejść z koszyka do checkoutu.
• Pola adresowe i dostawy działają.
• Dostępne metody płatności są widoczne.
• Testowe zamówienie przechodzi do oczekiwanego statusu.
• E-maile transakcyjne są generowane.
• Integracja magazynowa lub ERP nie zgłasza błędu.
• Zadania cykliczne i kolejki wykonują się.
• Panel zamówień otwiera się prawidłowo.
• Cache i CDN nie pokazują nieaktualnej wersji koszyka lub checkoutu.

Nie wykonuj realnej płatności bez odpowiedniej procedury i zgody właściciela sklepu. W środowisku produkcyjnym można skorzystać z uzgodnionej metody testowej, a następnie anulować zamówienie zgodnie z procesem firmy.

Co zapisać po teście?

Dla każdej instalacji zachowaj:

• wersję przed aktualizacją;
• wersję po aktualizacji;
• godzinę wykonania kopii;
• godzinę aktualizacji;
• zakres wykonanych testów;
• wynik testowego zamówienia;
• wykryte błędy;
• podjęte działania;
• osobę zatwierdzającą przywrócenie normalnej pracy sklepu.

Aktualizacja a reakcja na incydent: to nie jest to samo

Aktualizacja

Aktualizacja jest działaniem naprawczym, gdy:

• instalacja działa normalnie;
• nie ma rozpoznanych oznak kompromitacji;
• zachowano kopię i logi;
• problemem jest obecność podatnej wersji;
• po wdrożeniu przeprowadzono testy.

Jej celem jest usunięcie znanej podatności z kodu.

Reakcja na incydent

Do procedury incydentowej należy przejść, gdy występują między innymi:

• nieoczekiwane konta administratorów;
• niewyjaśnione zmiany plików;
• brak kontroli nad panelem;
• nieoczekiwane przekierowania albo treści;
• anomalie w logach;
• nowe błędy niezwiązane czasowo wyłącznie z aktualizacją;
• podejrzane zmiany konfiguracji;
• informacja hostingu lub zabezpieczeń o możliwym naruszeniu.

W takiej sytuacji:

1. ogranicz dostęp stosownie do obowiązującej procedury;
2. zabezpiecz logi i kopię stanu;
3. nie usuwaj podejrzanych plików przed ich udokumentowaniem;
4. nie przywracaj automatycznie przypadkowej kopii;
5. skontaktuj się z administratorem, hostingiem albo zespołem reagowania na incydenty;
6. ustal zakres naruszenia;
7. dopiero później podejmij kontrolowane działania naprawcze.

Sam update nie usuwa utworzonych wcześniej kont, zmienionych plików ani innych skutków potencjalnego włamania.

Kiedy eskalować do administratora, hostingu albo zespołu IR?

Natychmiastowa eskalacja jest uzasadniona, gdy:

• nie można ustalić wersji WordPressa;
• aktualizacja nie kończy się poprawnie;
• witryna przestaje działać po wdrożeniu;
• nie istnieje wiarygodna kopia;
• nie masz dostępu do logów;
• pojawiają się nieoczekiwane konta lub zmiany plików;
• sklep nie przyjmuje zamówień;
• płatności, formularze albo integracje przestają działać;
• strona zawiera dane klientów lub obsługuje istotne procesy biznesowe;
• kilka instalacji wykazuje podobne anomalie;
• nie wiadomo, czy środowisko nadal jest kontrolowane przez właściciela.

Hosting może pomóc w potwierdzeniu wersji, odtworzeniu kopii, udostępnieniu logów, blokadzie dostępu lub analizie zmian. Nie należy jednak zakładać, że każdy hosting automatycznie wykonuje pełną analizę incydentu.

Checklista dla agencji zarządzającej wieloma witrynami

Przy kilkunastu albo kilkudziesięciu stronach największym problemem jest brak kompletnego inwentarza. Nie zaczynaj od aktualizowania przypadkowych domen. Najpierw ustal zakres.

Kolejność priorytetów

1. Publiczne sklepy i serwisy przyjmujące dane użytkowników.
2. Podatne wersje 6.9 i 7.0.
3. Podatne instalacje 6.8.
4. Instalacje o nieznanej wersji.
5. Stare, niewspierane wersje wymagające kontrolowanej migracji.
6. Środowiska testowe, które nie powinny być dostępne publicznie.

Nie odkładaj instalacji o nieznanej wersji na koniec tylko dlatego, że „prawdopodobnie jest stara”. Brak danych jest osobnym ryzykiem.

Czego nie robić?

Nie zakładaj, że autoaktualizacja na pewno się wykonała

WordPress.org uruchomił wymuszone aktualizacje dla podatnych wersji, ale proces może nie zakończyć się poprawnie z powodu konfiguracji serwera, uprawnień plików albo innych problemów. Zawsze potwierdź wersję po aktualizacji.

Nie wyłączaj losowo zabezpieczeń

Wyłączenie WAF, wtyczki bezpieczeństwa, kontroli dostępu albo ochrony hostingu może zwiększyć ekspozycję. Jeżeli zabezpieczenie blokuje aktualizację, ustal przyczynę i zastosuj kontrolowaną procedurę.

Nie usuwaj logów

Logi mogą być jedynym źródłem pozwalającym odtworzyć zdarzenia. Nie czyść ich przed zabezpieczeniem kopii.

Nie kasuj podejrzanych plików przed analizą

Usunięcie pliku może pozbawić zespół informacji o czasie, zakresie i charakterze zmiany. Najpierw zabezpiecz dowód i ogranicz ryzyko, potem wykonuj naprawę.

Nie traktuj poprawionej wersji jako dowodu braku włamania

Numer 7.0.2, 6.9.5 albo 6.8.6 potwierdza, że zainstalowana wersja zawiera poprawkę. Nie mówi, co wydarzyło się przed jej wdrożeniem.

Nie przywracaj kopii bez sprawdzenia jej daty i stanu

Kopia może pochodzić z okresu, w którym podatna wersja była już zaatakowana. Samo odtworzenie nie rozwiązuje wtedy problemu.

Czy aktualizacja wpływa na SEO?

Celem aktualizacji jest bezpieczeństwo, a nie poprawa pozycji w Google.

Wpływ na widoczność może być pośredni. Naruszona strona może przestać działać, wyświetlać nieautoryzowane treści, generować błędy albo tracić integralność. Nie oznacza to jednak, że samo zainstalowanie WordPressa 7.0.2 poprawi pozycje, ruch lub wyniki Core Web Vitals.

Po aktualizacji warto sprawdzić:

• statusy HTTP ważnych podstron;
• dostępność strony dla użytkowników;
• działanie canonicali i przekierowań;
• obecność oczekiwanej treści;
• formularze i konwersje;
• błędy serwera;
• działanie sitemap;
• brak nieoczekiwanych zmian w kodzie strony.

Są to testy integralności serwisu po zmianie, a nie obietnica efektu SEO.

FAQ

Czy automatyczna aktualizacja wystarczy?

Nie należy tego zakładać. WordPress.org włączył wymuszone aktualizacje automatyczne dla podatnych wersji, ale właściciel strony powinien potwierdzić rzeczywiście zainstalowany numer, sprawdzić działanie serwisu i przejrzeć dostępne dane pod kątem oznak wcześniejszego naruszenia.

Do jakiej wersji zaktualizować WordPress?

Minimalne poprawione wersje to:

• 6.8.6 dla gałęzi 6.8;
• 6.9.5 dla gałęzi 6.9;
• 7.0.2 dla gałęzi 7.0.

WordPress rekomenduje jednak korzystanie z najnowszej wersji, ponieważ aktywnie wspierane jest najnowsze wydanie.

Czy WordPress 6.7 jest bezpieczny?

Nie jest według komunikatu WordPress objęty CVE-2026-60137 ani CVE-2026-63030. Nie oznacza to jednak, że jest bezpieczny. Jest wersją starszą niż obecnie wspierane wydanie i może być objęty innymi podatnościami lub problemami. Należy zaplanować kontrolowaną aktualizację do najnowszej wspieranej wersji.

Czy sam update usuwa skutki włamania?

Nie. Aktualizacja usuwa podatność z bieżącego kodu. Nie usuwa automatycznie kont, plików, zmian konfiguracji ani innych skutków, które mogły powstać wcześniej.

Jak sprawdzić wersję WordPressa?

Zaloguj się do panelu i otwórz Kokpit → Aktualizacje. Po wykonaniu aktualizacji wróć na ten ekran i potwierdź nową wersję. Administrator może dodatkowo sprawdzić ją z poziomu hostingu lub serwera.

Czy termin CISA 4 sierpnia obowiązuje polskie firmy?

Nie jako termin prawny wynikający z tego wpisu. Data 4 sierpnia dotyczy obowiązków amerykańskich agencji federalnych objętych dyrektywami CISA. Dla polskiej firmy jest sygnałem wysokiego priorytetu operacyjnego, a nie krajowym terminem administracyjnym.

Czy CISA potwierdziła wykorzystanie pełnego łańcucha RCE?

Wpis przywołany w tym artykule potwierdza aktywne wykorzystanie CVE-2026-60137. Oficjalne advisory WordPress opisuje możliwość połączenia jej z CVE-2026-63030 w łańcuch prowadzący do RCE na gałęziach 6.9 i 7.0. Nie należy jednak na tej podstawie przypisywać CISA potwierdzenia aktywnego wykorzystania całego łańcucha.

Czy przed aktualizacją zawsze trzeba zrobić kopię?

Dokumentacja WordPress zaleca wykonanie kopii przed rozpoczęciem aktualizacji, aby w razie problemów możliwe było przywrócenie strony. Dla serwisu biznesowego kopia powinna obejmować zarówno pliki, jak i bazę danych oraz być przechowywana w miejscu niezależnym od aktualizowanej instalacji.

Podsumowanie

CVE-2026-60137 nie jest już wyłącznie teoretycznym problemem opisanym w advisory. 21 lipca 2026 roku CISA oznaczyła jej eksploatację jako aktywną. Dla właściciela WordPressa oznacza to konieczność szybkiej, ale kontrolowanej reakcji.

Właściwa kolejność działań to:

1. ustalić rzeczywistą wersję WordPressa;
2. zapisać stan instalacji i zabezpieczyć logi;
3. wykonać odtwarzalną kopię plików i bazy;
4. zaktualizować do poprawionej wersji gałęzi lub najnowszej wspieranej wersji;
5. potwierdzić numer wersji po wdrożeniu;
6. wyczyścić cache;
7. przetestować frontend, logowanie, formularze i funkcje WooCommerce;
8. sprawdzić logi, konta, pliki i zadania automatyczne;
9. w razie anomalii przejść z trybu aktualizacji do reakcji na incydent.

Najważniejszy błąd to uznanie, że aktualizacja została wykonana, ponieważ WordPress zapowiedział mechanizm automatyczny. Drugi to przyjęcie, że poprawiony numer wersji dowodzi braku wcześniejszego włamania.

Aktualizacja jest konieczna. Weryfikacja jej wyniku i zachowanie dowodów są równie ważne.