Kilka dni temu zespół WordPress opublikował awaryjną aktualizację bezpieczeństwa usuwającą jedną z najgroźniejszych podatności ostatnich lat. Tym razem problem nie tkwi w zewnętrznych dodatkach, lecz w samym rdzeniu najpopularniejszego systemu zarządzania treścią na świecie. Oznacza to, że zagrożone były również całkowicie „czyste” instalacje WordPressa, pozbawione jakichkolwiek wtyczek.
Lukę odkryli badacze z Searchlight Cyber, którzy nazwali cały łańcuch ataku WP2Shell. Za zgłoszenie podatności odpowiada Adam Kues z Assetnote, który przekazał ją do programu bug bounty WordPress na platformie HackerOne. Dzięki temu poprawki zostały przygotowane jeszcze przed pełnym ujawnieniem szczegółów technicznych.
Jednym z najbardziej interesujących aspektów całej sprawy jest sposób wykrycia błędu. Otóż badacze wykorzystali w tym celu model AI GPT-5.6 Sol Ultra. Jest to więc jeden z pierwszych tak głośnych przypadków, w którym sztuczna inteligencja pomogła znaleźć krytyczny błąd w rdzeniu tak powszechnego oprogramowania.
Dwie luki, jeden bardzo groźny scenariusz
WP2Shell łączy dwie odrębne podatności. Pierwsza (CVE-2026-63030) dotyczy obsługi żądań wsadowych REST API, natomiast druga (CVE-2026-60137) umożliwia przeprowadzenie ataku SQL Injection w mechanizmie WP_Query. Osobno błędy nie prowadzą do pełnego przejęcia systemu. Razem tworzą jednak łańcuch pozwalający na zdalne wykonanie kodu (Remote Code Execution – RCE), czyli jedną z najgroźniejszych kategorii podatności.
Aatak nie wymaga praktycznie żadnych warunków wstępnych. „Kluczowe jest to, co podkreśla Searchlight Cyber: atak nie ma żadnych warunków wstępnych, nie wymaga konta, logowania, podatnej wtyczki ani interakcji użytkownika” – wskazuje Łukasz Ozimek, COO Exea Data Center.
Napastnik może wysłać odpowiednio spreparowane żądanie do endpointu pod adresem /wp-json/batch/v1, wykorzystać błąd w obsłudze zapytań, uzyskać dostęp m.in. do hashy haseł administratorów, a następnie przejąć kontrolę nad serwerem.
Setki milionów stron w zasięgu ataku
Według szacunków Searchlight Cyber, WordPress obsługuje ponad 500 mln stron internetowych, co odpowiada blisko połowie całego internetu.
Najbardziej zagrożone są wersje: 6.9.0-6.9.4 oraz 7.0.0-7.0.1. Wersje 6.8.x zawierają jedynie podatność SQL Injection, natomiast starsze wydania nie są objęte opisanym łańcuchem ataku.
Ekspert Exea zwraca uwagę, że nawet obecność rozwiązań takich jak Redis czy Memcached nie powinna być traktowana jako skuteczna ochrona. „Ścieżka RCE może nie działać w środowiskach z trwałą pamięcią podręczną obiektów (np. Redis lub Memcached), ale nie należy tego traktować jako zabezpieczenia, bo nie usuwa samej luki” – przestrzega Łukasz Ozimek.
AI skraca czas od odkrycia luki do ataków
Szczególny niepokój budzi tempo, w jakim cyberprzestępcy zaczęli wykorzystywać nową podatność. Już dwa dni po jej ujawnieniu firma VulnCheck zidentyfikowała ponad 20 publicznie dostępnych exploitów, a aktywne próby wykorzystania błędu potwierdziły m.in. Patchstack, Hexastrike i watchTowr. Ostrzeżenie opublikował również CERT Polska. Zmienia się więc nie tylko skala zagrożeń, ale również tempo ich wykorzystania.
„Benjamin Harris, szef watchTowr, zwraca uwagę na dwie rzeczy: że tak poważna, nieuwierzytelniona luka w samym rdzeniu WordPressa jest rzadkością, i że okno między ujawnieniem a masowym atakiem drastycznie się skróciło dzięki narzędziom AI, które pozwalają odtworzyć exploit w kilka godzin, a nie dni” – komentuje Łukasz Ozimek.
Przejęta strona może działać pozornie normalnie
Największym zagrożeniem nie musi być całkowite wyłączenie witryny. Znacznie częściej przejęte serwery pozostają aktywne i przez długi czas nie wzbudzają podejrzeń właścicieli. Zainfekowane strony mogą zostać wykorzystane do dystrybucji złośliwego oprogramowania, prowadzenia kampanii phishingowych, kradzieży danych klientów czy jako element botnetów. W praktyce właściciel serwisu często dowiaduje się o kompromitacji dopiero po wielu dniach lub tygodniach.
W związku z aktywnym wykorzystywaniem podatności administratorzy powinni jak najszybciej zaktualizować WordPress do najnowszej wersji bezpieczeństwa oraz zweryfikować logi pod kątem oznak nieautoryzowanego dostępu. Poniżej ekspert Exea podaje więcej szczegółów.
Jak się zabezpieczyć, krok po kroku
- Sprawdź swoją wersję. W panelu WordPress wejdź w Kokpit i sekcję Aktualizacje albo spójrz na widżet „Rzut oka”. Jeśli masz 6.9.0-6.9.4, 7.0.0-7.0.1 lub 6.8.0-6.8.5, jesteś w grupie ryzyka. Możesz też skorzystać z darmowego testera pod adresem wp2shell.com, przygotowanego przez odkrywców luki.
- Zaktualizuj natychmiast, to jedyne pełne rozwiązanie. Zaktualizuj WordPress do wersji 7.0.2, 6.9.5 lub 6.8.6, zależnie od gałęzi. Zrobisz to w Kokpit, Aktualizacje, „Zaktualizuj teraz”. Wszystkie pozostałe kroki to jedynie tymczasowe łagodzenie ryzyka.
- Zweryfikuj, że aktualizacja faktycznie się wykonała. Ze względu na wagę problemu WordPress.org uruchomił wymuszone aktualizacje automatyczne, ale samo ich uruchomienie nie gwarantuje, że proces się powiódł. Po aktualizacji ponownie sprawdź numer wersji w panelu.
- Jeśli nie możesz zaktualizować od razu, zablokuj endpoint na WAF. Trzeba zablokować obie formy dostępu, bo zablokowanie tylko jednej zostawia otwartą furtkę: ścieżkę /wp-json/batch/v1 oraz formę ?rest_route=/batch/v1. Alternatywnie wyłącz REST API dla anonimowych użytkowników albo zainstaluj udostępnioną przez badaczy wtyczkę odrzucającą anonimowe żądania wsadowe. Uwaga: te środki mogą zakłócić działanie edytora blokowego i innych funkcji, więc traktuj je jako pomost do właściwej aktualizacji.
- Jeśli używasz Cloudflare. Klienci planów darmowych są chronieni automatycznie. Klienci planów Pro, Business i Enterprise powinni upewnić się, że reguły Cloudflare Managed Rules są włączone.
- Sprawdź, czy nie jesteś już przejęty, niezależnie od tego, czy zdążyłeś załatać. Przejrzyj listę kont administratorów i usuń te, których nie rozpoznajesz. Sprawdź ostatnio modyfikowane pliki na serwerze i poszukaj nieznanych wtyczek oraz podejrzanych plików PHP. Przejrzyj logi pod kątem nietypowych żądań do REST API. Jeśli strona działała na podatnej wersji dłużej niż kilka dni, potraktuj ją jak potencjalnie już zaatakowaną, a nie tylko teoretycznie zagrożoną.
