Команда исследователей кибербезопасности обнаружила и оперативно сообщила компании Patchstack о критической уязвимости в популярном плагине для WordPress Modular DS. Уязвимость, классифицируемая как неаутентифицированное повышение привилегий, затрагивает более 40 тысяч активных установок и уже активно эксплуатируется злоумышленниками в дикой среде. Разработчик плагина, modulards, выпустил исправление в версии 2.5.2. Всем пользователям настоятельно рекомендуется немедленно обновить плагин, чтобы защитить свои ресурсы от компрометации.
Описание
Плагин Modular DS предназначен для централизованного управления несколькими сайтами на WordPress. Его функционал включает удалённый мониторинг, обновление и выполнение различных задач. Однако в версиях 2.5.1 и ниже исследователи выявили цепочку логических ошибок, позволяющую любому пользователю без авторизации получить права администратора на уязвимом сайте.
Ключевая проблема кроется в механизме проверки так называемых "прямых запросов" от платформы Modular. Для упрощения внутренней коммуникации плагин использует специальный режим, активируемый при определённых параметрах HTTP-запроса. В частности, метод "isDirectRequest()" во фреймворке плагина ошибочно признавал запрос внутренним и пропускал его через систему аутентификации, если в нём присутствовали параметры "origin=mo" и "type" с любым значением. При этом отсутствовала какая-либо криптографическая проверка подписи, секретного ключа или IP-адреса источника.
В результате злоумышленник мог легко сымитировать "прямой запрос" и получить доступ к группе защищённых маршрутов плагина, которые должны требовать авторизации. Среди этих маршрутов наиболее опасным оказался "/api/modular-connector/login/". Контроллер, обрабатывающий этот путь, содержал логику автоматического входа в систему. Если в запросе не был указан конкретный ID пользователя, код автоматически находил учётную запись администратора или суперадминистратора сайта и выдавал атакующему авторизационные куки, перенаправляя его в административную панель WordPress. Это давало полный контроль над сайтом.
Эксплуатация уязвимости не требует специальных знаний или инструментов. Исследователь Теему Саарентаус продемонстрировал, что для успешной атаки достаточно отправить простой GET-запрос, например, на адрес "/api/modular-connector/login/?origin=mo&type=foo". После получения прав администратора злоумышленники, по данным компании Patchstack, обычно создают новую учётную запись с именем, содержащим "admin", и фиктивным email-адресом для сохранения доступа. Это является стандартным индикатором компрометации.
Первые попытки эксплуатации были зафиксированы аналитиками 13 января около 02:00 по всемирному координированному времени. После публикации правила для смягчения угрозы компанией Patchstack 14 января были замечены новые волны атак с идентичными параметрами. В настоящее время отслеживается активность с IP-адресов 45.11.89[.]19 и 185.196.0[.]11. Всем администраторам сайтов рекомендуется проверить журналы доступа на наличие запросов к пути "/api/modular-connector/login/" с указанными параметрами, а также на предмет наличия новых подозрительных учётных записей администраторов.
Разработчик оперативно отреагировал на сообщение об уязвимости. Патч, выпущенный в версии 2.5.2, кардинально меняет механизм маршрутизации. Была удалена логика сопоставления маршрутов на основе URL, контролируемого атакующим. Теперь выбор маршрута полностью управляется внутренней логикой плагина, а для некорректных запросов возвращается стандартная ошибка 404. Уязвимость получила идентификатор CVE-2026-23550.
Данный инцидент наглядно демонстрирует, насколько опасным может быть излишнее доверие к внутренним механизмам, когда они непреднамеренно становятся доступны из публичной сети. Проблема возникла не из-за одной ошибки в коде, а из-за совокупности архитектурных решений. Сюда входят маршрутизация на основе URL, излишне разрешительный режим "прямого запроса", аутентификация, основанная только на факте подключения сайта к сервису, и функция автоматического входа под учётной записью администратора. Вместе эти факторы создали идеальные условия для атаки.
Эксперты по безопасности подчёркивают, что внутренние API и функционал, предназначенный для межсервисного взаимодействия, никогда не должны быть публично доступны без строгой проверки источника запроса. Аутентификация должна верифицировать самого инициатора запроса, а не просто проверять состояние подключения сайта. Кроме того, решения о маршрутизации не должны зависеть от параметров, которые может контролировать потенциальный злоумышленник.
Индикаторы компрометации
IPv4
- 185.196.0.11
- 45.11.89.19
