Это позволяет неаутентифицированным атакующим, знающим действительное имя пользователя администратора, выдавать себя за этого администратора на время любого REST API запроса, включая стандартные конечные точки WordPress, такие как POST /wp-json/wp/v2/users. Учетные данные существующего администратора никогда не компрометируются, но атакующий получает его привилегии на время, достаточное для создания новой учетной записи администратора.

🔬 Анализ первопричины

Цепочка уязвимости следующая:

1. includes/class-burst.php:41 -> Плагин регистрирует init() на приоритете 9 хука plugins_loaded, который запускает bootstrap() и вызывает has_admin_access() для каждого запроса (включая REST).

2. includes/Traits/trait-admin-helper.php:202 -> Когда запрос содержит заголовок X-BurstMainWP: 1, has_admin_access() создает экземпляр MainWP_Proxy и делегирует аутентификацию методу is_mainwp_authenticated().

3. includes/Frontend/class-mainwp-proxy.php:314 -> Метод читает заголовок Authorization, декодирует учетные данные Basic и передает предоставленные атакующим username / password в функцию ядра WordPress wp_authenticate_application_password().

4. includes/Frontend/class-mainwp-proxy.php:328-329 -> Возвращаемое значение проверяется только с помощью is_wp_error(). Ядро WordPress возвращает неизменный $input_user (в данном случае null), когда прикладные пароли не используются или когда запрос не помечен как API-запрос. На приоритете 9 хука plugins_loaded REST API еще не установил фильтр application_password_is_api_request в true, поэтому второе условие всегда выполняется, когда выполняется уязвимый код — и null не является WP_Error, поэтому проверка проходит.

5. includes/Frontend/class-mainwp-proxy.php:336 -> Вызывается wp_set_current_user( $user->ID ) с пользователем, полученным исключительно из предоставленного атакующим имени пользователя, что устанавливает глобально аутентифицированного пользователя на весь запрос.

Таким образом, одного HTTP-запроса с поддельным паролем достаточно, чтобы выдать себя за любого администратора на уровне REST API ядра WordPress.

🔎 Обнаружение установки плагина

1. Активный плагин — HTML главной страницы ссылается на его ресурсы только когда плагин подключен:

   root@kitploit:~

   echo http://127.0.0.1:8000 | httpx -silent -mr '/wp-content/plugins/burst-statistics/'
   

2. Версия — readme.txt отдается статически и показывает установленную версию (уязвимые: 3.4.0–3.4.1.1, исправленные: 3.4.2+):

   root@kitploit:~

   echo http://127.0.0.1:8000 | httpx -silent -path /wp-content/plugins/burst-statistics/readme.txt -er 'Stable tag:\s*[0-9][0-9a-zA-Z.\-]*'
   

Встроенный шаблон CVE-2026-8181.yaml для nuclei автоматизирует обе проверки и сравнение версий:

🎯 Эксплуатация

После обнаружения уязвимой версии плагина для эксплуатации требуется знать действительное имя пользователя администратора. REST API WordPress'а на большинстве установок раскрывает их через публичную конечную точку пользователей:

Когда эта конечная точка заблокирована (например, с помощью Disable REST API или Stop User Enumeration), трюк с архивом автора (/?author=N) обычно все еще раскрывает имя пользователя через перенаправление на /author/<username>/.

Имея действительное имя пользователя, эксплойт создает новую администраторскую учетную запись одним запросом:

0. Установите зависимости Python:

   root@kitploit:~

   python3 -m venv venv
   venv/bin/pip install -r requirements.txt
   

1. Запустите эксплойт против цели, указав известное имя пользователя администратора с помощью -u:

   root@kitploit:~

   venv/bin/python3 CVE-2026-8181.py -t http://127.0.0.1:8000 -u admin
   

   Пример вывода:

   root@kitploit:~

   [2026-05-16] [12:20:20] [info] [config] Impersonating admin='admin', will create new admin 'pwn_322a4903' / 'kS8D^2A^P^%UtWyuUS3p8%64' ([email protected]).
   [2026-05-16] [12:20:21] [success] [http://127.0.0.1:8000] Authentication bypass successful — new administrator created: username='pwn_322a4903' password='kS8D^2A^P^%UtWyuUS3p8%64'
   

2. Войдите в /wp-admin/ с новосозданной учетной записью администратора.

⚠️ Ограничения

Обход срабатывает только если заголовок Authorization достигает PHP через $_SERVER['HTTP_AUTHORIZATION']. На Apache + mod_php с обычными постоянными ссылками (стандартная настройка WordPress по умолчанию) не создается .htaccess, и заголовок молча удаляется — эксплойт не может быть успешным.

Переключение на любые необычные постоянные ссылки в Настройки → Постоянные ссылки заставляет WordPress 5.6+ записать директиву RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] в .htaccess, восстанавливая пересылку. Nginx + PHP-FPM и LiteSpeed пересылают Authorization по умолчанию независимо от постоянных ссылок. ЧПУ (человеко-понятные URL) являясь нормой SEO в продакшене, являются причиной, по которой эта уязвимость оценивается как CVSS 9.8 неаутентифицированная.

Эксплойт сначала пробует /wp-json/wp/v2/users, затем отступает к /index.php?rest_route=/wp/v2/users, поэтому маршрутизация конечных точек никогда не является препятствием — только пересылка заголовка.

📚 Ссылки

• https://www.wordfence.com/blog/2026/05/200000-wordpress-sites-at-risk-from-critical-authentication-bypass-vulnerability-in-burst-statistics-plugin/
• https://www.wordfence.com/threat-intel/vulnerabilities/id/8ca830d6-3d3c-4026-85cd-8447b8a568d3
• https://www.cve.org/CVERecord?id=CVE-2026-8181