AI znalazła XSS2Shell w WordPressie. Jedna spacja otwierała drogę do serwera

System agentowy pwn.ai odnalazł w rdzeniu WordPressa nieznany wcześniej łańcuch podatności, który zaczynał się od nietypowego XSS na stronie logowania, a w sprzyjających warunkach kończył wykonaniem kodu PHP na serwerze. Błąd otrzymał identyfikator CVE-2026-64638 i ocenę 8,9/10. Najciekawsze nie jest jednak samo XSS, lecz to, że droga do przejęcia serwera powstała z połączenia kilku pozornie niegroźnych zachowań aplikacji — a pwn.ai twierdzi, że cały łańcuch zbudowały autonomicznie agenty AI.

WordPress potwierdził podatność i 6 sierpnia 2026 roku wydał poprawkę w wersji 7.0.3. Łatki trafiły także do starszych utrzymywanych gałęzi, aż do 4.7. Administratorzy nie powinni jednak mylić tego ataku z ujawnionym wcześniej łańcuchem wp2shell, również odkrytym z pomocą AI. To odrębna podatność, inny mechanizm i inne warunki wykorzystania.

XSS2Shell w skrócie

Oficjalny advisory WordPressa precyzyjnie opisuje ograniczenie, które łatwo zgubić w alarmistycznym nagłówku: atakujący nie potrzebuje własnego konta, aby uruchomić XSS, ale pełne przejście do RCE wymaga socjotechniki i wyraźnej interakcji ofiary. Nie jest to zatem bezwarunkowe „wyślij jedno żądanie i przejmij dowolny serwer”.

Jedna spacja rozdzieliła dwa mechanizmy ochronne

Źródło problemu znajdowało się w obsłudze błędnego loginu. Po próbie zalogowania na nieistniejącego użytkownika WordPress umieszczał podaną nazwę w komunikacie błędu. Dane przechodziły kolejno przez dwa mechanizmy oczyszczania: funkcję PHP strip_tags() oraz wordpressowy filtr KSES.

Oba parsery nie zgadzały się co do tego, czym jest znacznik HTML. Wystarczyła spacja po znaku otwierającym, aby pierwszy mechanizm potraktował fragment jako zwykły tekst. KSES normalizował ten sam zapis i rozpoznawał go jako dozwolony element HTML. W efekcie atakujący mógł doprowadzić do powstania kontrolowanych przez siebie elementów DOM w obrębie strony logowania.

To nadal nie oznaczało wykonania JavaScriptu. Przełomem okazał się kod, który WordPress już sam ładował na tej stronie. Skrypt przeznaczony m.in. do obsługi resetowania hasła szukał określonych elementów interfejsu i automatycznie wywoływał na nich akcje. Wstrzyknięte elementy mogły podszyć się pod oczekiwaną strukturę strony. Dalej łańcuch wykorzystywał DOM clobbering, odpowiedź JSONP z REST API oraz technikę Same Origin Method Execution.

W praktyce niebezpieczeństwo wynikało więc nie z jednej oczywistej instrukcji, lecz z nieoczekiwanej współpracy kilku prawidłowo działających komponentów. strip_tags(), KSES, jQuery, publiczny REST API i strona autoryzacji haseł aplikacyjnych były bezpieczne w swoich typowych rolach. Dopiero połączenie ich zachowań utworzyło ścieżkę ataku.

Od XSS do konta administratora i kodu PHP

Opis techniczny pwn.ai przedstawia pięcioetapowy łańcuch. Atakujący przygotowuje zewnętrzną stronę i skłania zalogowanego administratora docelowego WordPressa do jej odwiedzenia. Strona otwiera pomocnicze okno, a główne kieruje do wbudowanego w WordPressa formularza autoryzacji hasła aplikacyjnego.

Podatność na stronie logowania pozwala następnie wykonać akcję w kontekście domeny WordPressa. Za pomocą techniki SOME kod uruchomiony w jednym oknie może wywołać kliknięcie przycisku zatwierdzającego w drugim. WordPress tworzy wtedy hasło aplikacyjne administratora i przekazuje je pod adres kontrolowany przez atakującego.

Takie hasło daje dostęp do REST API z uprawnieniami właściciela konta. Badacze pokazali, że można go użyć do opublikowania strony zawierającej skrypt, a następnie — już w sesji administratora — pobrać formularz instalacji wtyczki, odczytać token zabezpieczający i przesłać archiwum ZIP z plikiem PHP. Plik umieszczony w katalogu wtyczek może być dostępny bezpośrednio z internetu, nawet bez aktywowania wtyczki.

To właśnie ostatni krok zmienia XSS w RCE, czyli zdalne wykonanie kodu. Wymaga jednak, by ofiara była zalogowanym administratorem i miała uprawnienia do instalowania wtyczek. W sieci multisite albo w środowisku, w którym te uprawnienia ograniczono, pełny łańcuch może się zatrzymać wcześniej.

Co dokładnie zrobiła sztuczna inteligencja?

pwn.ai opisuje swój system jako grupę agentów zdolnych do rozpoznania aplikacji, testowania hipotez i łączenia słabości w działające exploity. Według firmy system otrzymał jako punkt startowy opublikowaną w 2022 roku technikę SOME. Następnie przez niemal cztery dni, korzystając z modeli open source, miał samodzielnie opracować pełny łańcuch niezależny od pierwotnego scenariusza obejścia Content Security Policy.

WordPress w komunikacie o wersji 7.0.3 przypisuje zgłoszenie zespołowi pwn.ai i potwierdza możliwość przejścia od XSS do wykonania kodu PHP. Nie weryfikuje jednak publicznie, jaka część procesu była autonomiczna. Sama firma nie ujawniła nazw użytych modeli, promptów, konfiguracji agentów, kosztu obliczeń ani pełnych logów przebiegu badań.

Dlatego najuczciwszy wniosek brzmi: techniczny rezultat jest potwierdzony, lecz deklaracja o pełnej autonomii pozostaje twierdzeniem pwn.ai. Wiemy również, że AI nie zaczynała od pustej kartki — dostała wartościową technikę badawczą i jasno wyznaczony cel. Nie umniejsza to wyniku. Pokazuje raczej, gdzie obecnie leży przewaga agentów: w wielodniowym, systematycznym sprawdzaniu kombinacji, które dla człowieka byłyby bardzo czasochłonne.

Podobny kierunek widać już poza WordPressem. Anthropic i Mozilla informowały wcześniej, że AI wykrywała krytyczne błędy w Firefoksie, a narzędzia takie jak Claude Code Security próbują automatyzować analizę kodu pod kątem podatności. XSS2Shell jest szczególnie wymowny, bo wymagał nie tylko znalezienia błędu, ale też połączenia zachowań wielu warstw aplikacji i przeglądarki.

Które wersje WordPressa są bezpieczne?

Główna poprawiona wersja to WordPress 7.0.3. Łata została również przeniesiona do każdej utrzymywanej gałęzi od 6.9 aż do 4.7. Przykładowo bezpieczne wydania to 6.9.6, 6.8.7, 6.7.6, 6.6.6, 6.5.9, 6.4.9 oraz 4.9.30 i 4.7.34. Pełna lista znajduje się w oficjalnym advisory.

Najprostsza i zalecana ścieżka to aktualizacja do najnowszego WordPressa. Backport nie oznacza, że kilkuletnia gałąź staje się w pełni wspierana. Sam projekt podkreśla, że aktywnie wspiera wyłącznie najnowszą wersję, a poprawki dla starszych wydań są rozwiązaniem przejściowym.

Co powinien zrobić administrator?

• Natychmiast zaktualizować rdzeń WordPressa do 7.0.3 lub odpowiedniej poprawionej wersji swojej gałęzi.
• Sprawdzić hasła aplikacyjne administratorów i unieważnić każde, którego pochodzenia nie można potwierdzić.
• Przejrzeć konta i wtyczki pod kątem nowych, nieautoryzowanych pozycji oraz nieznanych plików PHP.
• Przeszukać logi pod kątem nietypowych żądań POST do wp-login.php i wywołań REST API z parametrem _jsonp.
• Ograniczyć możliwość instalowania wtyczek do rzeczywiście potrzebnych kont i rozważyć blokadę modyfikacji plików z panelu.
• Nie używać stale tej samej sesji administratora do zwykłego przeglądania internetu; codzienną pracę redakcyjną wykonywać na koncie z mniejszymi uprawnieniami.

Jeżeli istnieją oznaki wykorzystania podatności, sama aktualizacja nie wystarczy. Należy potraktować incydent jak potencjalne przejęcie serwera: zabezpieczyć logi, zmienić poświadczenia, odtworzyć integralność plików i bazy danych oraz sprawdzić mechanizmy trwałości pozostawione przez napastnika.

Najważniejsza lekcja nie dotyczy tylko WordPressa

XSS2Shell pokazuje dwa równoległe zjawiska. Po pierwsze, dojrzałe oprogramowanie może przez lata zawierać błąd wynikający z różnicy między parserami, mimo wielu audytów i ogromnej liczby użytkowników. Po drugie, agenty AI zaczynają być przydatne nie tylko jako szybsze wyszukiwarki podejrzanych linii kodu. Mogą długo eksplorować aplikację, budować hipotezy i szukać sposobu na połączenie kilku słabości w jeden praktyczny atak.

To dobra wiadomość dla obrońców, o ile takie systemy działają w kontrolowanych programach badawczych i odpowiedzialnie zgłaszają wyniki. Jest też oczywistym ostrzeżeniem: ta sama automatyzacja obniża koszt tworzenia exploitów po stronie atakujących. W przypadku XSS2Shell poprawka już istnieje, więc najważniejszą decyzją nie jest dziś ocena marketingowych deklaracji pwn.ai, lecz szybkie zamknięcie znanej ścieżki ataku.