A WordPress kijavított egy előzetes hitelesítés nélküli, visszaverődő cross-site scripting (XSS) sebezhetőséget a bejelentkező felületén, amely a tartalomkezelő rendszer minden verzióját érinti. A pwn.ai bemutatta, hogyan lehet a hibát úgy összefűzni, hogy a szerveren PHP-kód futását érjék el, amikor egy bejelentkezett adminisztrátor egy támadó által irányított oldallal lép interakcióba.

A CVE-2026-64638 azonosítót kapott, 8,9-es CVSS pontszámú, súlyos sebezhetőség kihasználásához a támadónak nincs szüksége jogosultságokra. A hibát felfedező és a technikai részleteket a The Hacker News-szal megosztó pwn.ai szerint a bejelentkező oldal XSS sebezhetősége nem igényel hitelesítést. Ha az ügyesen megfogalmazott felhasználónév eljut a sikertelen bejelentkezést jelző hibaoldalig, az így létrejövő JavaScript a látogató böngészőjében lefut, további interakció nélkül azon az oldalon.

A kódfuttatáshoz vezető lánc olyan áldozatot igényel, aki már adminisztrátorként be van jelentkezve, és kifejezetten interakcióba lép egy támadó által irányított oldallal. A pwn.ai demonstrációjában ez az interakció egyetlen, teljesen hétköznapi kattintás volt.

A kutatók a The Hacker News-nak elmondták, hogy a támadás alapértelmezett WordPress telepítések ellen is működik, és nem igényel szokatlan hoszting- vagy telepítési beállításokat. Több útvonalat is találtak az XSS-től a kódfuttatásig, köztük olyan változatokat, amelyek egy bővítmény telepítésével vagy egy tetszőleges ZIP-fájl feltöltésével érik el a célt.

A WordPress saját figyelmeztetése óvatosabban értékeli a sebezhetőség kihasználhatóságát. Kiemeli, hogy a távoli kódfuttatásra (RCE) való eszkaláció olyan feltételektől függ, amelyek a támadó számára nem irányíthatók, és sikeres social engineeringet, valamint az áldozat kifejezett interakcióját igénylik.

A problémát augusztus 6-án javították a WordPress 7.0.3 kiadásban, a javításokat pedig visszavezették egészen a 4.7-es ágig. A WordPress azonnali frissítést javasol, az automatikus háttérfrissítést támogató oldalaknak pedig automatikusan meg kell kapniuk a security kiadást. A 4.7-nél régebbi verziók továbbra is érintettek, de már nem tartoznak a projekt aktuális visszaportolási körébe.

A kutatók, akik az egész támadási láncot XSS2Shell néven emlegetik, elmondták, hogy autonóm rendszerük fedezte fel és reprodukálta a sebezhetőségi láncot, miután kiindulópontként megkapta Paulos Yibelo 2022-es Same Origin Method Execution (SOME) kutatását.

A cég szerint a munka közel négy napig tartott, nyílt forráskódú modellekkel és több ügynökből álló workflow-val. A láncot július 26-án sikerült reprodukálniuk, és másnap jelentették a WordPressnek.

A hiba onnan indul, ahogyan a WordPress a sikertelen bejelentkezéskor megadott felhasználónevet kezeli. A kutatók szerint az érték először a sanitize_user() és a wp_strip_all_tags() függvényen megy át, utóbbi a PHP strip_tags() függvényére támaszkodik. Egy olyan, tag-szerű szöveg, amelyben a nyitó < jel után szóköz szerepel, ezen az elemzőn szövegként átcsúszhat. Később a WordPress a wp_kses_post() függvényen is átengedi az értéket, amelynek külön parser-e ugyanazt a bemenetet engedélyezett HTML-ként értelmezi. Így a sikertelen bejelentkezési oldalon támadó által vezérelt, élő DOM-elemek jelenhetnek meg.

Ezek az elemek ezután kölcsönhatásba lépnek a WordPress saját user-profile.js állományával, egy profilkezelő script-tel, amely a jelszó-visszaállítás miatt a bejelentkező oldalon is betöltődik.

A script által várt egyes profil-elemek ezen az oldalon hiányoznak: két hiányzó input is undefined értékre fut ki, ami miatt egy egyenlőségvizsgálat átmehet, miközben a normál esetben undefined ajaxurl változót egy befecskendezett DOM-elemmel felül lehet írni. Így a WordPress saját JavaScriptje egy támadó által választott, azonos eredetű REST kérés felé terelhető.

A kutatók a WordPress REST JSONP támogatását használják fel arra, hogy ebből a kérésből olyan JavaScript legyen, amely a webhely eredetén fut. Azoknál a telepítéseknél, ahol a névtelen REST kérések HTTP 401 választ adnak, az _envelope=1 paraméter a megtagadást egy külső HTTP 200 válaszba csomagolhatja, így a jQuery továbbra is scriptként dolgozza fel a választ.

A tesztek során azt is megállapították, hogy egy nonce-alapú, strict-dynamic direktívát használó Content Security Policy sem blokkolta a bemutatott támadási útvonalat.

Az XSS-től a PHP-kódfuttatásig vezető lánc Yibelo korábbi SOME technikájára épül, amely egy engedélyezett JSONP property-láncot használ fel arra, hogy egy másik böngészőablakban metódust hívjon meg.

A pwn.ai által bemutatott egyik útvonal a WordPress-eredetű XSS-t használja arra, hogy egy bejelentkezett adminisztrátor munkamenetében meghívja a natív Application Password jóváhagyó vezérlőt. A WordPress ezután létrehoz egy API-hitelesítési adatot, és átirányítja azt egy támadó által választott HTTPS success_url címre.

Az Application Passwords visszavonható, API-hozzáférésre szánt hitelesítési adatok, ezért ezen az útvonalon nincs szükség az adminisztrátor elsődleges jelszavának ellopására. A kutatók ezt a hitelesítési adatot használták fel hitelesített REST hozzáféréshez, hogy közzétegyenek egy WordPress oldalt, amely azonos eredetű JavaScriptet tartalmazott. Amikor a még érvényes adminisztrátori munkamenet megnyitotta az oldalt, a script megszerezte a WordPress plugin-feltöltési nonce értékét, és feltöltött egy támadó által készített ZIP-et. A kicsomagolt pluginból közvetlenül lehetett PHP-t kérni. A plugint nem kellett aktiválni.

A The Hacker Newsnak átadott, éles környezetből származó bizonyíték az XSS-nél megáll. A kutatók külön is reprodukálták a sütik nélküli, bejelentkező oldali XSS-t két WordPress 7.0.2 telepítésen, friss Chrome profilokkal, WordPress sütik és hitelesítési adatok nélkül.

A kutatók ezeken a rendszereken nem próbáltak Application Passwordöt létrehozni, fájlokat feltölteni, tartós jelenlétet kiépíteni vagy PHP-kódot futtatni. A teljes, PHP-futtatásig tartó láncot külön, egy tiszta, helyi WordPress 7.0.2 telepítésen mutatták be.

Hangsúlyozták, hogy a WordPress ismert megerősítési lépései önmagukban nem jelentik a mögöttes XSS teljes kivédését, ezért mindenképpen szükséges a biztonsági frissítés telepítése.

Egy sikeres PHP-kódfuttatás felfedné a WordPress adatbázis-hitelesítési adatait a wp-config.php fájlban, lehetővé tenné tartós adminisztrátori fiók létrehozását és a tartalom módosítását, hozzáférést adna a PHP worker által olvasható fájlokhoz és titkokhoz, és operációs rendszer szintű parancsok futtatását tenné lehetővé a worker jogosultságaival.

WordPress a pwn.ai csapatát ismerte el a sebezhetőség felfedezéséért és felelős bejelentéséért. Augusztus 7-ig a projekt biztonsági közleménye nem számolt be arról, hogy a hibát aktívan kihasználnák.