WP2Shell WordPress भेद्यता श्रृंखला के लिए PoC डिटेक्टर और सुरक्षित सत्यापनकर्ता: CVE-2026-63030 (REST batch-route confusion) + CVE-2026-60137 (author__not_in SQL injection)। केवल अधिकृत सुरक्षा परीक्षण के लिए।
CVE कवरेज: CVE-2026-63030 और CVE-2026-60137 अभीष्ट उपयोग: केवल अधिकृत सुरक्षा परीक्षण, रक्षात्मक सत्यापन, और डिस्पोज़ेबल localhost लैब
WP2Shell एक WordPress Core भेद्यता श्रृंखला है जो प्री-ऑथेंटिकेशन REST API बैच-रूट कन्फ्यूज़न बग (CVE-2026-63030) को WP_Query author__not_in SQL इंजेक्शन प्रिमिटिव (CVE-2026-60137) के साथ जोड़ती है। यह रिपॉज़िटरी एक Python प्रूफ-ऑफ-कॉन्सेप्ट स्कैनर और सुरक्षित वैलिडेटर प्रदान करती है, ताकि डिफेंडर प्रभावित WordPress इंस्टॉलेशन की फ़िंगरप्रिंटिंग कर सकें, एक पृथक लैब में भेद्य व्यवहार की पुष्टि कर सकें, और निवारण को सत्यापित कर सकें — बिना डेटा निकालने या कोड निष्पादन प्राप्त करने की आवश्यकता के।
यह प्रोजेक्ट WordPress इंस्टॉलेशन की फ़िंगरप्रिंटिंग करता है और WP2Shell WordPress Core भेद्यता श्रृंखला से जुड़े दो भेद्यता प्रिमिटिव को सत्यापित करता है:
WP_Query::author__not_in का अधूरा सैनिटाइज़ेशन, जिसके परिणामस्वरूप SQL इंजेक्शन हो सकता है जब हमलावर-नियंत्रित इनपुट पैरामीटर तक पहुँचता है।जब दोनों स्थितियाँ मौजूद होती हैं, तो एक अनऑथेंटिकेटेड अनुरोध WordPress REST API बैच एंडपॉइंट के माध्यम से भेद्य SQL निर्माण तक पहुँच सकता है। सार्वजनिक एडवाइज़री संयुक्त प्रभाव को संभावित रूप से रिमोट कोड निष्पादन की ओर ले जाने वाला बताती हैं।
इस रिपॉज़िटरी का उपयोग केवल उन्हीं सिस्टमों पर किया जाना चाहिए जिनके आप स्वामी हैं या जिनके परीक्षण के लिए आप स्पष्ट रूप से अधिकृत हैं। 127.0.0.1 से बंधी एक पृथक Docker या वर्चुअल-मशीन लैब को प्राथमिकता दें।
वर्तमान स्रोत फ़ाइल में स्थिति-परिवर्तनकारी कार्यक्षमता शामिल है, जिसमें डेटाबेस-डेटा निष्कर्षण प्रयास, फ़ाइल-लेखन प्रयास, प्रमाणीकरण वर्कफ़्लो, व्यवस्थापक निर्माण, प्लगइन अपलोड, और कमांड निष्पादन शामिल हैं।
प्रभावित WordPress रिलीज़ में आंतरिक ऐरे के बीच संरेखण खो सकता है, जिनका उपयोग ट्रैक करने के लिए किया जाता है:
जब एक विकृत बैच सदस्य एक आंतरिक ऐरे में स्वीकार कर लिया जाता है लेकिन दूसरे में नहीं, तो बाद के अनुरोध गलत हैंडलर से संबद्ध हो सकते हैं। इसलिए एक अनुरोध को एक रूट के रूप में मान्य किया जा सकता है लेकिन दूसरे रूट के कॉलबैक का उपयोग करके निष्पादित किया जा सकता है।
सुरक्षा प्रभाव:
author__not_in SQL इंजेक्शनप्रभावित WP_Query कार्यान्वयन SQL NOT IN (...) स्थिति बनाने के लिए उपयोग करने से पहले author__not_in को लगातार सामान्यीकृत नहीं करता है।
यह पैरामीटर सामान्यतः पूर्णांक लेखक आईडी की सूची की अपेक्षा करता है। यदि एक स्केलर स्ट्रिंग अभीष्ट REST-स्कीमा वैलिडेशन के बिना भेद्य क्वेरी निर्माण तक पहुँचती है, तो असुरक्षित SQL संरचना डेटाबेस क्वेरी में जीवित रह सकती है।
सुरक्षा प्रभाव:
| WordPress ब्रांच | प्रभावित | फिक्स्ड रिलीज़ |
|---|---|---|
| 6.8.x | केवल CVE-2026-60137: 6.8.0–6.8.5 | 6.8.6 |
| 6.9.x | दोनों समस्याएँ: 6.9.0–6.9.4 | 6.9.5 |
| 7.0.x | दोनों समस्याएँ: 7.0.0–7.0.1 | 7.0.2 |
| 7.1 prerelease | Beta 1 प्रभावित | Beta 2 |
| 6.8 से पहले | इन दोनों CVEs से प्रभावित नहीं | N/A |
WordPress ने 17 जुलाई, 2026 को फिक्स जारी किए और गंभीरता के कारण प्रभावित इंस्टॉलेशन के लिए अनिवार्य स्वचालित अपडेट सक्षम किए।
Unauthenticated client | v WordPress REST batch endpoint | v Malformed batch member creates request/handler misalignment | v Later request is validated against one route but dispatched using another route's handler | v Scalar author_exclude reaches WP_Query as author__not_in | v Unsafe value reaches SQL NOT IN (...) construction | v Blind SQL timing or Boolean oracle | v Potential database compromise | v Potential application-level compromise and RCE
डिटेक्टर को route-confusion और SQL-injection प्राइमिटिव्स की पुष्टि करने के बाद रुक जाना चाहिए। किसी प्रभावित इंस्टॉलेशन के असुरक्षित होने को स्थापित करने के लिए उसे डेटा निकालने या कमांड निष्पादित करने की आवश्यकता नहीं है।
---
## डिटेक्शन कार्यप्रवाह
### चरण 1 — टारगेट को नॉर्मलाइज़ करें
टूल:
1. डिफ़ॉल्ट `http` या `https` स्कीम न होने पर जोड़ता है।
2. WordPress इंस्टॉलेशन पथ को नॉर्मलाइज़ करता है।
3. असमर्थित URL स्कीम और एम्बेडेड क्रेडेंशियल्स को अस्वीकार करता है।
4. रिडायरेक्ट, प्रॉक्सी, TLS और टाइमआउट नीतियों को लागू करता है।
### चरण 2 — WordPress की पहचान करें
स्कैनर निम्न की जाँच करता है:
- `wp-content/` संदर्भ।
- `wp-includes/` संदर्भ।
- WordPress जनरेटर मेटाडेटा।
- REST API डिस्कवरी लिंक।
- WordPress REST इंडेक्स संरचना।
- `wp/v2` नेमस्पेस।
- वैकल्पिक फ़ीड और `readme.html` फ़िंगरप्रिंट।
### चरण 3 — संस्करण निर्धारित करें
संस्करण के साक्ष्य निम्न से प्राप्त हो सकते हैं:
- HTML जनरेटर मेटाडेटा।
- फ़ीड जनरेटर मेटाडेटा।
- WordPress कोर एसेट क्वेरी स्ट्रिंग्स।
- HTTP जनरेटर हेडर।
- `readme.html`।
- एक स्थानीय `wp-includes/version.php` फ़ाइल।
साक्ष्य को स्कोर किया जाता है और समेकित किया जाता है। परस्पर विरोधी रिमोट संस्करण संकेतक विश्वास को कम करते हैं।
### चरण 4 — batch-route एक्सपोज़र जाँचें
स्कैनर निम्न के माध्यम से `/batch/v1` खोजने का प्रयास करता है:```text
/?rest_route=/
/wp-json/
मार्ग को निम्न में से किसी एक का उपयोग करके संबोधित किया जा सकता है:```text /?rest_route=/batch/v1 /wp-json/batch/v1
### चरण 5 — सुरक्षित रूट-कन्फ्यूजन जांच
सुरक्षित जांच में शामिल हैं:
1. एक जानबूझकर विकृत आंतरिक पथ।
2. एक अमान्य पोस्ट ID के लिए अनुरोध जिसमें एक हानिरहित नेस्टेड सार्वजनिक `GET` शामिल है।
3. एक अनुवर्ती `/batch/v1` अनुरोध।
कोई संवेदनशील सर्वर एक बाहरी `207 Multi-Status` प्रतिक्रिया लौटाता है जिसमें अमान्य पोस्ट अनुरोध को नेस्टेड बैच अनुरोध के रूप में संसाधित किया जाता है।
डिटेक्टर रिपोर्ट करता है:```text
route-confusion-observed
जब यह देखता है:
parse_path_failed मार्कर।207 वाला एक दूसरा बाहरी प्रतिक्रिया।responses ऐरे जो दर्शाता है कि हानिरहित आंतरिक अनुरोध चला।एक गैर-विनाशकारी SQLi वैलिडेटर को युग्मित अनुरोध भेजने चाहिए जो केवल एक स्थिर बूलियन शर्त द्वारा भिन्न हों:```text False control -> no deliberate database delay True test -> deliberate database delay
वैलिडेटर को यह करना होगा:
- बाहरी HTTP `207` को स्वीकार करे।
- बाहरी और नेस्टेड दोनों बैच एनवेलप्स को पार्स करे।
- गलत-प्रारूप वाले अनुरोध मार्करों को सत्यापित करे।
- यह सुनिश्चित करे कि SQLi-युक्त नेस्टेड अनुरोध ने एक मान्य प्रतिक्रिया लौटाई।
- कई सही और गलत नमूने एकत्र करे।
- नमूना क्रम को यादृच्छिक या अंतर्विष्ट (interleave) करे।
- एकल अनुरोध के बजाय माध्यिकाओं (medians) की तुलना करे।
- अपर्याप्त मापों को `inconclusive` के रूप में रिपोर्ट करे।