whattheslime/cve-2026-8181Exploit para o CVE-2026-8181 - Bypass de Autenticação do Plugin Burst Statistics WordPress
Exploit para o CVE-2026-8181 descoberto por Chloe Chamberland e PRISM.
Este repositório é fornecido apenas para fins de pesquisa e segurança defensiva. O autor não assume responsabilidade pelo uso indevido destas informações.
O plugin Burst Statistics – Privacy-Friendly WordPress Analytics para WordPress é vulnerável a um Bypass de Autenticação levando a Escalação de Privilégio de Administrador nas versões 3.4.0 a 3.4.1.1.
A vulnerabilidade existe no método is_mainwp_authenticated() do proxy MainWP do plugin, que trata incorretamente qualquer valor de retorno diferente de WP_Error de como uma autenticação bem-sucedida.
wp_authenticate_application_password()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.
A cadeia de vulnerabilidade é a seguinte:
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).
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().
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.
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.
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.
Plugin ativo — o HTML da página inicial referencia seus assets apenas quando o plugin está enfileirado:
echo http://127.0.0.1:8000 | httpx -silent -mr '/wp-content/plugins/burst-statistics/'
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+):
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:
nuclei -t CVE-2026-8181.yaml -u http://127.0.0.1:8000
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:
echo http://127.0.0.1:8000 | httpx -silent -path '/wp-json/wp/v2/users' -er '"slug":"[^"]+"'
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:
Instale as dependências Python:
python3 -m venv venv
venv/bin/pip install -r requirements.txt
Execute o exploit contra o alvo, fornecendo um nome de usuário administrador conhecido com -u:
venv/bin/python3 CVE-2026-8181.py -t http://127.0.0.1:8000 -u admin
Exemplo de saída:
[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'
Faça login em /wp-admin/ com a nova conta de administrador criada.
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 é.