Конструктор страниц Elementor для WordPress работает более чем на десяти миллионах сайтов. В версиях 4.3.0 и 4.3.1 плагин отключал защиту от межсайтовой подделки запроса при обращениях к REST API - программному интерфейсу, через который WordPress и его расширения выполняют действия с сайтом. Хватает одной ссылки, открытой вошедшим в систему пользователем, чтобы тот от своего имени выполнил любое действие, на которое у него есть права. На обычной установке администратор, кликнувший по такой ссылке, создаёт вторую учётную запись администратора, принадлежащую злоумышленнику.
Детали уязвимости
Ни сценария на JavaScript, ни формы, ни страницы под контролем атакующего не нужно. Подойдёт обычный переход по ссылке из письма, сообщения в мессенджере или комментария на постороннем сайте. Жертва видит нормальную ссылку и ответ сервера в формате JSON (текстовый формат обмена данными). Поэтому способ доставки почти не ограничен: содержимое страницы, куда ведёт ссылка, роли не играет.
Причина в том, как плагин решал, к кому адресован запрос. Ядро WordPress защищает обращения к программному интерфейсу от межсайтовой подделки единственным способом: сверяет одноразовый код, встроенный в запрос, для сессии, которая хранит учётные данные в браузере. Elementor отменял сверку, если в адресе запроса встречалось название его собственного внутреннего маршрута. Адрес включает не только путь, но и строку запроса, а её целиком пишет тот, кто составляет ссылку. Достаточно дописать безобидный на вид параметр, и проверка перестаёт работать для любого обращения. Поиск подстроки не привязывался к началу адреса, поэтому подходило и упоминание нужного фрагмента в середине строки.
Важна и другая деталь. Проверка выполнялась до того, как WordPress определит маршрут, и получала только сырую строку адреса. Других сведений в тот момент у неё не было. Возвращённое значение "истина" сообщало всем последующим обработчикам, что подлинность запроса уже подтверждена. Ядро сверяет одноразовый код в обработчике, который первым смотрит, не решил ли вопрос кто-то до него. Здесь решение уже принято, и сверка не выполняется. Заодно не срабатывают сторонние средства защиты, подключённые к тому же механизму.
Остаётся проверка прав доступа, но она опирается на ту же сессию жертвы. Пользователь вошёл в систему, значит его учётная запись охотно подтверждает право создавать пользователей, менять настройки и работать с содержимым. Права сохраняются, пропадает лишь подтверждение того, что действие совершено добровольно.
Дальше срабатывает ещё одна особенность ядра WordPress: метод запроса можно переопределить параметром в адресе. Из-за этого простая навигация превращается в операцию записи, и вся атака укладывается в один адрес. Без ключевого параметра сервер отвечает отказом с кодом 401, с ним создаёт пользователя и возвращает код 201 вместе с объектом новой учётной записи, где указана роль администратора. Маркер, отличающийся от нужного на один символ, результата не даёт.
Пострадать может не только Elementor. Проверка выполняется до сопоставления маршрута, поэтому обход касается всей программной поверхности сайта: маршрутов ядра WordPress и маршрутов остальных установленных плагинов. Создание администратора - самый наглядный пример. Исследователь показал и чтение настроек сайта: запрос, который прежде отклонялся с кодом 401, начинал возвращать код 200 и содержимое настроек в теле ответа. Расширения, не имеющие отношения к конструктору страниц, тоже подпадают под обход, поскольку защита отключалась на общем уровне. Для агентств и хостинговых компаний, где на одном аккаунте живут десятки сайтов, один переход по ссылке может открыть доступ сразу к нескольким из них.
Затронуты версии 4.3.0 и 4.3.1, и только они. Уязвимость затрагивает модуль, передающий данные о работе редактора. Он скрыт за настройкой-экспериментом, не отображается на экране экспериментов, но включается по умолчанию для сайтов, где Elementor впервые установили начиная с версии 3.32.0. Обычная установка без изменённых настроек и без сторонних плагинов тоже уязвима. В релизах до 4.3.0 этого модуля нет вовсе.
Исправление вышло 24 сентября 2026 года в версии 4.3.2. Проверка теперь читает маршрут, который уже определил WordPress, а не сырую строку адреса, и сравнивает его только с началом пути. Добавили и отсечение случая, когда вместо строки подставляют массив. Владельцам сайтов нужно обновить Elementor до 4.3.2 или более поздней версии. На большинстве установок автоматическое обновление справится само, но в закрытых контурах стоит проверить номер версии вручную. Компания Patchstack выпустила правила фильтрации трафика, блокирующие использование уязвимости.
О проблеме сообщили 22 сентября 2026 года, обновление появилось через два дня, публичное уведомление - 25 сентября. Скорость реакции здесь существенна: уязвимость не требует ни подготовки, ни особых условий, а ссылку легко замаскировать под безобидную.
История показывает расхождение между вопросом и данными, которыми на него отвечали. Код спрашивал, адресован ли запрос его маршруту, в момент, когда маршрут ещё не выбран, и ограничился поиском подстроки в строке, которой управляет клиент. Строку адреса нельзя считать сведениями о маршрутизации: это входные данные от атакующего, и решения по ним требуют отсечения строки запроса и сравнения с начала. Общий механизм проверки подлинности тоже не место для локальных исключений, потому что положительный ответ утверждает успех для всех, кто подключён ниже, включая сверку одноразового кода в ядре WordPress. Обработчику, у которого нет собственного мнения, правильнее вернуть то, что он получил.
Ссылки
