Różnica w parsowaniu HTML może doprowadzić do RCE w WordPressie

WordPress to ta część świata oprogramowania open source, o której na sekuraku piszemy na tyle regularnie, że tym razem już darujemy Wam fragment o tym, jak ważny jest to projekt dla całego internetu. Powodem dzisiejszego wpisu jest łańcuch drobnych błędów zaczynający się od XSS, a po spełnieniu określonych warunków kończący się możliwością zdalnego wykonania kodu (RCE). Podatność otrzymała identyfikator CVE-2026-64638 oraz wysoką ocenę 8.9 w CVSS 4.0 (CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H). Zaklasyfikowana została jako CWE-79.

TLDR:

• Pozornie niewinny łańcuch drobnych podatności może doprowadzić do uzyskania uprawnień administratora, a ostatecznie także do możliwości wykonania kodu po stronie serwera.
• Drobne różnice w parsowaniu kodu HTML na różnych etapach logowania otwierają drogę do pozornie niewinnego, ale po spełnieniu określonych warunków skutecznego łańcucha ataku. Atakujący nie musi posiadać konta w WordPressie. Pełny łańcuch prowadzący do RCE wymaga jednak interakcji zalogowanego administratora podatnej instancji dla RCE. 

Gdy użytkownik podaje nazwę użytkownika i hasło za pomocą pliku wp-login.php, WordPress wywołuje wp_signon(), który następnie wywołuje wp_authenticate(). Jeśli nazwa użytkownika nie istnieje, wp_authenticate_username_password() generuje komunikat błędu w wp-includes/user.php. Przesłana nazwa użytkownika jest umieszczana bezpośrednio w kodzie HTML za pomocą sprintf. W tym momencie zmienna $username przechodzi przez sanitize_user() w trybie nieścisłym, który wywołuje wp_strip_all_tags(). Ścieżka ta opiera się o strip_tags(). Oznacza to, że niektóre konstrukcje z odstępem po znaku < nie są przez ten etap traktowane jak prawdziwy tag HTML. Taki ciąg danych trafia następnie do KSES, autorskiego silnika WordPressa do oczyszczania kodu HTML. Jak zwracają uwagę badacze z pwn.ai, posiada on całkowicie odrębny tokenizer. KSES obsługuje odstępy między nazwami < tagów a ich nazwami. W praktyce oznacza to, że dla KSES < area> jest prawidłowym elementem <area>. To wszystko sprawia, że dane, które początkowo traktowane są jako zwykły tekst, w kolejnym etapie mogą zostać potraktowane jako prawidłowy element HTML.

Prezentacja łańcucha ataku.

Samo wstrzyknięcie HTML nie prowadzi jeszcze do wykonania kodu. Ważny jest następny krok. Na stronie logowania WordPress ładuje skrypt user-profile.js, który m.in. obsługuje ścieżkę resetowania hasła. Z obserwacji pwn.ai wynika, że skrypt ten zakłada obecność elementów, które normalnie występują w innych częściach panelu WordPressa. To pozwala atakującemu wykorzystać DOM clobbering. Dzięki temu skrypt próbuje odwoływać się do elementów takich jak przycisk generowania hasła czy pola związane z resetowaniem hasła. Jeśli atakującemu uda się wstrzyknąć odpowiednią zawartość HTML, strona zaczyna zachowywać się tak jakby elementy te naprawdę istniały.

Z opisu pwn.ai wynika, że możliwa jest także podmiana ajaxurl przez element HTML o takim samym identyfikatorze. Takie elementy mogą być dostępne przez window, a jQuery może potraktować obiekt jak adres URL. Finalnie żądanie AJAX może zostać wysłane tam, gdzie chce atakujący, co otwiera drogę do kolejnego etapu ataku w obrębie orygina WordPressa. Ostatecznie na tym etapie ataku możliwe jest już nie tylko wstrzyknięcie HTML, ale także wykonanie kodu JavaScript w kontekście WordPressa. Co istotne, samo wykonanie JavaScript w oryginie WordPressa w dalszym ciągu nie oznacza możliwości zdalnego wykonania kodu na samym serwerze. Do tego, aby kolejny etap ataku mógł zakończyć się sukcesem potrzebne jest wywołanie window.opener.approve.click oraz zalogowane konto administratora. Dostęp do ekranu Application Password umożliwia wygenerowanie tokenu dla konta administratora. Tak wygenerowany token daje dostęp do WordPress API. W scenariuszu opisanym przez badaczy umożliwia to wykonywanie działań administracyjnych, a także wykonanie dowolnego kodu po stronie serwera.

Ciekawostką może być fakt, że z deklaracji badaczy wynika, iż łańcuch ataku został odkryty przez autonomiczny system pwn.ai opierając się na wynikach badań Paulosa Yibelo z 2022 roku dotyczących metody Same Origin Execution (SOME). Prace miały potrwać 4 dni, podczas których korzystano z modeli open source i multi-agent workflow.

Problem został naprawiony 6 sierpnia w wersji 7.0.3, a poprawki zostały przeniesione wstecz aż do gałęzi 4.7. WordPress zaleca natychmiastową aktualizację. Instancje obsługujące automatyczne aktualizacje powinny automatycznie otrzymać aktualizację zabezpieczeń. Gałęzie starsze niż 4.7 również są dotknięte podatnością, jednak z racji braku wsparcia nie otrzymają stosownych poprawek bezpieczeństwa. Podatność została nazwany przez badaczy XSS2Shell. Jak dotychczas nie są znane przypadki aktywnego wykorzystania. Warto zapoznać się ze szczegółowym raportem na stronie pwn.ai oraz z opisem wydania na stronie projektu.

~pu