Форма входа WordPress содержала критическую уязвимость, которая позволяла преобразовать несостоявшуюся попытку входа в выполнение вредоносного JavaScript-кода на веб-сайте. При определенных обстоятельствах атаковавший мог добиться запуска PHP-кода на хостинге. Разработчики WordPress устранили проблему в обновлении версии 7.0.3 и настоятельно рекомендуют администраторам незамедлительно обновить свои сайты.
Уязвимость зарегистрирована под номером CVE-2026-64638 и получила оценку опасности 8,9 балла по системе CVSS. Проблема классифицируется как отраженная XSS и находится в самой форме входа WordPress. Для запуска вредоносного кода злоумышленнику не требуется учетная запись на целевом сайте. Исследователи из pwn.ai представили еще более серьезный сценарий атаки XSS2Shell, который при наличии дополнительных условий дает возможность выполнить PHP-код на сервере.
Уязвимость возникла из-за несогласованной обработки одной и той же входной строки различными компонентами WordPress. При неудачной попытке входа система повторяет введенное имя пользователя в сообщении об ошибке. Перед отображением строка обрабатывается несколькими фильтрами, в том числе встроенной PHP-функцией strip_tags() и системой защиты KSES от WordPress.
Специалисты выяснили, что строка с пробелом после символа «<» проходит первый фильтр без изменений, как обычный текст. Второй парсер расценивает эту же последовательность символов как допустимый HTML-код. В результате злоумышленнику удается внедрить собственные элементы в структуру страницы входа, хотя непосредственная вставка тега script заблокирована.
Затем в действие вступает неожиданная особенность WordPress. На странице входа активируется скрипт user-profile.js, который обычно управляет элементами учетного профиля и функциями восстановления пароля. Созданные злоумышленником HTML-элементы заставляют стандартный JavaScript WordPress отправить запрос на произвольный адрес. Благодаря REST API и поддержке JSONP исследователям удалось превратить такой запрос в выполнение JavaScript-кода в контексте целевого сайта.
Сама по себе XSS-уязвимость не гарантирует полный контроль над сервером. Для достижения выполнения PHP-кода исследователям потребовалось участие администратора WordPress, который авторизован и посещает страницу под контролем атакующего. В их демонстрации было достаточно одного простого клика мышью.
Затем вредоносная страница задействует встроенный в WordPress механизм Application Passwords и побуждает браузер администратора выдать отдельный пароль для работы с API. Злоумышленник получает такой ключ доступа, размещает через REST API страницу с вредоносным кодом, а потом использует активный сеанс администратора для получения nonce и загрузки ZIP-файла с плагином. PHP-файл в загруженном плагине может быть вызван напрямую, без необходимости его активировать.
Команда WordPress отмечает, что преобразование XSS в удаленное выполнение кода зависит от нескольких предварительных условий, которые атакующий не может гарантировать заранее. Жертва должна иметь активный административный сеанс и взаимодействовать с вредоносной страницей. По этой причине CVE-2026-64638 нельзя полностью отнести к pre-auth RCE, несмотря на то, что первоначальная XSS действительно не требует входа в систему.
Уязвимость была обнаружена системой pwn.ai, которая использует несколько ИИ-модулей и открытые нейросетевые архитектуры. Разработчики предоставили системе исследование методики Same Origin Method Execution 2022 года в качестве отправной точки. По сообщению pwn.ai, поиск и полная разработка цепочки атаки заняла почти четыре дня. Уязвимость была подтверждена 26 июля, о проблеме сообщено команде WordPress 27 июля, а 6 августа команда выпустила патч.
Исследователи протестировали XSS на двух реальных инсталляциях WordPress версии 7.0.2 без входа в систему. Полную цепочку до выполнения PHP-кода исследователи воспроизводили только в собственной контролируемой среде и не попытались атаковать сторонние серверы. На 7 августа информация об активной эксплуатации CVE-2026-64638 отсутствует.
Исправление вошло в обновление WordPress 7.0.3. Разработчики также применяют патч к старым версиям, которые еще получают обновления безопасности, вплоть до WordPress 4.7. Владельцы сайтов с включенными фоновыми автоматическими обновлениями должны получить патч самостоятельно, но WordPress рекомендует проверить номер версии вручную и не откладывать обновление.
