wp2shell: RCE w standardowym WordPressie, znalezione w dziesięć godzin za 25 dolarów

17 lipca 2026 r. Searchlight Cyber opublikowała wp2shell — łańcuch zdalnej egzekucji kodu przed uwierzytelnieniem w rdzeniu WordPressa, który nie wymaga żadnej wtyczki, motywu ani logowania. Wystarczy anonimowe żądanie skierowane do standardowej instalacji: „Atak nie ma żadnych warunków wstępnych i może go wykorzystać anonimowy użytkownik w standardowej instalacji WordPressa bez wtyczek” — głosi komunikat doradczy firmy. Łańcuch łączy dwa błędy — CVE-2026-63030, błąd mylenia tras w punkcie końcowym wsadowym interfejsu REST API WordPressa, który komunikat doradczy projektu określa jako krytyczny, oraz CVE-2026-60137, wstrzyknięcie SQL w parametrze author__not_in WP_Query, które określa jako średnie. WordPress udostępnił WordPress 7.0.2 tego samego dnia, a komunikaty doradcze projektu wymieniają WordPress 6.9.5, WordPress 6.8.6 i WordPress 7.1 beta2 jako zawierające te same poprawki. Searchlight przytacza szacunki mówiące o ponad 500 mln witryn WordPressa. Badacz stojący za łańcuchem, Adam Kues, twierdzi, że powstał on podczas uruchomienia GPT-5.6 Sol Ultra opartego na prompcie, który OpenAI opublikowało dla problemu matematycznego: do czterech agentów, co najmniej sześć godzin na poszukiwania i około czterech kolejnych na eskalację, około 25 USD zużycia modelu. Rekord został zarejestrowany jako odkrycie badawcze — wysoka istotność w skali samego archiwum, pewność klasy A, brak odnotowanych szkód w świecie rzeczywistym, datowany na jeden dzień — a Orca AI Incident Archive udostępnia go wraz z dokumentami źródłowymi podlinkowanymi poniżej.

Ujawnienie zostało skoordynowane. Searchlight wstrzymał szczegóły mechaniki 17 lipca i dał obrońcom weekend na aktualizację; Kues opublikował pełny opis techniczny 20 lipca. W tym czasie łańcuchowy exploit został już niezależnie odtworzony: Searchlight twierdzi, że Calif i Hacktron odtworzyli pełny łańcuch, zanim na GitHubie pojawiły się inne proof-of-concepty. Dwa własne komunikaty bezpieczeństwa WordPressa wymieniają te same wersje z poprawkami, a CISA dodała oba CVE do swojego katalogu Known Exploited Vulnerabilities 21 lipca.

Dwa błędy i tablice, które tracą synchronizację

Punkt wejścia jest zamierzoną funkcją, a nie błędem. WordPress 5.6 wprowadził w 2020 r. punkt końcowy wsadowy, aby klient mógł wysłać kilka wirtualnych żądań REST w ramach jednego żądania HTTP, na przykład po to, by naraz zmienić tytuły zestawu wpisów. Punkt końcowy jest osiągalny niezależnie od tego, czy wywołujący jest uwierzytelniony, a każde podżądanie przenosi wszelkie dane uwierzytelniające podane przez wywołującego. Bezpośrednie żądanie do trasy REST WordPressa uruchamia czteroetapowy potok: sprawdzenie wymaganych i prawidłowych parametrów, ich oczyszczenie, uruchomienie wywołania zwrotnego uprawnień, a następnie wykonanie wywołania zwrotnego punktu końcowego. Punkty końcowe polegają na tym potoku w zakresie swoich założeń dotyczących typów — że identyfikator wpisu jest liczbą całkowitą, a tytuł ciągiem znaków.

API wsadowe dzieli potok na dwie części: w jednej pętli waliduje każde podżądanie, a w drugiej je wykonuje, oraz utrzymuje dwie tablice, $matches i $validation, których wpisy mają się pokrywać indeks po indeksie. W class-wp-rest-server.php, jak opisuje Kues, podżądanie, które samo jest błędem WordPressa, zostaje dopisane do $validation, a następnie trafia na continue, pomijając wiersz, który dopisuje do $matches. Od tego momentu każde dopasowanie jest przesunięte o jedną pozycję wstecz. Pętla wykonawcza łączy podżądanie pod jednym indeksem z walidacją zapisaną pod tym indeksem, ale procedura obsługi jest dopasowana do innej trasy — więc parametr jest sprawdzany według reguł jednego punktu końcowego, a następnie wykonywany przez kod innego.

To właśnie zamienia wyglądający zwyczajnie parametr listy w wstrzyknięcie. Trasa kolekcji wpisów mapuje swój publiczny author_exclude argument na author__not_in. Gdy wartość jest tablicą, WordPress uruchamia absint na każdym elemencie i sortuje je; gdy wartość jest skalarem, jest dołączana bez zmian do fragmentu SQL, który staje się NOT IN ($author__not_in). Ciąg taki jak 0) OR 1=1 -- trafia zatem do tekstu zapytania. Wywołana normalnie trasa odrzuciłaby go, ponieważ author_exclude musi być tablicą liczb całkowitych; zdesynchronizowane wywołanie wsadowe pozwala ciągowi znaków przedostać się.

Pozostały dwie przeszkody i obie rozwiązano, zagnieżdżając tę sztuczkę. API wsadowe odrzuca żądania GET, a iniekcja znajduje się na trasie GET; ponadto walidacja metody żądania sama jest zaimplementowana jako walidacja parametrów, którą ta sama desynchronizacja może ominąć. Opublikowany payload Kuesa wysyła źle sformułowane zewnętrzne podżądanie, aby zdesynchronizować sprawdzanie metody, następnie wewnętrzny batch, którego drugie podżądanie przenosi złośliwy author_exclude skierowany przeciwko handlerowi, który go nie waliduje, a następnie GET, który go uruchamia. Iniekcja oparta na UNION zwraca dowolne wartości z bazy danych w wierszach ukształtowanych jak zwykłe wpisy.

Przebieg modelu: polecenie matematyczne skierowane na bazę kodu

Kues nie napisał tego promptu od zera. OpenAI opublikowało prompt, którego używało, pracując nad hipotezą Cycle Double Cover, a Kues napisał, że czytał, iż model niedawno rozwiązał tę hipotezę i że nikt w społeczności bezpieczeństwa zdawał się nie mówić o tym promptcie. Rozumował, że jeśli wystarcza on do trudnej matematyki, to prawdopodobnie wystarczy też do badań bezpieczeństwa. Zaadaptował go i skierował na WordPress.

Konfiguracja była celowo wąska. Sklonował najnowsze stabilne wydanie WordPressa do katalogu o nazwie main/ i usunął jego katalog .git, mówiąc modelowi, aby nie używał changelogów, historii git ani otwartego internetu do porównania kodu z wersją załataną — podanym przez niego powodem było to, że przy odkrywaniu nowych podatności przeglądanie historii lub sieci to strata tokenów. Zaoferowano pusty katalog third_party/, aby model mógł sklonować zależności, takie jak źródła PHP lub MySQL, jeśli uznał, że łańcuch wymaga błędów w bibliotekach pod WordPressem. Zadanie określono jako RCE przed uwierzytelnieniem w typowym wdrożeniu produkcyjnym na MySQL, z maksymalnie czterema agentami i co najmniej sześcioma godzinami. Kues napisał, że wyraźnie podaje wymóg konfiguracji, ponieważ w przeciwnym razie modele „oszukują” — wybierając skrajnie nieprawdopodobne opcje konfiguracji lub fabrykując warunki wstępne, których atakujący nigdy nie mógłby osiągnąć.

To, co pojawiło się w danych wyjściowych uruchomienia, było twierdzeniem o iniekcji SQL przed uwierzytelnieniem. Kues w to wątpił: WordPress należy do najczęściej audytowanych celów w historii — napisał — i w tej dekadzie nie miał żadnej istotnej podatności przed uwierzytelnieniem. Zainstalował standardową instancję WordPressa na zdalnym serwerze i poprosił model o wykradzenie adresu e-mail administratora; w ciągu kilku minut model wydrukował adres, którego użył do skonfigurowania instancji. Następnie zapytał, czy iniekcję tylko do odczytu można eskalować, a około cztery godziny później model odpowiedział, że można — do uprawnień administratora, bez łamania jakiegokolwiek hasła i bez obliczeń offline.

Jego własna kalkulacja kosztów: 50% tygodniowego limitu zużycia, który oszacował na około 25 dolarów proporcjonalnie do subskrypcji za 200 dolarów, za exploit wytworzony w nieco ponad dziesięć godzin. Część ludzka nie była darmowa — Kues spędził kolejny dzień na rozpracowywaniu tego, co zrobił model, i napisał, że zrozumienie pracy poeksploatacyjnej zajęło mu znacznie więcej czasu, niż zajęło jej wygenerowanie. Jego werdykt jest niezwykle dosadny i ściśle ograniczony: „Nie formułuję żadnych ogólnych twierdzeń, ale mogę powiedzieć z całkowitą pewnością, że żaden badacz bezpieczeństwa nie byłby w stanie w 10 godzin znaleźć i ukończyć tego łańcucha exploitów bez AI”.

Od SELECT-a tylko do odczytu do administratora

Eskalacja jest tą częścią zapisu, która ma największe znaczenie, ponieważ właśnie tam odczyt z bazy danych stał się kontrolą nad serwerem. Relacja Kuesa przedstawia ją jako sekwencję sześciu posunięć, z których każde wykorzystuje zwykłą funkcję WordPressa przeciwko innej.

Najpierw zatruj cache wpisów w pamięci.WordPress utrzymuje cache obiektów WP_Post dla każdego żądania, dzięki czemu odwołanie się do tego samego wpisu kilka razy w ramach jednego żądania kosztuje tylko jedną rundę komunikacji z bazą danych. Wstrzyknięcie SQL może tworzyć fikcyjne wpisy, więc atakujący dokładnie kontroluje, co trafi do cache — ale te sfabrykowane wpisy nie są wierszami w bazie danych, a cache znika wraz z żądaniem.

Po drugie, zamień sfabrykowane wpisy w prawdziwe wiersze. Funkcja osadzania WordPressa buforuje rozwiązane osadzenia w bazie danych jako wpisy typu oembed_cache. Osadzenie lokalnego wpisu przez ścieżkę względną, jak w [embed]/?p=S[/embed], sprawia, że WordPress pomija pobieranie przez HTTP i nigdy nie sprawdza, czy wskazany wpis istnieje, więc tworzony jest wiersz. Trzy takie osadzenia z różnymi tokenami ciągu zapytania tworzą trzy różne hashe pamięci podręcznej, dzięki czemu atakujący uzyskuje kilka wierszy do wykorzystania.

Po trzecie, obejdź jedno pole, które pozostaje stałe.Gdy wersja wpisu w pamięci i wersja w bazie danych nie są zgodne, WordPress uzgadnia je za pomocą wywołania, które jawnie ustawia post_content na podstawie wyniku osadzenia. Wszystko we wpisie jest kontrolowane przez atakującego z wyjątkiem jego treści, która jest dokładnie tym polem, którego customize_changeset używa do przechowywania JSON oczekujących zmian motywu i witryny.

Po czwarte, mechanizm cyklu. Wpisy mają rodziców, a WordPress odrzuca cykle: wp_insert_post_parent filtr przechodzi w górę drzewa i po napotkaniu pętli wywołuje aktualizację, która ustawia post_parent na zero. To wywołanie nie nadpisuje post_content, więc sfabrykowana wersja w pamięci przetrwa uzgadnianie — zestaw zmian z nienaruszonym JSON-em, oparty na rzeczywistym wierszu.

Po piąte, wypożycz uprawnienia administratora. Zestaw zmian, którego status wskazuje, że jest zaplanowany na przyszłość, ale którego data jest w przeszłości, jest stosowany natychmiast. Każdy wpis w jego JSON wskazuje user_id, a wpis w łańcuchu Kuesa wskazuje user_id 1, administratora, więc WordPress tymczasowo przyjmuje tę tożsamość, aby zastosować zmianę. Pierwsza zmiana to wyglądająca nieszkodliwie aktualizacja nav_menus_created_posts.

Po szóste, odtwórz żądanie z użyciem tej tożsamości.Publikowanie wpisu uruchamia akcję o dynamicznej nazwie, {status}_{post_type}. Ponieważ wpis jest sfabrykowany, ten status i typ mogą być dowolne — w tym parse i request, co daje parse_request hook i restartuje potok żądań od początku, podczas gdy pożyczona tożsamość administratora nadal obowiązuje. Pierwotne żądanie wsadowe zawierało podżądanie tworzące nowego administratora; nie powiodło się ono w pierwszym przebiegu jako gość, a przy powtórzeniu kończy się powodzeniem. Następnie atakujący loguje się na to nowe konto i przesyła z pliku ZIP wtyczkę z backdoorem, co stanowi wykonanie kodu.

Technika ma pewien warunek. The Hacker News, powołując się na Cloudflare, poinformował, że CVE-2026-63030 umożliwia zdalne wykonanie kodu tylko wtedy, gdy nie jest używany trwały cache obiektów; samo wstrzyknięcie występuje od WordPress 6.8, natomiast pełny łańcuch wymaga wersji 6.9 lub nowszej. Standardowa instalacja nie ma trwałego cache’u obiektów, dlatego sformułowanie Searchlight „bez warunków wstępnych” i zastrzeżenie Cloudflare opisują ten sam domyślny przypadek z różnych stron.

Co ustalają dokumenty źródłowe

Komunikaty bezpieczeństwa samego WordPressa są najsilniejszym potwierdzeniem, ponieważ to dostawca przyznaje mechanizm i wydaje poprawkę. GHSA-ff9f-jf42-662q, oceniony jako krytyczny, opisuje lukę polegającą na myleniu tras wsadowych REST API w WordPressie 6.9 i nowszych, która w połączeniu z iniekcją prowadzi do wykonania kodu, i wymienia Adama Kuesa z Assetnote oraz Searchlight Cyber. GHSA-fpp7-x2x2-2mjf, oceniony jako średni, opisuje podatność związaną z author__not_ininiekcją w WordPressie 6.8 i nowszych oraz stwierdza, że oba problemy zostały naprawione w WordPressie 7.0.2, WordPressie 6.9.5, WordPressie 6.8.6 i WordPressie 7.1 beta2. Wpisy NVD dla dwóch CVE, ocenione przez CNA WPScan, a nie przez NIST, mają ocenę 9.8 dla CVE-2026-63030 z wektorem AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H oraz 5.9 dla CVE-2026-60137 z AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N — w pierwszym przypadku błąd osiągalny przez sieć i niewymagający uprawnień, a w drugim wymagający wysokiej złożoności ataku i skutkujący jedynie wpływem na poufność. Własne pole ważności tego wpisu w archiwum ma wartość „high”, podczas gdy WordPress określa tę wadę wsadową jako „critical”; to dwie odrębne skale zastosowane do całego łańcucha i do pojedynczego komponentu, a nie rozbieżność co do samych błędów.

Wpisy katalogu CISA, odzwierciedlone w polach wzbogacania NVD, dodano 21 lipca 2026 r., z terminami remediacji 24 lipca dla CVE-2026-63030 i 4 sierpnia dla CVE-2026-60137. CISA nazywa pierwszą „WordPress Core Interpretation Conflict Vulnerability”, a drugą „WordPress Core SQL Injection Vulnerability”. Searchlight udostępnił również publiczną sprawdzarkę pod adresem wp2shell.com, aby operatorzy mogli przetestować instancję bez oczekiwania na sygnaturę skanera.

Niezależne odtworzenie jest udokumentowane przez sam Searchlight i dlatego stanowi twierdzenie o osobach trzecich, a nie relację osoby trzeciej: według artykułu z 20 lipca Calif i Hacktron odtworzyli pełny łańcuch, zanim na GitHubie pojawiły się inne dowody koncepcji. Niezależnie weryfikowalny jest efekt — dowody koncepcji, ruch związany z wykorzystaniem podatności i telemetria dostawców w ciągu kilku dni, omówione poniżej.

Co się twierdzi, ale czego nie ustalono

Dwa przypisania zasług za jedną iniekcję nie dają się uzgodnić w publicznym zapisie. Komunikat bezpieczeństwa WordPressa dotyczący CVE-2026-60137 stwierdza, że luka została „odkryta i odpowiedzialnie ujawniona jako zespół przez TF1T, dtro i haongo”. Relacja Searchlight przedstawia tę samą iniekcję przed uwierzytelnieniem jako wynik ujawniony przez uruchomienie jej modelu i nie wspomina o tym zespole; komunikat WordPressa przypisuje Kuesowi zasługę wyłącznie w związku z zamieszaniem z trasą wsadową i nie wspomina o modelu. Żaden z dokumentów nie wyjaśnia tej zbieżności, a nic, co ustalił ten artykuł, tego nie rozstrzyga — nie wykluczono możliwości, że były to niezależne odkrycia tego samego błędu, nie ustalono też możliwości, że jedna relacja jest późniejszym ponownym odkryciem. Zapis tego nie rozstrzyga, podobnie jak ten artykuł.

Liczba w nagłówku wpisu Searchlight z 20 lipca nie znajduje potwierdzenia w samej treści. Brzmi on: „Brokerzy exploitów płacą $500,000 za RCE w WordPressie. Znalazłem jedną przy użyciu GPT5.6 Sol Ultra i $25”. Treść dokumentuje $25 i dziesięć godzin w konkretny sposób; nie zawiera żadnych nazw brokerów, żadnych ofert, żadnej korespondencji ani źródła dla kwoty $500,000. Nie znaleziono niezależnego doniesienia związanego z tym tekstem, które potwierdzałoby cenę zapłaconą lub zaoferowaną za wp2shell. Traktuj kwotę $500,000 jako element ujęcia w nagłówku, a nie jako ustaloną cenę rynkową.

Zakres samego wpisu archiwalnego jest węższy niż otaczająca go historia. Wpis rejestruje ustalenie badawcze z dnia ujawnienia, nie sygnalizuje żadnych szkód w świecie rzeczywistym i jest opatrzony datą jednego dnia, 17 lipca 2026 r. To nie jest twierdzenie, że później nic się nie wydarzyło: ruch związany z wykorzystaniem odnotowano w ciągu kilku godzin od wydania ostrzeżenia, a CISA skatalogowała obie podatności CVE cztery dni później. Flaga obejmuje to, co opisuje wpis — odkrycie i skoordynowane ujawnienie — a późniejsze wykorzystanie jest udokumentowane poniżej przez inne strony na podstawie ich własnych dowodów.

Wykorzystanie po publikacji komunikatu doradczego

Jake Knott, główny badacz bezpieczeństwa w watchTowr, powiedział The Hacker News, że „wczesnym rankiem w sobotę (UTC) udana eksploatacja była już w pełnym toku; początkowo wykorzystywano publiczny kod exploitu do eksfiltracji zahaszowanych danych uwierzytelniających, a następnie, gdy ujawniono dodatkowe szczegóły, doszło do zdalnego wykonania kodu”. W tym samym raporcie przywołano telemetrię KEVIntel łączącą 13 unikalnych adresów IP ze Szwajcarii, Niemiec, Wielkiej Brytanii, Indonezji, Litwy, Holandii i Singapuru z eksploatacją CVE-2026-63030, oraz zacytowano założyciela KEVIntel, Ryana Dewhursta, który powiedział, że żądania odpowiadały publicznie dostępnym proof of concept oraz że wykorzystano payloady typu blind, oparte na UNION i oparte na logice boolowskiej.

Badacze z Wiz, Shahar Dorfman i Gili Tikochinski, w publikacji z 20 lipca określili skalę: 60% organizacji korzystających z WordPressa miało co najmniej jedną podatną instancję w momencie publikacji CVE, a 25% wystawiało podatny serwer do internetu; odsetki te spadły do 50% i 10% w ciągu 24 godzin, gdy rozpoczęto łatanie. Zarejestrowali złośliwe przesyłanie wtyczek przez instalator administracyjny, enumerację użytkowników względem punktu końcowego users, próby local file inclusion wymierzone w wp-config, a także dostęp do panelu administracyjnego zwracający HTTP 200 — sygnaturę udanego logowania, a nie sondowania. Znaleziony przez nich złośliwy kod obejmował minimalny jednowierszowy backdoor PHP oraz 150 KB webshell ukryty jako legalna wtyczka bezpieczeństwa WordPressa o nazwie CMSmap, z modułami zarządzania plikami, dostępu do bazy danych, skanowania portów i eskalacji uprawnień.

Wiz odnotował także ograniczenie co do tego, jakie można wyciągać wnioski. Skanowanie o dużym natężeniu bez działań po wykorzystaniu podatności było powszechne, co jest spójne z oportunistycznym masowym skanowaniem oraz z legalnym skanowaniem bezpieczeństwa, a firma oświadczyła, że nie zidentyfikowała ruchu bocznego ani eksfiltracji danych. To stwierdzenie o tym, co pokazała telemetria jednego dostawcy, a nie ustalenie, że nic nie zostało wykradzione.

Co się później zmieniło, a co pozostało otwarte

Dla operatorów ścieżka reakcji była krótka. Rozwiązaniem jest aktualizacja do WordPress 7.0.2, WordPress 6.9.5 lub WordPress 6.8.6. Awaryjne alternatywy Searchlight dla witryn, które nie mogły zaktualizować się natychmiast, polegały na zablokowaniu anonimowego dostępu do interfejsu API wsadowego — albo przez zainstalowanie wtyczki, która całkowicie blokuje anonimowy dostęp do REST API, albo przez zablokowanie /wp-json/batch/v1 i ?rest_route=/batch/v1 na zaporze aplikacji internetowej (WAF). Firma ostrzegła, że oba rozwiązania mogą wpływać na legalne korzystanie z witryny i należy je traktować jako środki tymczasowe do czasu wdrożenia aktualizacji. Publiczny skaner pod adresem wp2shell.com testuje instancję bezpośrednio. Wpisy w katalogu CISA wprowadziły termin zgodności: naprawa do 24 lipca dla CVE-2026-63030 i do 4 sierpnia dla CVE-2026-60137.

Jeśli chodzi o pytanie badawcze, nierozstrzygnięta pozostała kwestia, co model faktycznie wniósł w stosunku do swojego operatora. Kues precyzyjnie określa ten podział: model wytworzył łańcuch w ciągu mniej więcej dziesięciu godzin, a jego zrozumienie zajęło mu więcej czasu niż samo wygenerowanie. Odżegnuje się od ogólnych stwierdzeń i mówi jedynie, że dziesięciogodzinnego wyniku człowiek bez wsparcia nie byłby w stanie osiągnąć. Sam prompt nie jest tajemnicą — wywodzi się z jednego z promptów opublikowanych przez OpenAI, a Searchlight odtworzyło jego strukturę w swoim opisie, w tym polecenie ignorowania historii wersji oraz wymóg, by exploit działał w typowej konfiguracji produkcyjnej. Czy ten przepis sprawdza się w innych bazach kodu — to właśnie pytanie, na które Kues, jak mówi, nie odpowiada, a nie opublikowano żadnego drugiego przebiegu.

To, czego zapis nie ustala, jest zatem wąskie, lecz brzemienne w skutki: który z dwóch uznanych podmiotów jako pierwszy odkrył wstrzyknięcie, czy jakikolwiek broker kiedykolwiek zapłacił kwotę podaną w nagłówku oraz co — jeśli w ogóle cokolwiek — webshelle zaobserwowane przez Wiz faktycznie zabrały z witryn, na których wylądowały. W kwestii ostatniego punktu jedynym publicznym oświadczeniem jest oświadczenie Wiz, że nie zidentyfikowała żadnego ruchu lateralnego ani eksfiltracji danych — brak dowodów z jednej perspektywy, przedstawiony jako taki.