Większość poważnych włamań na strony oparte o WordPressa idzie przez wtyczki i motywy — kod pisany przez tysiące niezależnych deweloperów o bardzo różnym poziomie. Sam rdzeń CMS-a od lat trzyma się zaskakująco dobrze. Tym razem jest inaczej. 17 lipca 2026 roku badacze z Searchlight Cyber ujawnili wp2shell — łańcuch podatności pozwalający anonimowemu napastnikowi wykonać własny kod na czystej, domyślnej instalacji WordPressa. Bez wtyczek, bez konta, bez żadnych warunków wstępnych. Dzień później w sieci pojawiły się publiczne exploity, a firma watchTowr potwierdziła pierwsze ataki na żywych stronach.
Dwa błędy, które osobno wyglądały niegroźnie
wp2shell to nie jedna luka, tylko dwie połączone w łańcuch. Pierwsza, CVE-2026-63030, to pomyłka w obsłudze zbiorczego endpointu REST API pod adresem /wp-json/batch/v1, dodanego w WordPressie 6.9. Gdy w paczce żądań trafi się wpis źle sformułowany, obsługa go pomija — ale tablica dopasowanych procedur rozjeżdża się wtedy o jedną pozycję względem tablicy żądań. Od tego momentu każde kolejne żądanie jest autoryzowane na podstawie uprawnień cudzego żądania z tej samej paczki. Operacja, do której napastnik nie ma prawa, zostaje przepuszczona, bo serwer sprawdził uprawnienia nie tego wpisu, co trzeba.
Druga, CVE-2026-60137, to klasyczne SQL injection w parametrze author__not_in w WP_Query. Sama w sobie jest oceniana jako wysoka, ale nie krytyczna. Dopiero zestawione razem eskalują do zdalnego wykonania kodu — najgorszego możliwego wyniku dla aplikacji webowej. To podręcznikowy przykład tego, jak dwie podatności ocenione osobno na “średnia” i “wysoka” tworzą razem realną ścieżkę do pełnego przejęcia serwera.
Kogo to dotyczy
Pełny łańcuch RCE działa na WordPressie od 6.9.0 do 6.9.4 oraz od 7.0.0 do 7.0.1. Samo SQL injection sięga wstecz aż do 6.8.0, ale bez feralnego endpointu batch (dodanego dopiero w 6.9) nie da się go rozwinąć do wykonania kodu. Łańcuch został załatany w wersjach 6.9.5 i 7.0.2.
Skala jest tym, co robi tu największe wrażenie. Searchlight Cyber szacuje, że na WordPressie stoi ponad 500 milionów stron — od blogów po sklepy i witryny firmowe. W Polsce to prawdopodobnie większość małych i średnich firmowych stron internetowych. Zespół bezpieczeństwa WordPressa uznał sprawę za na tyle poważną, że włączył wymuszone aktualizacje automatyczne dla podatnych instalacji — krok stosowany naprawdę wyjątkowo.
Warto zauważyć, że część krążących po GitHubie exploitów działa w słabszym wariancie: wyciąga hashe haseł przez SQL injection, łamie hasło administratora, loguje się i dopiero wtedy wgrywa złośliwą wtyczkę. Inne twierdzą, że osiągają wykonanie kodu w ogóle bez poświadczeń, co pokrywa się z opisem odkrywców. Dla właściciela strony różnica jest akademicka — obie drogi kończą się tak samo.
Co zrobić już dziś
Jedyne właściwe działanie to aktualizacja do WordPressa 7.0.2 lub 6.9.5. Jeżeli masz włączone automatyczne aktualizacje bezpieczeństwa, jest spora szansa, że stało się to już samo — ale sprawdź to ręcznie w panelu, zamiast zakładać. Searchlight Cyber udostępniło stronę wp2shell.com, która pozwala przetestować, czy dana instalacja jest podatna.
Jeśli z jakiegoś powodu nie możesz zaktualizować od ręki, badacze proponują dwa obejścia tymczasowe: zablokowanie anonimowego dostępu do REST API odpowiednią wtyczką albo odcięcie ścieżek /wp-json/batch/v1 oraz ?rest_route=/batch/v1 na poziomie WAF-a. Cloudflare wdrożył reguły WAF blokujące obie podatności dla wszystkich planów, łącznie z darmowym. Trzeba jednak jasno powiedzieć: to plaster, nie leczenie — łatka jest jedynym trwałym rozwiązaniem.
Osobna sprawa to strony, które mogły zostać zaatakowane, zanim zdążyłeś załatać. Sprawdź listę kont administratorów pod kątem nieznanych wpisów, przejrzyj katalog wtyczek pod kątem plików, których tam nie wgrywałeś, i zajrzyj do logów serwera pod kątem żądań do batch/v1. Aktualizacja zamyka drzwi, ale nie usuwa napastnika, który przeszedł przez nie wcześniej.
Podsumowanie
wp2shell jest groźny nie dlatego, że jest skomplikowany, ale dlatego, że nie wymaga zupełnie niczego — żadnej wtyczki, żadnego konta, żadnego szczęścia. Wystarczy podatna wersja i dostęp do internetu. Publiczne exploity są już w obiegu i pierwsze ataki trwają, więc czas na spokojne planowanie aktualizacji się skończył. To także dobra okazja, by sprawdzić, czy automatyczne aktualizacje bezpieczeństwa w twoich instalacjach faktycznie działają — bo dziś to one dla wielu stron będą różnicą między spokojnym weekendem a odbudową serwisu z kopii zapasowej.