wp2shell: krytyczna podatność WordPressa. Jak załatać

Krytyczna podatność zdalnego wykonania kodu (RCE) w rdzeniu WordPressa, nazwana wp2shell, została publicznie ujawniona 17 lipca 2026 r. W przeciwieństwie do wielu problemów bezpieczeństwa WordPressa zależnych od podatnych wtyczek lub motywów, wp2shell atakuje samego WordPressa, umożliwiając nieautoryzowanym atakującym uzyskanie RCE na domyślnych instalacjach WordPressa w wersjach WordPressa wydanych od grudnia 2025 r.

Łańcuch został odkryty i ujawniony przez Searchlight Cyber, a dodatkową weryfikację oraz prace nad narzędziami obronnymi opisali pierwsi reagujący. Od publikacji aktywność eksploatacyjna była obserwowana szybko, po czym pojawiały się spójne wzorce post-exploatacji, w tym wdrażanie webshelli.

Dlaczego o tym piszemy? Szacuje się, że WordPress działa na ponad 500-600 milionach stron na całym świecie, na około 44% wszystkich stron, również na naszej.

Łańcuch podatności

wp2shell wykorzystuje dwie luki:

• CVE-2026-63030: problem nieautoryzowanego pomylenia tras w REST API w domyślnym endpointcie batch (punkt wejścia).
• CVE-2026-60137: podatność SQL injection związaną z WP_Query.

Razem pozwalają atakującemu przejść od braku dostępu do utworzenia podstawionego administratora, a ostatecznie do wykonania kodu (oraz utrzymywania dostępu przez webshell). Mechanika opiera się na wieloetapowym procesie, a nie na pojedynczym żądaniu; zachowanie końcowej eksploatacji zależy też od tego, jak budowana jest ścieżka zapytania strony.

Naprawione przez poprawkę opisaną w poście: wp_parse_id_list() w WordPress 7.0.2.

Dlaczego ta podatność jest inna (i ma duży wpływ)

Większość podatności WordPressa koncentruje się w ekosystemie wtyczek/motywów. wp2shell jest inna, ponieważ dotyczy rdzenia — czyli może dosięgnąć gołej instalacji, bez dodawania czegokolwiek.

Dodatkowo jest nieautoryzowana, działa domyślnie za pośrednictwem odpowiedniego endpointu REST i jest dostępna bez interakcji użytkownika. To połączenie skutkuje ogromną populacją wystawionych instancji, dlatego tak istotne były wymuszone automatyczne aktualizacje na WordPress.org.

Odnotowano jedno zawężające ograniczenie: ścieżka prowadząca do wykonania kodu może się zmienić w zależności od tego, czy włączone jest trwałe zewnętrzne cache obiektów. Może to zmniejszyć ekspozycję w niektórych większych wdrożeniach, ale nie rozwiązuje problemu w dużo częstszym przypadku standardowych instalacji.

Ekspozycja według wersji (co trzeba poprawić)

Dwie podatności nie pokrywają się idealnie pod względem zastosowania do wersji, więc ekspozycja dzieli się zależnie od tego, które części łańcucha są możliwe do osiągnięcia.

• 6.8.0 – 6.8.5: ekspozycja: tylko SQL injection (brak pełnego łańcucha RCE)
• 6.9.0 – 6.9.4: ekspozycja: pełny nieautoryzowany łańcuch RCE
• 7.0.0 – 7.0.1: ekspozycja: pełny nieautoryzowany łańcuch RCE

Sprawdź, czy masz zaktualizowaną wersję (do 7.0.2).

Typowa aktywność po eksploatacji

Po udanej eksploatacji endpointu obserwowano:

• Wgranie złośliwej wtyczki
  • Dostęp do: /wp-admin/plugin-install.php?tab=upload
  • Następnie: uruchomienie POST /wp-admin/update.php?action=upload-plugin
• Listing użytkowników
  • Żądania typu: /wp-json/wp/v2/users?context=edit
  • Cel: pozyskiwanie nazw użytkowników administratorów i adresów e-mail
• Próby lokalnego dołączania plików (LFI)
  • Przykładowy wzorzec: admin-ajax.php?template=../../../wp-config
  • Cel: dotarcie do sekretów na poziomie wp-config w celu dalszego przejęcia i/lub wycieku danych
• Dostęp do panelu administracyjnego
  • Dostęp do /wp-admin/
  • Obserwowane sygnały: odpowiedzi HTTP 200 zgodne z pomyślnymi uwierzytelnionymi sesjami

Dodatkowo pojawiły sie informacje o wysokowolumenowym skanowaniu, gdzie wiele hostów było sprawdzanych bez potwierdzonego przejęcia, co sugeruje oportunistyczne masowe skanowanie podatnych celów.

Główna praktyczna obserwacja: eksploatacja wp2shell często kończy się wdrożeniem webshella, a ładunki (payloady) różnią się znacząco poziomem zaawansowania.

Lekki backdoor oparty o PHP eval, który uruchamia PHP podane przez atakującego w parametrze POST i zwraca 404 w celu obejścia wykrycia. Znacznie większy jest webshell udający wtyczkę WordPress nazwaną „CMSmap”.

Inne zaobserwowane podejście polega na rejestrowaniu niestandardowego endpointu REST, co umożliwia atakującym wysyłanie poleceń zakodowanych w base64 przez POST i otrzymywanie wyniku w odpowiedzi JSON — w praktyce daje to wykonanie poleceń.

Co zrobić już teraz?

1. Natychmiast sprawdź wersję WordPressa
   Nie zakładaj, że automatyczne aktualizacje w pełni Cię ochroniły. Zweryfikuj zainstalowaną wersję w panelu.
2. Uruchom sprawdzanie kompromitacji, a nie tylko „sprawdzenie wersji”
   Jeśli system mógł zostać wystawiony zanim pojawiły się poprawki (albo jeśli aktualizacje były ograniczone/wyłączone), bezpieczniej jest przeskanować pod kątem dowodów.
3. Jeśli podejrzewasz ekspozycję: zresetuj hasła
   Zalecane jest zresetowanie haseł dla wszystkich użytkowników — zaczynając od administratorów. Uzasadnienie jest takie, że komponent SQL injection może odczytać wp_users, co może ujawnić hashe haseł.
4. Sprawdź użytkowników administratorów
   Tworzenie użytkowników z rolą administratora oznacza utrwalenie dostępu (atakujący zapewnia sobie kolejny sposób wejścia, nawet jeśli pierwotna luka zostanie załatana). Usuń wszystkich nietypowych użytkowników.
5. Sprawdź pliki w katalogu upload (202607)
   Wgrywanie plików do katalogu upload, gdzie pliki będące obrazami zawierają kod PHP, to mechanizm obejścia zasad/filtrów (np. „maskowanie” payloadu jako plik multimedialny) i często prowadzi do uzyskania webshella albo innego sposobu wykonywania kodu z poziomu publicznie dostępnych katalogów. Usuń wszystkie takie pliki
6. Reset/odtworzenie SALT
   i/lub wygaszenie wszystkich cookies/sesji, bo atakujący mógł korzystać z aktywnych sesji lub tokenów. W WordPressie odpowiadają za to klucze w wp-config.php (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY itd. oraz ich wersje „SALT”). Po wygenerowaniu nowych SALT użytkownicy zostaną wylogowani (i wszelkie tokeny/sesje stracą ważność). Nowe klucze wygenerujesz tutaj: https://api.wordpress.org/secret-key/1.1/salt/
7. Usuń nieautoryzowane pliki
   w /wp-content/uploads/, /wp-content/plugins/, ewentualnie nietypowe pliki w katalogach core, porównaj wp-content i (w razie potrzeby) cały kod z wersją z oficjalnego repozytorium.

Podejście do incydentu wp2shell jest więc nastepujące: aktualizacja, weryfikacja i sprzatanie, ponieważ przy łańcuchach, gdzie logi mogą nie wystarczyć, a kluczowe są dowody w bazie danych, „zaktualizowaliśmy” nie znaczy „jesteśmy bezpieczni”.