Уязвимость CVE-2026-64638 находится на экране входа WordPress и получила 8,9 балла CVSS при уровне опасности «высокий». Это отражённая XSS, срабатывающая до аутентификации: злоумышленнику не нужны учётная запись или какие-либо права. Ошибка затрагивает все версии WordPress, хотя исправления выпущены лишь для веток начиная с WordPress 4.7. Компания назвала полную цепочку атаки XSS2Shell, поскольку браузерная инъекция при дополнительных условиях заканчивается выполнением PHP-кода на сервере.
Точкой входа служит имя пользователя, специально подготовленное и отправленное через форму авторизации. После неудачного входа WordPress показывает это значение на странице ошибки. Оно последовательно проходит через sanitize_user(), wp_strip_all_tags() и лежащую в основе последней функции PHP strip_tags(), а позднее обрабатывается wp_kses_post(). Проблема кроется в разном понимании одной строки двумя парсерами. Конструкция, похожая на тег и содержащая пробел после открывающего символа «<», переживает strip_tags() как текст, но wp_kses_post() уже распознаёт её как допустимый HTML. В результате на странице появляются управляемые атакующим DOM-элементы, и JavaScript выполняется в контексте домена сайта. После открытия страницы с ошибкой дополнительных действий на ней не требуется.
Инъекция использует штатный скрипт WordPress user-profile.js. Он предназначен для управления профилем, но загружается и на странице входа из-за размещённой там функции сброса пароля. Часть элементов профиля на этой странице отсутствует, поэтому два ожидаемых поля ввода получают значение undefined. Проверка их равенства проходит, хотя разработчики явно рассчитывали на другой сценарий. Затем внедрённый элемент подменяет через DOM clobbering обычно неопределённую переменную ajaxurl. После такой подмены собственный JavaScript WordPress отправляет выбранный атакующим REST-запрос внутри того же источника.
Для превращения REST-ответа в исполняемый сценарий применила поддержку JSONP в WordPress. Даже конфигурации, возвращающие анонимному клиенту HTTP 401 Unauthorized, не всегда останавливают цепочку. Параметр _envelope=1 помещает отказ во внешнюю оболочку с кодом HTTP 200 OK, после чего jQuery продолжает обрабатывать ответ как скрипт. Не спасла испытанная исследователями и nonce-политика Content Security Policy с директивой strict-dynamic. Этот путь развивает технику Same Origin Method Execution, или SOME, которую Paulos Yibelo описал в 2022 году: разрешённая цепочка свойств JSONP позволяет вызвать метод в другом окне браузера.
Само XSS не требует входа, но переход к выполнению PHP заметно сложнее. Жертва должна быть авторизована в WordPress с правами Administrator, открыть контролируемую атакующим страницу и совершить явное действие. В демонстрации хватало одного обычного щелчка. Исследователи утверждают, что цепочка работает на стандартной установке без редкой серверной конфигурации и допускает несколько маршрутов, включая установку плагина и загрузку произвольного ZIP-архива. WordPress формулирует риск осторожнее: успешная эскалация зависит от социальной инженерии и обстоятельств, которыми атакующий управляет не полностью.
Один показанный маршрут использовал WordPress Application Passwords. XSS из источника WordPress обращался к штатному элементу подтверждения Application Password в активной административной сессии. Сайт создавал отзывной API-пароль и перенаправлял его на заданный злоумышленником HTTPS-адрес success_url. Основной пароль администратора при этом красть не требовалось. Полученная учётная информация давала аутентифицированный доступ к WordPress REST API.
Через API исследователи публиковали страницу WordPress с JavaScript того же источника и заставляли ещё активную сессию администратора открыть её. Скрипт извлекал n необходимый для загрузки плагина, после чего на сервер отправлялся подготовленный ZIP-архив. Существенная деталь: вредоносный плагин не надо было активировать. PHP-файл вызывался напрямую из каталога, куда WordPress распаковал архив. Такой доступ позволяет прочитать реквизиты базы данных из wp-config.php, создать постоянные административные учётные записи, менять материалы сайта, просматривать доступные процессу PHP файлы и секреты, запускать команды операционной системы с правами PHP-процесса и закрепляться посредством серверного кода.
Автономная система нашла и воспроизвела цепочку, взяв за отправную точку исследование SOME Паулоса Йибело. По данным компании, работа заняла почти четыре дня; в ней использовались модели ИИ с открытым исходным кодом и многоагентный процесс. Технические материалы передали изданию The Hacker News. При этом доказательства с реальных систем ограничивались начальной XSS: её повторили на двух развёртываниях WordPress 7.0.2 в свежих профилях Chrome без cookies WordPress и без учётных данных.
На этих двух системах исследователи не создавали Application Passwords, не загружали файлы, не закреплялись и не запускали PHP. Полную XSS2Shell-цепочку отдельно показали на чистой локальной установке WordPress 7.0.2. Такое разделение существенно для оценки риска: наличие неаутентифицированной XSS подтверждено шире, тогда как серверный этап доказан в контролируемой среде и требует подходящей административной сессии, перехода жертвы на внешнюю страницу и успешного социального приёма.
Исправление выпущено 6 августа; основная безопасная версия — WordPress 7.0.3, а патчи перенесены назад вплоть до ветки WordPress 4.7. Сайтам с фоновыми автоматическими обновлениями релиз должен устанавливаться автоматически, но администраторам стоит проверить фактическую версию, а не полагаться на настройку. Установки старше WordPress 4.7 остаются уязвимыми и находятся за пределами диапазона официальных исправлений, поэтому им требуется миграция на поддерживаемую ветку. Обычные меры усиления WordPress и CSP с nonce и strict-dynamic не закрывают исходную XSS полностью. По состоянию на 7 августа WordPress не сообщал об эксплуатации CVE-2026-64638 в реальных атаках и указал команду как обнаружившую и ответственно раскрывшую ошибку.
Изображение носит иллюстративный характер
Точкой входа служит имя пользователя, специально подготовленное и отправленное через форму авторизации. После неудачного входа WordPress показывает это значение на странице ошибки. Оно последовательно проходит через sanitize_user(), wp_strip_all_tags() и лежащую в основе последней функции PHP strip_tags(), а позднее обрабатывается wp_kses_post(). Проблема кроется в разном понимании одной строки двумя парсерами. Конструкция, похожая на тег и содержащая пробел после открывающего символа «<», переживает strip_tags() как текст, но wp_kses_post() уже распознаёт её как допустимый HTML. В результате на странице появляются управляемые атакующим DOM-элементы, и JavaScript выполняется в контексте домена сайта. После открытия страницы с ошибкой дополнительных действий на ней не требуется.
Инъекция использует штатный скрипт WordPress user-profile.js. Он предназначен для управления профилем, но загружается и на странице входа из-за размещённой там функции сброса пароля. Часть элементов профиля на этой странице отсутствует, поэтому два ожидаемых поля ввода получают значение undefined. Проверка их равенства проходит, хотя разработчики явно рассчитывали на другой сценарий. Затем внедрённый элемент подменяет через DOM clobbering обычно неопределённую переменную ajaxurl. После такой подмены собственный JavaScript WordPress отправляет выбранный атакующим REST-запрос внутри того же источника.
Для превращения REST-ответа в исполняемый сценарий применила поддержку JSONP в WordPress. Даже конфигурации, возвращающие анонимному клиенту HTTP 401 Unauthorized, не всегда останавливают цепочку. Параметр _envelope=1 помещает отказ во внешнюю оболочку с кодом HTTP 200 OK, после чего jQuery продолжает обрабатывать ответ как скрипт. Не спасла испытанная исследователями и nonce-политика Content Security Policy с директивой strict-dynamic. Этот путь развивает технику Same Origin Method Execution, или SOME, которую Paulos Yibelo описал в 2022 году: разрешённая цепочка свойств JSONP позволяет вызвать метод в другом окне браузера.
Само XSS не требует входа, но переход к выполнению PHP заметно сложнее. Жертва должна быть авторизована в WordPress с правами Administrator, открыть контролируемую атакующим страницу и совершить явное действие. В демонстрации хватало одного обычного щелчка. Исследователи утверждают, что цепочка работает на стандартной установке без редкой серверной конфигурации и допускает несколько маршрутов, включая установку плагина и загрузку произвольного ZIP-архива. WordPress формулирует риск осторожнее: успешная эскалация зависит от социальной инженерии и обстоятельств, которыми атакующий управляет не полностью.
Один показанный маршрут использовал WordPress Application Passwords. XSS из источника WordPress обращался к штатному элементу подтверждения Application Password в активной административной сессии. Сайт создавал отзывной API-пароль и перенаправлял его на заданный злоумышленником HTTPS-адрес success_url. Основной пароль администратора при этом красть не требовалось. Полученная учётная информация давала аутентифицированный доступ к WordPress REST API.
Через API исследователи публиковали страницу WordPress с JavaScript того же источника и заставляли ещё активную сессию администратора открыть её. Скрипт извлекал n необходимый для загрузки плагина, после чего на сервер отправлялся подготовленный ZIP-архив. Существенная деталь: вредоносный плагин не надо было активировать. PHP-файл вызывался напрямую из каталога, куда WordPress распаковал архив. Такой доступ позволяет прочитать реквизиты базы данных из wp-config.php, создать постоянные административные учётные записи, менять материалы сайта, просматривать доступные процессу PHP файлы и секреты, запускать команды операционной системы с правами PHP-процесса и закрепляться посредством серверного кода.
Автономная система нашла и воспроизвела цепочку, взяв за отправную точку исследование SOME Паулоса Йибело. По данным компании, работа заняла почти четыре дня; в ней использовались модели ИИ с открытым исходным кодом и многоагентный процесс. Технические материалы передали изданию The Hacker News. При этом доказательства с реальных систем ограничивались начальной XSS: её повторили на двух развёртываниях WordPress 7.0.2 в свежих профилях Chrome без cookies WordPress и без учётных данных.
На этих двух системах исследователи не создавали Application Passwords, не загружали файлы, не закреплялись и не запускали PHP. Полную XSS2Shell-цепочку отдельно показали на чистой локальной установке WordPress 7.0.2. Такое разделение существенно для оценки риска: наличие неаутентифицированной XSS подтверждено шире, тогда как серверный этап доказан в контролируемой среде и требует подходящей административной сессии, перехода жертвы на внешнюю страницу и успешного социального приёма.
Исправление выпущено 6 августа; основная безопасная версия — WordPress 7.0.3, а патчи перенесены назад вплоть до ветки WordPress 4.7. Сайтам с фоновыми автоматическими обновлениями релиз должен устанавливаться автоматически, но администраторам стоит проверить фактическую версию, а не полагаться на настройку. Установки старше WordPress 4.7 остаются уязвимыми и находятся за пределами диапазона официальных исправлений, поэтому им требуется миграция на поддерживаемую ветку. Обычные меры усиления WordPress и CSP с nonce и strict-dynamic не закрывают исходную XSS полностью. По состоянию на 7 августа WordPress не сообщал об эксплуатации CVE-2026-64638 в реальных атаках и указал команду как обнаружившую и ответственно раскрывшую ошибку.
