WordPress закрыл XSS во всех версиях CMS с риском эскалации до PHP
WordPress выпустил обновление безопасности для CVE-2026-64638 — отражённой XSS-уязвимости на странице входа, затрагивающей все версии CMS. Проблема получила 8,9 балла по CVSS и не требует от атакующего учётной записи. При дополнительном наборе условий исследователи pwn.ai продемонстрировали цепочку, которая может привести к выполнению PHP-кода на сервере.
Исправление вышло 6 августа в WordPress 7.0.3 и было перенесено в поддерживаемые ветки вплоть до 4.7. Сайты с включёнными автоматическими фоновыми обновлениями должны получить релиз самостоятельно. Версии старше 4.7 остаются подвержены ошибке, поскольку не входят в текущий диапазон бэкпортов.
Как возникает XSS на странице входа
Уязвимость проявляется при обработке имени пользователя после неудачной попытки входа. По описанию pwn.ai, значение проходит через sanitize_user() и wp_strip_all_tags(), использующий PHP-функцию strip_tags(). Строка, похожая на тег, но содержащая пробел после символа «<», может сохраниться как текст.
Позднее тот же ввод передаётся в wp_kses_post(), где другой разборщик воспринимает его как разрешённый HTML. Это позволяет создать управляемые DOM-элементы на странице неудачного входа. Далее в цепочке участвует штатный скрипт WordPress user-profile.js, который загружается на этой странице для поддержки сброса пароля.
Исследователи описали возможность подменить значение ajaxurl через внедрённый DOM-элемент и направить штатный JavaScript на выбранный same-origin REST-запрос. Поддержка REST JSONP затем используется для исполнения JavaScript в контексте сайта. Параметр _envelope=1 помогает обработать ответ как скрипт в конфигурациях, где анонимные REST-запросы возвращают HTTP 401.
Почему выполнение PHP возможно не на каждом сайте
Полная цепочка, названная pwn.ai XSS2Shell, была показана на чистой локальной установке WordPress 7.0.2. В производственной среде исследователи подтвердили только XSS на двух развёртываниях WordPress 7.0.2 в чистых профилях Chrome, без cookies и учётных данных. Создание Application Password, загрузку файлов, закрепление и запуск PHP на этих сайтах они не выполняли.
Для эскалации необходим уже авторизованный администратор одиночного сайта, который перейдёт по контролируемой атакующим странице. Также требуются Application Passwords, введённые в WordPress 5.6, права unfiltered_html и upload_plugins, доступная для записи директория плагинов и отсутствие ограничений на изменение файлов либо прямой запуск PHP из каталогов неактивных плагинов.
В ходе демонстрации XSS открывала в сессии администратора интерфейс одобрения Application Password. Полученные API-учётные данные использовались для публикации страницы и загрузки ZIP-архива плагина. Активация плагина для прямого запроса к извлечённому PHP-файлу не требовалась. Отключение Application Passwords ломает именно этот путь эскалации, но не устраняет первичную XSS.
Что проверить владельцам сайтов
Уязвимость дополняет тему рисков WordPress core, где анонимные точки входа WordPress core показывает, почему анонимные точки входа требуют приоритетного обновления и пересмотра защитных настроек. WordPress не сообщал об эксплуатации CVE-2026-64638 в реальных атаках по состоянию на 7 августа.
Бизнесу следует без промедления установить WordPress 7.0.3 или актуальный патч своей поддерживаемой ветки, а для устаревших установок спланировать обновление. Дополнительно стоит проверить, нужны ли Application Passwords, кто обладает правом загрузки плагинов, доступны ли каталоги плагинов для записи и применяются ли ограничения на изменение файлов и исполнение PHP. Эти меры не заменяют обновление, но сокращают условия для продемонстрированной эскалации.