Atakujący na szeroką skalę wykorzystują dwie krytyczne luki w WordPressie, które można połączyć w łańcuch, aby uzyskać nieuwierzytelnione zdalne wykonanie kodu na podatnych witrynach.
Łańcuch exploitów, nazwany WP2Shell, łączy CVE-2026-60137 i CVE-2026-63030. Użyte razem, te błędy pozwalają atakującemu bez żadnych danych logowania przejąć domyślną instalację WordPressa.
Badacze z Searchlight Cyber odkryli te luki, używając GPT-5.6 Sol Ultra podczas badań nad podatnościami. Według raportu AI pomogła zidentyfikować błędy i zbudować łańcuch exploitów w około 10 godzin.
Tempo odkrycia, ujawnienia i wykorzystania pokazuje, jak szybko badania nad podatnościami wspierane przez AI mogą przerodzić się w realne ryzyko.
Co sprawia, że WP2Shell jest groźny
Niebezpieczeństwo wynika ze sposobu, w jaki obie luki współdziałają.
CVE-2026-60137 to luka typu SQL injection w rdzeniu WordPressa. Sama w sobie wymaga uwierzytelnienia, co oznacza, że atakujący zwykle potrzebowałby ważnego konta, aby ją wykorzystać.
CVE-2026-63030 to błąd logiczny w Batch REST API WordPressa. To API pozwala aplikacjom łączyć wiele żądań w jedno wywołanie.
Błąd polega na rozbieżności między tym, jak punkt końcowy wsadowy waliduje żądania, a tym, jak później je wykonuje. Atakujący mogą wykorzystać to niedopasowanie, aby przepuścić złośliwe żądanie przez kontrole, które normalnie wymagałyby dostępu po zalogowaniu.
Po połączeniu w łańcuch błąd w Batch REST API sprawia, że SQL injection staje się osiągalne bez uwierzytelniania.
To dramatycznie zmienia skutki.
To, co zaczyna się jako uwierzytelnione SQL injection, staje się nieuwierzytelnioną ścieżką do pełnego zdalnego wykonania kodu.
Zagrożone są domyślne instalacje WordPressa
Luki dotyczą:
- WordPressa w wersjach od 6.9.0 do 6.9.4
- WordPressa w wersjach od 7.0.0 do 7.0.1
Ponieważ łańcuch dotyczy domyślnych konfiguracji instalacji, potencjalna ekspozycja jest ogromna.
WordPress napędza znaczną część internetu, a wiele witryn polega na automatycznych aktualizacjach lub opóźnionych cyklach konserwacji. Tworzy to szeroką pulę celów dla oportunistycznych atakujących.
Badacze bezpieczeństwa ostrzegali, że organizacje, które nie zainstalowały poprawek, powinny zakładać, iż włamanie jest możliwe, zwłaszcza wobec dużej liczby publicznych exploitów proof-of-concept i aktywnego skanowania.
Wykorzystywanie luk szybko eskalowało
Oś czasu wykorzystywania luk potoczyła się szybko.
WordPress wydał aktualizację zabezpieczeń 17 lipca, aby usunąć obie luki. Ze względu na powagę sytuacji zespół WordPress.org włączył wymuszone aktualizacje przez system automatycznych aktualizacji dla dotkniętych wersji.
W ciągu dwóch dni od ujawnienia badacze zidentyfikowali już ponad dwa tuziny publicznych exploitów proof-of-concept wymierzonych w WP2Shell.
WatchTowr poinformował, że wykorzystywanie luk zaobserwował w swojej sieci honeypotów wkrótce po ujawnieniu. Wczesne ataki koncentrowały się na eksfiltracji zahaszowanych danych uwierzytelniających, ale aktywność szybko rozszerzyła się na zdalne wykonanie kodu w miarę udostępniania kolejnych szczegółów.
Ataki wydają się szeroko zakrojone, zautomatyzowane i oportunistyczne.
Co atakujący robią po wykorzystaniu luki
Gdy atakujący uzyskają dostęp, nie poprzestają na potwierdzeniu działania proof-of-concept.
Zaobserwowana aktywność po wykorzystaniu luk obejmuje:
- tworzenie kont administratorów typu backdoor
- wdrażanie fałszywych wtyczek WordPressa
- eksfiltrację danych uwierzytelniających i sekretów
- wgrywanie dodatkowych narzędzi
- próby instalacji złośliwego oprogramowania do zdalnego dostępu
- utrzymywanie trwałej obecności na przejętych witrynach
WatchTowr poinformował o zaobserwowaniu ponad 100 kont administratorów typu backdoor utworzonych przez różne grupy zagrożeń przy użyciu odmian publicznych narzędzi.
W jednym zaobserwowanym przypadku atakujący próbowali pobrać Overlord RAT, trojana zdalnego dostępu napisanego w Golangu.
Oznacza to, że obrońcy nie powinni zakładać, iż samo zainstalowanie poprawek wystarczy, jeśli witryna była wystawiona na atak w okresie wykorzystywania luk.
Dlaczego AI zmienia oś czasu
Jednym z najważniejszych aspektów WP2Shell jest rola badań nad podatnościami wspieranych przez AI.
Searchlight Cyber poinformował, że GPT-5.6 Sol Ultra pomógł znaleźć luki i opracować łańcuch exploitów w czasie, który byłby niezwykle trudny do osiągnięcia dla badacza pracującego samodzielnie.
To ma znaczenie, ponieważ atakujący mogą używać podobnych narzędzi, gdy tylko szczegóły podatności staną się publiczne.
Po ujawnieniu odtwarzanie łańcuchów exploitów staje się szybsze. Publiczne wskazówki, różnice w poprawkach (patch diffs), fragmenty proof-of-concept i czołowe modele AI mogą skrócić czas między ujawnieniem a masowym wykorzystaniem luki.
Dla obrońców oznacza to zmniejszenie dawnego bufora czasowego na łatanie.
Okno między „wydaniem poprawki” a „wykorzystaniem w całym internecie” się kurczy.
Dlaczego ten łańcuch jest atrakcyjny dla atakujących
WP2Shell jest szczególnie niebezpieczny, ponieważ pomija wiele kroków, które obrońcy zwykle starają się wykrywać.
Atakujący nie potrzebują:
- skradzionych danych uwierzytelniających
- użytkownika, który padł ofiarą phishingu
- podatnej wtyczki innej firmy
- dostępu do panelu administracyjnego
- wcześniejszego przyczółka na serwerze
Podatna domyślna instalacja WordPressa może wystarczyć.
To sprawia, że wykorzystanie luki łatwo zautomatyzować w skali całego internetu.
Jak zauważył jeden z ekspertów, SQL injection może ujawnić bazę danych, a zdalne wykonanie kodu daje kontrolę nad serwerem. Razem tworzą bezpośrednią drogę od anonimowego żądania do pełnego przejęcia.
Co właściciele witryn powinni zrobić natychmiast
Właściciele witryn WordPress powinni natychmiast zaktualizować system do naprawionej wersji.
Ponieważ jednak wykorzystywanie luk rozpoczęło się szybko, zainstalowanie poprawek należy traktować jedynie jako pierwszy krok.
Administratorzy powinni również sprawdzić witryny pod kątem oznak włamania, w tym:
- nowych lub nieznanych kont administratorów
- podejrzanych wtyczek
- niedawno zmodyfikowanych plików motywów lub wtyczek
- nieznanych plików PHP
- nieoczekiwanych zaplanowanych zadań
- nieznanych web shelli
- podejrzanych przesłanych plików
- nietypowych połączeń wychodzących
- prób uzyskania dostępu do danych uwierzytelniających
- nieoczekiwanych zmian w użytkownikach lub opcjach bazy danych
Każdą wystawioną witrynę z dotkniętą wersją należy przejrzeć, nawet jeśli poprawki zostały już zainstalowane.
Zalecane działania obronne
Organizacje zarządzające środowiskami WordPress powinny:
- zweryfikować, czy wszystkie dotknięte wersje WordPressa zostały zaktualizowane
- potwierdzić, że automatyczne aktualizacje zakończyły się powodzeniem
- przejrzeć użytkowników z rolą administratora
- usunąć nieznane wtyczki i motywy
- sprawdzić integralność plików względem sprawdzonych kopii zapasowych
- zmienić hasła administratorów WordPressa
- zmienić dane uwierzytelniające bazy danych, jeśli podejrzewa się włamanie
- przejrzeć logi serwera WWW pod kątem prób wykorzystania luk
- w razie potrzeby przywrócić dane z czystych kopii zapasowych
- wdrożyć lub dostroić reguły zapory aplikacji internetowych (WAF)
- monitorować ponowne tworzenie backdoorów
- ograniczyć dostęp administracyjny tam, gdzie to możliwe
W środowiskach zarządzanych dostawcy hostingu powinni przeprowadzać skanowanie całej floty serwerów i powiadamiać klientów, których witryny wykazują wskaźniki włamania.
Podsumowanie
WP2Shell to poważny łańcuch exploitów WordPressa, ponieważ łączy skalę, prostotę i skutki.
Łańcuch dotyczy domyślnych instalacji WordPressa, nie wymaga uwierzytelniania i może prowadzić do pełnego zdalnego wykonania kodu. Publiczne exploity proof-of-concept pojawiły się szybko, a atakujący w bardzo krótkim czasie przeszli od skanowania do tworzenia backdoorów i wdrażania złośliwego oprogramowania.
Rola badań nad podatnościami wspieranych przez AI dodaje kolejną lekcję.
Obrońcy muszą teraz zakładać, że gdy tylko pojawią się szczegóły techniczne, odtworzenie i wykorzystanie luki jako broni może nastąpić bardzo szybko.
Zainstaluj poprawki natychmiast, ale także przeprowadź dochodzenie. Jeśli podatna witryna WordPress była online w okresie wykorzystywania luk, traktuj ją jako potencjalnie przejętą, dopóki nie udowodnisz inaczej.
