WordPress коригира уязвимост от тип отразена междусайтова застъпваща се атака (reflected XSS) преди автентикация в своя екран за влизане, която засяга всички версии на системата за управление на съдържанието. От pwn.ai демонстрираха как уязвимостта може да бъде свързана в рамките на верига от атаки до изпълнение на PHP код на сървъра, когато влязъл в профила си администратор си взаимодейства със страница, контролирана от атакуващия.
Проследявана като CVE-2026-64638 (CVSS оценка: 8.9), тази уязвимост с висока степен на сериозност не изисква никакви привилегии от страна на атакуващия. Според pwn.ai, които откриха уязвимостта и споделиха технически детайли с „The Hacker News“, тази XSS уязвимост на страницата за влизане не изисква автентикация. След като специално разработено потребителско име достигне страницата за грешка при неуспешно влизане, генерираният JavaScript се изпълнява в браузъра на посетителя без необходимост от допълнително взаимодействие на тази страница.
Пътят за изпълнение на код изисква жертвата вече да е влязла като администратор и да извърши експлицитно взаимодействие със страница, контролирана от атакуващия. В демонстрацията на pwn.ai това взаимодействие е едно обикновено кликване.
Изследователите споделиха пред „The Hacker News“, че атаката работи срещу стандартни инсталации на WordPress и не изисква необичайни хостинг или конфигурационни настройки. Те заявиха, че разполагат с множество пътища от XSS до изпълнение на код, включително варианти, които инсталират плъгин или качват произволен ZIP архив.
В собственото становище на WordPress се изразява по-предпазливо виждане относно възможността за експлоатация, като се отбелязва, че ескалацията до отдалечено изпълнение на код (RCE) включва условия извън контрола на атакуващия и изисква успешно социално инженерство плюс изрично взаимодействие от страна на жертвата.
Проблемът беше коригиран на 6 август в WordPress 7.0.3, като корекциите за сигурност бяха пренесени и към по-старите версии до клон 4.7. WordPress препоръчва незабавно обновяване, а сайтовете, които поддържат автоматични фонови актуализации, трябва да получат защитната версия автоматично. Версиите, по-стари от 4.7, остават засегнати, но попадат извън текущия обхват на поддръжка за обратна съвместимост на проекта.
Изследователите, които наричат веригата от атаки „XSS2Shell“, заявиха, че тяхната автономна система е открила и възпроизвела веригата от уязвимости, след като е получила изследването на Паулос Йибело от 2022 г. относно Изпълнение на методи от същия произход (SOME) като начална точка.
Компанията заяви, че работата е отнела близо четири дни с използване на модели с отворен код и работен процес с множество агенти. Веригата е била възпроизведена на 26 юли и докладвана на WordPress на следващия ден.
Слабостта започва от начина, по който WordPress обработва потребителското име при неуспешно влизане. Според изследователите стойността преминава през sanitize_user() и wp_strip_all_tags(), която разчита на PHP функцията strip_tags(). Символен низ, наподобяващ таг и съдържащ празно пространство след отварящото „<“, може да оцелее в този парсер като обикновен текст. По-късно WordPress предава стойността на wp_kses_post(), чийто отделен парсер интерпретира същия вход като разрешен HTML. Резултатът е контролирани от атакуващия активни DOM елементи на страницата за неуспешно влизане.
Тези елементи след това взаимодействат с файла user-profile.js на WordPress – скрипт за управление на профили, който също се зарежда на страницата за влизане, тъй като тя обработва възстановяването на пароли.
Някои профилни елементи, които скриптът очаква, липсват там: две липсващи полета за въвеждане се оценяват като undefined, което позволява на проверката за равенство да премине успешно, докато иначе недефинираната променлива ajaxurl може да бъде презаписана с инжектиран DOM елемент. Това насочва собствения JavaScript на WordPress към избрана от атакуващия REST заявка от същия произход (same-origin).
Изследователите използват JSONP поддръжката за REST в WordPress, за да превърнат тази заявка в JavaScript, изпълняващ се в контекста на сайта. За среди, където анонимните REST заявки връщат HTTP 401, параметърът _envelope=1 може да обвие отказа във външен HTTP 200 отговор, позволявайки на jQuery да продължи обработката на отговора като скрипт.
При тестването изследователите също така установиха, че политика за сигурност на съдържанието (CSP), базирана на еднократни кодове (nonce) с директива strict-dynamic, не блокира демонстрирания път.
Пътят от XSS до изпълнение на PHP се основава на по-ранната SOME техника на Йибело, която използва разрешена верига от JSONP свойства за извикване на метод в друг прозорец на браузъра.
Един от демонстрираните от pwn.ai пътища използва XSS уязвимостта с произход от WordPress за извикване на вградения контрол за одобрение на приложни пароли (Application Password) в рамките на сесията на влязъл в системата администратор. След това WordPress създава идентификационни данни за API и ги пренасочва към избран от атакуващия HTTPS success_url.
Приложните пароли са оттегляеми идентификационни данни, предназначени за API достъп, така че този път не изисква кражба на основната парола на администратора. Изследователите са използвали тези данни за оторизиран REST достъп, за да публикуват WordPress страница, съдържаща JavaScript от същия произход. Когато запазената администраторска сесия отвори тази страница, нейният скрипт придобива еднократния код (nonce) за качване на плъгини в WordPress и качва предоставен от атакуващия ZIP файл. След това PHP кодът може да бъде извикан директно от разархивирания плъгин. Не е необходимо плъгинът да бъде активиран.
Предоставените доказателства за „The Hacker News“ спират до XSS уязвимостта. Изследователите отделно са възпроизвели XSS уязвимостта на страницата за влизане без бисквитки срещу две инсталации на WordPress 7.0.2 в чисти Chrome профили без бисквитки или идентификационни данни за WordPress. Те не са направили опит за приложни пароли в тези тестове.