whattheslime/cve-2026-8181Exploit para el CVE-2026-8181 - Bypass de autenticación del plugin Burst Statistics de WordPress
Exploit del CVE-2026-8181 descubierto por Chloe Chamberland y PRISM.
Este repositorio se proporciona únicamente con fines de investigación y seguridad defensiva. El autor no asume ninguna responsabilidad por el mal uso de esta información.
El plugin de WordPress Burst Statistics – Privacy-Friendly WordPress Analytics es vulnerable a una omisión de autenticación que conduce a la escalada de privilegios a administrador en las versiones 3.4.0 a 3.4.1.1.
La vulnerabilidad se encuentra en el método is_mainwp_authenticated() del proxy MainWP del plugin, que trata incorrectamente cualquier valor de retorno de wp_authenticate_application_password() que no sea un WP_Error como una autenticación correcta.
Esto permite a atacantes no autenticados que conozcan un nombre de usuario de administrador válido suplantar a ese administrador durante cualquier solicitud a la API REST, incluidos los endpoints del núcleo de WordPress, como POST /wp-json/wp/v2/users. Las credenciales del administrador existente nunca se ven comprometidas, pero el atacante obtiene sus privilegios durante el tiempo suficiente para crear una cuenta de administrador completamente nueva.
La cadena de la vulnerabilidad es la siguiente:
includes/class-burst.php:41 -> El plugin registra init() en plugins_loaded con prioridad 9, que ejecuta bootstrap() y llama a has_admin_access() en cada solicitud (incluidas las REST).
includes/Traits/trait-admin-helper.php:202 -> Cuando la solicitud incluye la cabecera X-BurstMainWP: 1, has_admin_access() instancia MainWP_Proxy y delega la autenticación en is_mainwp_authenticated().
includes/Frontend/class-mainwp-proxy.php:314 -> El método lee la cabecera Authorization, decodifica las credenciales Basic y reenvía el / proporcionados por el atacante a del núcleo de WordPress.
Por lo tanto, una única solicitud HTTP con una contraseña falsa es suficiente para suplantar a cualquier administrador a nivel de la API REST del núcleo de WordPress.
Plugin activo — el HTML de la página principal solo hace referencia a sus recursos cuando el plugin está cargado:
echo http://127.0.0.1:8000 | httpx -silent -mr '/wp-content/plugins/burst-statistics/'
Versión — readme.txt se sirve de forma estática y expone la versión instalada (vulnerable: 3.4.0–3.4.1.1, parcheada: 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.\-]*'
La plantilla de nuclei incluida, CVE-2026-8181.yaml, automatiza ambas comprobaciones y la comparación de versiones:
nuclei -t CVE-2026-8181.yaml -u http://127.0.0.1:8000
Una vez detectada una versión vulnerable del plugin, la explotación requiere conocer un nombre de usuario de administrador válido. La API REST de WordPress los expone en la mayoría de las instalaciones a través del endpoint público de usuarios:
echo http://127.0.0.1:8000 | httpx -silent -path '/wp-json/wp/v2/users' -er '"slug":"[^"]+"'
Cuando ese endpoint está bloqueado (p. ej., mediante Disable REST API o Stop User Enumeration), el truco del archivo de autor (/?author=N) normalmente sigue filtrando el nombre de usuario mediante la redirección a /author/<username>/.
Con un nombre de usuario válido, el exploit crea una nueva cuenta de administrador en una única solicitud:
Instalar las dependencias de Python:
python3 -m venv venv
venv/bin/pip install -r requirements.txt
Ejecutar el exploit contra el objetivo, proporcionando un nombre de usuario de administrador conocido con -u:
venv/bin/python3 CVE-2026-8181.py -t http://127.0.0.1:8000 -u admin
Ejemplo de salida:
[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'
Iniciar sesión en /wp-admin/ con la cuenta de administrador recién creada.
La omisión solo se activa si la cabecera Authorization llega a PHP a través de $_SERVER['HTTP_AUTHORIZATION']. En Apache + mod_php con enlaces permanentes simples (la configuración predeterminada de WordPress), no se genera ningún .htaccess y la cabecera se elimina silenciosamente — el exploit no puede tener éxito.
Al cambiar a cualquier tipo de enlace permanente que no sea simple en Settings → Permalinks, WordPress 5.6+ escribe la directiva RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] en .htaccess, restaurando el reenvío. Nginx + PHP-FPM y LiteSpeed reenvían Authorization de forma predeterminada, independientemente de los enlaces permanentes. El hecho de que los enlaces permanentes bonitos sean la norma SEO en producción es el motivo por el que esta vulnerabilidad está clasificada como CVSS 9.8 sin autenticación.
El exploit intenta primero /wp-json/wp/v2/users y, si falla, recurre a /index.php?rest_route=/wp/v2/users, por lo que el enrutamiento del endpoint nunca es el obstáculo — solo lo es el reenvío de la cabecera.
usernamepasswordwp_authenticate_application_password()includes/Frontend/class-mainwp-proxy.php:328-329 -> El valor de retorno solo se comprueba con is_wp_error(). El núcleo de WordPress devuelve el $input_user sin modificar (aquí, null) cuando las Contraseñas de aplicación no están en uso o cuando la solicitud no está marcada como solicitud de API. En plugins_loaded con prioridad 9, la API REST aún no ha establecido el filtro application_password_is_api_request en true, por lo que la segunda condición siempre se cumple cuando se ejecuta el código vulnerable — y null no es un WP_Error, por lo que la validación se supera.
includes/Frontend/class-mainwp-proxy.php:336 -> Se llama a wp_set_current_user( $user->ID ) con el usuario obtenido únicamente a partir del nombre de usuario proporcionado por el atacante, lo que establece el usuario autenticado globalmente para toda la solicitud.