Критическая уязвимость Burst Statistics уже используют в реальных атаках: по данным Wordfence, за последние 24 часа было заблокировано более 7400 попыток эксплуатации. Для владельцев WordPress-сайтов это не абстрактная история про «очередной баг в плагине», а риск мгновенной потери административного доступа, установки бэкдоров и компрометации данных.
Проблема затрагивает плагин Burst Statistics, который позиционируется как приватная и легковесная альтернатива Google Analytics и установлен примерно на 200 тысячах сайтов. Как пишет BleepingComputer, атакующие используют уязвимость с идентификатором CVE-2026-8181, чтобы выдавать себя за администратора и выполнять действия от его имени через REST API WordPress. В худшем сценарии злоумышленник может создать новый аккаунт с правами администратора вообще без предварительной аутентификации.
Технически ошибка выглядит почти обидно. Уязвимый код неправильно трактует результат работы функции wp_authenticate_application_password(). Вместо того чтобы считать объект WP_Error признаком неудачной аутентификации, логика плагина фактически пропускает такой результат дальше. Исследователи Wordfence отдельно отмечают и второй сбойный сценарий: WordPress в ряде случаев возвращает null, а это также ошибочно воспринимается как успешный запрос. Дальше код вызывает wp_set_current_user() с именем пользователя, которое передал атакующий, и на время REST API-запроса система считает его этим пользователем.
Ключевой нюанс в том, что злоумышленнику не нужен корректный пароль администратора. Достаточно знать его логин и отправить любой неверный пароль в заголовке Basic Authentication. Если логин администратора известен, этого хватает для подмены личности в рамках запроса. А логины в WordPress нередко лежат почти на поверхности: в URL авторов, в комментариях, в публичных API-ответах, иногда даже в старых публикациях. Если они не видны напрямую, их можно банально перебирать.
Из этого вытекает неприятная практическая картина. Доступ уровня администратора в WordPress позволяет не только менять контент. Это доступ к управлению пользователями, плагинами, темами и значительной части серверной логики сайта. После успешной эксплуатации атакующий может создать запасную админскую учетную запись, загрузить вредоносный код, встроить редиректы на фишинговые страницы, развернуть малварь или закрепиться в системе через бэкдор. Для корпоративного сайта это уже не локальный инцидент команды контента, а полноценный риск для бренда, SEO, клиентских данных и интеграций.
Когда появился баг и сколько сайтов еще под ударом
Уязвимость Burst Statistics появилась не «с незапамятных времен», а довольно точно привязана к релизам. По данным источника, проблема была внесена 23 апреля 2026 года вместе с версией 3.4.0. Уязвимый код сохранился и в следующем выпуске 3.4.1. Исследователи Wordfence обнаружили CVE-2026-8181 8 мая, а исправление вышло 12 мая в версии 3.4.2. Это важная деталь: речь не о древнем заброшенном плагине, а о свежей регрессии в активно используемом продукте.
Даже после выхода патча картина остается неприятной. Статистика WordPress.org, на которую ссылается BleepingComputer, показывает 85 тысяч загрузок с момента релиза 3.4.2. Если предположить, что все они пришлись именно на исправленную версию, то около 115 тысяч сайтов все еще могут оставаться уязвимыми для захвата администраторских прав. Для массовой автоматизированной эксплуатации это более чем достаточная поверхность атаки.
Важен и темп развития истории. Wordfence прямо предупреждала, что уязвимость почти наверняка быстро станет целью атакующих. Судя по цифре в 7400 заблокированных атак за сутки, прогноз сбылся без задержки. Это типичный сценарий последних лет для экосистемы WordPress: как только выходит информация о критическом баге в популярном плагине, между публикацией, автоматизацией атаки и массовым сканированием интернета проходят не недели, а часы.
Контекст здесь тоже показателен. В той же повестке регулярно всплывают похожие инциденты с плагинами WordPress: от ошибок загрузки файлов до обхода аутентификации и чтения данных. Причина не только в популярности самой CMS, но и в устройстве рынка расширений. Плагин может быть удобным, легким и полезным, но одна ошибка в проверке авторизации мгновенно превращает его из инструмента аналитики в точку входа для атаки. Для бизнеса это еще один аргумент в пользу инвентаризации плагинов и более жесткой дисциплины обновлений.
Что делать разработчикам и владельцам сайтов
Практический вывод у этой истории довольно прямой. Если на сайте используется Burst Statistics, нужно либо немедленно обновиться до версии 3.4.2, либо отключить плагин. Полумер здесь нет: уязвимость Burst Statistics уже эксплуатируется, а значит окно «обновим на выходных» фактически закрыто. После обновления логично проверить список пользователей, последние изменения в настройках, неизвестные плагины и темы, а также следы подозрительных REST API-запросов.
Для технических команд история шире одного конкретного плагина. Стоит пересмотреть подход к WordPress как к периферийному активу, который «сам как-то живет». Маркетинговый сайт, блог продукта или лендинг под кампанию часто получают меньше внимания, чем основная платформа, хотя именно через них злоумышленники нередко заходят в инфраструктуру. Если у сайта есть интеграции с CRM, почтовыми сервисами, аналитикой или внутренними API, компрометация WordPress перестает быть проблемой только веб-команды.
История с Burst Statistics хорошо показывает неприятную реальность зрелой веб-экосистемы: даже приватный аналитический плагин без лишнего шума может стать входной дверью для атак на десятки тысяч сайтов. Чем больше бизнес полагается на модульную сборку из сторонних компонентов, тем важнее не только ставить патчи, но и понимать, какие именно плагины имеют привилегированный доступ и что случится, если один из них внезапно начнет «аутентифицировать» кого попало.