Дыра в WordPress: форма входа отдаёт сервер
Уязвимость WordPress по прозвищу XSS2Shell превращает неудачную попытку входа в исполнение PHP-кода на сервере. Дыра числится как CVE-2026-64638 и получила 8,9 балла по шкале CVSS. Начинается всё с имени пользователя, введённого в общедоступную форму логина, а заканчивается, при определённых условиях, распакованным в вашей установке плагином от атакующего. Исправление вышло в WordPress 7.0.3 6 августа 2026 года и было забэкпортировано вплоть до ветки 4.7. Публичный эксплойт появился в считаные дни.
Как работает цепочка XSS2Shell
Точка входа - сообщение об ошибке входа. Отправьте несуществующее имя пользователя, и WordPress выведет его обратно на странице. Это отражение должно быть безобидным, и на пути стоят два разных санитайзера. Обход, найденный командой pwn.ai, использует расхождение между ними: strip_tags() не считает тегом конструкцию, перед которой стоит пробел, поэтому полезная нагрузка вида < area id=ajaxurl> проходит нетронутой, а wp_kses_post() позднее читает ту же строку как валидный HTML и отрисовывает её настоящим элементом страницы.
Самое интересное - что делает этот элемент. Это не скрипт. Это именованный DOM-узел, который сталкивается с JavaScript-переменной, оставленной WordPress неопределённой на этом экране. Приём называется DOM clobbering. Штатный админский скрипт обращается к ajaxurl, находит вместо пустоты элемент атакующего и направляет запрос туда, куда указал атакующий. Дальше цепочка идёт через собственный доверенный код сайта: REST-эндпоинт с поддержкой JSONP выполняет JavaScript атакующего в источнике самого сайта, приём с межоконным вызовом методов дотягивается до сессии авторизованного администратора и подтверждает создание Application Password, а эта учётная запись даёт аутентифицированный доступ к REST API.
Последний шаг не требует вообще никакой экзотики. Украденный Application Password несёт права администратора, поэтому атакующий просто загружает через API плагин: ZIP-архив с PHP внутри. На односайтовой установке у администратора вдобавок по умолчанию есть право на нефильтруемый HTML, и именно оно делает возможным промежуточный шаг с публикацией страницы, набитой JavaScript. С этого момента код уже не в браузере. Он выполняется с правами PHP-воркера, рядом с учётными данными базы.
Что на самом деле нужно атакующему
Здесь заголовок и реальность расходятся. Половина с межсайтовым скриптингом действительно не требует ни учётной записи, ни пароля - именно поэтому баг считается доаутентификационным. А вот половина с удалённым выполнением кода сама по себе не срабатывает. Администратор должен быть авторизован на целевом сайте и должен открыть ссылку, которую контролирует атакующий. Никаких запросов подтверждения не появляется, жертва не видит ничего необычного, но переход по ссылке обязан произойти.
На практике это низкий барьер. Администраторы сайтов целыми днями кликают по ссылкам в тикетах поддержки, формах обратной связи, уведомлениях о комментариях и письмах подрядчиков, причём часто в той же сессии браузера, где открыта админка. Отношение к формулировке "требуется действие пользователя" как к утешению - ровно тот путь, на котором такая цепочка остаётся незакрытой месяц.
Какие версии затронуты
Уязвимы все выпуски WordPress от 4.7 до 7.0.2 включительно. Эта ветка вышла в декабре 2016 года, поэтому затронутый диапазон покрывает практически любую установку, которая ещё получает обновления. WordPress выпустил исправления по всему поддерживаемому дереву в один день: от 7.0.3 через 6.9.6 и 6.8.7 и дальше вплоть до 4.7.34. Всё, что работает на 4.6 и старше, обновлений безопасности не получает вовсе и должно считаться постоянно уязвимым.
XSS2Shell была одной из двенадцати проблем, закрытых в этом выпуске. Среди остальных - хранимый межсайтовый скриптинг в блоках Post Date и Post Content, в настройках эмодзи и в быстром редактировании, утечка информации с раскрытием комментариев к постам под паролем, обход процедуры подтверждения адреса почты, CSS-инъекция через фильтр безопасных атрибутов, повышение привилегий в мультисайтовых сетях с открытой регистрацией, подделка серверных запросов при валидации URL с доступом к link-local диапазонам и перебор слагов записей. Даже без главной цепочки этот список - повод обновиться сегодня.
Что делать прямо сейчас
- Обновиться немедленно: перейти на 7.0.3 или на исправленный выпуск своей ветки. Фоновые автообновления по умолчанию ставят минорные релизы безопасности, но версию стоит проверить, а не предполагать.
- Проверить Application Passwords: открыть профиль каждого администратора и отозвать все учётные данные, которых вы не узнаёте. Именно этот артефакт цепочка оставляет за собой, и он переживает смену пароля.
- Пересмотреть пользователей, плагины и файлы: искать администраторов, которых вы не создавали, и плагины, появившиеся без соответствующей записи в вашей же истории изменений.
- Не заходить в админку откуда попало: держать сессию администратора в отдельном профиле браузера, не в том, где почта и тикеты поддержки, - это убирает то самое предусловие, на котором держится атака.
- Ограничить экран входа: отражение живёт в wp-login.php. Ограничение доступа к нему - по списку IP, через HTTP-аутентификацию или правилом файрвола - сужает поверхность для следующего бага в том же файле.
Почему это важно не только владельцам сайтов
Взломанная установка WordPress редко бывает целью атакующего. Это транспорт, и трафику с неё доверяют именно потому, что домен настоящий. Тот же сценарий мы видели, когда рекламный скрипт начал подменять адреса криптокошельков на тысячах обычных сайтов, и та же идея лежит в основе атак на уровне браузера, которые едут верхом на уже открытой авторизованной сессии жертвы. Для читателя, а не администратора, практическая защита находится на сетевом уровне: DNS-фильтрация и блок-листы не дают загрузиться полезной нагрузке второй ступени, даже если сайт, который её отдаёт, вы посещаете годами. Это прямой аргумент в пользу инструментов приватности, блокирующих на этапе резолвинга, и стоит честно сказать: ни один такой инструмент не патчит ваш собственный сервер. Это делает только обновление.
