Более 3600 попыток атаки за сутки, создание администратора без логина и пароля, и всё это через коммерческий плагин для карт. Уязвимость WP Maps Pro уже используют в реальных атаках, а для владельцев WordPress-сайтов это означает неприятную, но знакомую истину: даже премиальный плагин с вполне бытовой функцией поддержки может внезапно стать точкой полного захвата проекта.
О проблеме сообщает BleepingComputer со ссылкой на исследователей из Wordfence и автора находки Дэвида Брауна. Критическая уязвимость получила идентификатор CVE-2026-8732 и затрагивает WP Maps Pro версии 6.1.0 и ниже. Исправление вышло 20 мая в версии 6.1.1, но окно для атак, судя по активности злоумышленников, уже открылось: защитная компания Defiant зафиксировала и заблокировала тысячи попыток эксплуатации всего за последние 24 часа.
Сам плагин WP Maps Pro не относится к экзотике. Это платное расширение для WordPress, которое используют для интерактивных карт, локаторов магазинов и вывода нескольких точек на карте. Оно поддерживает Google Maps и OpenStreetMap, а ставят его, как правило, бизнесы с физическими адресами, агентства недвижимости, туристические сайты, каталоги и разные организации с географией филиалов. У продукта более 15 800 продаж на Envato Market, то есть речь не о заброшенном эксперименте одного разработчика, а о вполне заметном элементе экосистемы WordPress.
Причина уязвимости особенно показательна. В плагине была функция временного доступа, задуманная для службы поддержки поставщика. Идея понятная: дать вендору быстро зайти на сайт клиента и посмотреть, что сломалось. На практике именно эта сервисная дверца и превратилась в полноценный вход для посторонних. Браун обнаружил, что AJAX-эндпоинт этой функции доступен неавторизованным пользователям, а защита держится на nonce, который опубликован во фронтенд-JavaScript. Иными словами, секрет, который должен был ограничивать доступ, лежал на виду у всех, кто умеет открыть код страницы и собрать корректный запрос.
Дальше цепочка выглядит совсем безрадостно. Специально сформированный запрос запускает код, который создаёт нового пользователя WordPress, сразу назначает ему роль администратора, генерирует URL для входа без пароля и отправляет этот адрес во внешний сервис. После перехода по такой ссылке атакующий автоматически оказывается в админке под только что созданной учётной записью. Без подбора пароля, без социальной инженерии, без обхода двухфакторной авторизации, если она не распространяется на сам механизм магического входа. По данным Wordfence, при параметре check_temp со значением false функция создаёт пользователя через wp_insert_user(), использует жёстко заданную роль administrator и адрес support@flippercode.com, а затем формирует ссылку через generate_login_link(). Для атакующего это почти идеальный сценарий: минимум шума, максимум прав.
Когда у злоумышленника уже есть администратор в WordPress, дальнейшие варианты слишком хорошо известны любому, кто хоть раз разбирал инциденты на CMS. Можно поставить вредоносный плагин, внедрить постоянный бэкдор, загрузить web shell, подменить контент, украсть закрытые данные, изменить SEO-настройки или превратить сайт в площадку для дальнейших атак. В корпоративной среде это быстро выходит за пределы самого сайта. Если WordPress связан с CRM, формами заявок, внутренними API, платёжными модулями или почтовой инфраструктурой, компрометация одной админки перестаёт быть локальной проблемой маркетинга и становится задачей для всей ИБ-команды.
Отдельно неприятно то, как развивалась история по датам. Исследователь сообщил о баге в Wordfence 24 марта. После проверки эксплойта вендора уведомили 16 мая. Уже 20 мая вышла версия 6.1.1 с исправлением. Формально реакция не выглядела катастрофически медленной, но рынок WordPress живёт в своём ритме: даже после релиза патча значимая доля сайтов обновляется не сразу, а иногда не обновляется вообще, пока не случится инцидент. Поэтому между выпуском исправления и массовым накрытием проблемы почти всегда остаётся фаза, где атакующие соревнуются не с разработчиком, а с привычкой администраторов откладывать обновления на потом.
Для русскоязычной IT-аудитории здесь важен не только сам CVE, но и знакомый паттерн разработки. Вспомогательная функция для саппорта получает повышенные права, затем вокруг неё строится слабая логика проверки, а фронтенд-артефакт по ошибке начинает играть роль барьера безопасности. Такое регулярно всплывает не только в WordPress-плагинах, но и в самописных админках, B2B-кабинетах, внутренних панелях и low-code-продуктах. Как только удобство поддержки начинает конкурировать с моделью угроз, команда почти всегда недооценивает последствия. В результате временный доступ оказывается не временным, служебный обход не ограничивается сотрудниками, а публичный интерфейс внезапно становится точкой эскалации привилегий.
Для разработчиков вывод очевиден: нельзя считать nonce, токен из клиентского кода или любой видимый на странице параметр достаточной защитой для операций, которые создают пользователя, меняют роль или выдают магическую ссылку на вход. Для продукта и бизнеса вывод ещё прозаичнее: если сайт на WordPress используется как витрина продаж, каталог объектов, сеть филиалов или канал лидогенерации, компрометация через уязвимость WP Maps Pro может быстро обернуться не только зачисткой вредоносного кода, но и потерей заявок, репутационным ущербом и незапланированным аудитом всей цепочки подрядчиков. А для HR и IT-руководителей это напоминание, что управление уязвимостями на веб-платформах по-прежнему начинается не с модных слов про киберустойчивость, а с инвентаризации плагинов и дисциплины обновлений.
Главный вопрос теперь не в том, будет ли эта история единичным инцидентом, а в том, сколько ещё продуктов для WordPress прячут похожие механики удалённой поддержки под вывеской удобства. Если рынок продолжит встраивать сервисные обходы без жёсткой серверной авторизации, уязвимость WP Maps Pro рискует оказаться не исключением, а очередным эпизодом в длинной серии взломов через функции, которые когда-то добавили якобы для ускорения помощи клиенту.