
Docker-आधारित प्रयोगशाला CVE-2026-49060 को पुन: प्रस्तुत करने के लिए, जो WooCommerce WordPress प्लगइन के लिए Hippoo Mobile App में एक अप्रमाणित विशेषाधिकार वृद्धि है। यह कमजोर 1.9.4 और पैच किए गए 1.9.5 संस्करणों की तुलना Python PoC के साथ करता है।
इस रिपॉजिटरी में CVE-2026-49060 को पुन: उत्पन्न करने और मान्य करने के लिए एक स्थानीय Docker लैब शामिल है, जो WordPress प्लगइन Hippoo Mobile App for WooCommerce को प्रभावित करने वाली एक Incorrect Privilege Assignment कमजोरी है।
संवेदनशील व्यवहार Hippoo के क्लोन किए गए REST API नेमस्पेस के माध्यम से उजागर होता है:```text /wc-hippoo/v1/ext/
कमजोर लक्ष्य में, एक अनधिकृत आगंतुक एक क्लोन किए गए WordPress REST उपयोगकर्ता मार्ग तक पहुँच सकता है और एक अनधिकृत HTTP अनुरोध के माध्यम से प्रशासक उपयोगकर्ता का पासवर्ड अपडेट कर सकता है। पैच किए गए लक्ष्य में, वही अनुरोध `403 Forbidden` के साथ अवरुद्ध हो जाता है।
यह लैब दो Hippoo संस्करणों की तुलना करता है:
| सेवा | Hippoo संस्करण | उद्देश्य | URL |
| --------- | -------------: | ---------------------------- | ----------------------- |
| `vuln` | 1.9.4 | असुरक्षित तुलना लक्ष्य | `http://localhost:8081` |
| `patched` | 1.9.5 | पैच किया गया तुलना लक्ष्य | `http://localhost:8082` |
प्रदर्शित कमजोरी श्रृंखला है:```text
Unauthenticated visitor
→ Hippoo cloned REST namespace
→ /wc-hippoo/v1/ext/wp/v2/users/<id>
→ vulnerable permission handling allows access
→ unauthenticated GET exposes user data
→ unauthenticated POST can update the selected user's password
→ patched version blocks the same request with 403 Forbidden
यह लैब Hippoo 1.9.4 और Hippoo 1.9.5 का उपयोग करके असुरक्षित-बनाम-पैच किए गए प्राधिकरण व्यवहार को मान्य करती है।
लैब जानबूझकर स्थानीय Docker सेवाओं तक सीमित है। यह बाहरी सिस्टम को लक्षित नहीं करती है और इसमें पर्सिस्टेंस, वेब शेल, मैलवेयर, या बाहरी कॉलबैक शामिल नहीं हैं।
| दावा | साक्ष्य | इस लैब में कैसे सत्यापित करें |
|---|---|---|
CVE-2026-49060 Hippoo Mobile App for WooCommerce के संस्करण 1.9.4 तक को प्रभावित करता है। | सार्वजनिक सलाहकारियाँ Hippoo <= 1.9.4 / 1.9.4 तक को प्रभावित बताती हैं। | संदर्भ अनुभाग की समीक्षा करें और vuln सेवा संस्करण की तुलना करें। |
Hippoo 1.9.5 का उपयोग पैच किए गए तुलना लक्ष्य के रूप में किया जाता है। | सार्वजनिक सलाहकारी मेटाडेटा 1.9.5 को प्रभावित सीमा के लिए पैच किए गए संस्करण के रूप में पहचानता है। | docker compose logs init-vuln init-patched चलाएँ और आरंभिक प्लगइन संस्करणों की पुष्टि करें। |
| असुरक्षित व्यवहार Hippoo के क्लोन किए गए REST नेमस्पेस के माध्यम से उजागर होता है। | Hippoo बाहरी REST रूट्स को /wc-hippoo/v1/ext/ के अंतर्गत पुनः पंजीकृत करता है। | python3 poc/poc.py http://127.0.0.1:8081 http://127.0.0.1:8082 चलाएँ। |
Hippoo 1.9.4 इस लैब में क्लोन किए गए उपयोगकर्ता रूट तक अप्रमाणित पहुंच की अनुमति देता है। | लैब PoC को http://127.0.0.1:8081/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1 से 200 OK प्राप्त होता है। | 8081 के विरुद्ध केवल-पढ़ने योग्य सत्यापन कमांड चलाएँ। |
Hippoo 1.9.5 इस लैब में समान अप्रमाणित अनुरोध को रोकता है। | लैब PoC को http://127.0.0.1:8082/?rest_route=/wc-hippoo/v1/ext/wp/v2/users/1 से 403 Forbidden प्राप्त होता है। | 8082 के विरुद्ध केवल-पढ़ने योग्य सत्यापन कमांड चलाएँ। |
| इस स्थानीय लैब में असुरक्षित लक्ष्य एक अप्रमाणित POST के माध्यम से व्यवस्थापक पासवर्ड अपडेट कर सकता है। | --update-password का उपयोग करने पर सक्रिय PoC को असुरक्षित लक्ष्य से 200 OK प्राप्त होता है। | python3 poc/poc.py --update-password http://127.0.0.1:8081 चलाएँ। |
| पैच किया गया लक्ष्य अप्रमाणित पासवर्ड अद्यतन अनुरोध को रोकता है। | Hippoo 1.9.5 उसी क्लोन किए गए उपयोगकर्ता रूट के लिए निषिद्ध प्रतिक्रिया देता है। | दोनों लक्ष्यों के विरुद्ध सक्रिय सत्यापन चलाएँ। |
| PoC केवल HTTP-आधारित है। | poc/poc.py केवल HTTP अनुरोध भेजता है और Docker, WP-CLI, या कंटेनर API को कॉल नहीं करता है। | poc/poc.py का निरीक्षण करें। |
यह लैब Hippoo 1.9.4 का उपयोग असुरक्षित तुलना लक्ष्य के रूप में करती है क्योंकि सार्वजनिक सलाहकारियाँ 1.9.4 तक के संस्करणों को प्रभावित बताती हैं।
यह लैब Hippoo 1.9.5 का उपयोग पैच किए गए तुलना लक्ष्य के रूप में करती है क्योंकि सार्वजनिक सलाहकारी मेटाडेटा 1.9.5 को प्रदर्शित प्रभावित सीमा के लिए निश्चित संस्करण के रूप में पहचानता है।
सार्वजनिक CVE-2026-49060 रिकॉर्ड समस्या को उच्च स्तर पर गलत विशेषाधिकार असाइनमेंट / विशेषाधिकार वृद्धि के रूप में वर्णित करता है। यह लैब Hippoo 1.9.4 और Hippoo 1.9.5 के बीच अवलोकनीय प्राधिकरण व्यवहार पर केंद्रित है।
इस README में मूल-कारण सारांश लैब में उपयोग किए गए असुरक्षित और पैच किए गए Hippoo संस्करणों के बीच स्रोत तुलना पर आधारित है।
यह लैब प्रत्येक Hippoo रूट का परीक्षण करने का दावा नहीं करती है। यह क्लोन किए गए WordPress उपयोगकर्ता REST रूट पर केंद्रित है:```text /wc-hippoo/v1/ext/wp/v2/users/
प्रयोगशाला निम्नलिखित प्रदर्शित नहीं करती:
* स्थायित्व,
* वेब शैल अपलोड,
* मनमाना कमांड निष्पादन,
* बाहरी कॉलबैक,
* मैलवेयर व्यवहार,
* गैर-प्रयोगशाला प्रणालियों पर हमले,
* या स्थानीय पासवर्ड अद्यतन सत्यापन से परे पोस्ट-समझौता गतिविधि।
## मूल कारण सारांश
मूल कारण Hippoo की भूमिका और अनुमति प्रबंधन में एक अनुमति तर्क दोष है।
Hippoo अपने स्वयं के नामस्थान के अंतर्गत क्लोन किए गए WordPress और WooCommerce REST रूट्स को उजागर करता है:```text
/wc-hippoo/v1/ext/
रूट-क्लोनिंग व्यवहार सुरक्षा-संवेदनशील है क्योंकि क्लोन किए गए रूट को मूल रूट की प्राधिकरण आवश्यकताओं को संरक्षित या मजबूत करना चाहिए। यदि क्लोन किए गए रूट को एक अनुज्ञापूर्ण अनुमति कॉलबैक प्राप्त होता है, तो अप्रमाणित उपयोगकर्ता REST endpoints तक पहुंच सकते हैं जिन्हें प्रमाणीकरण और प्राधिकरण की आवश्यकता होनी चाहिए।
प्रासंगिक रूट-क्लोनिंग व्यवहार इस पैटर्न का अनुसरण करता है:
function re_register_external_routes() {
$server = rest_get_server();
$endpoints = $server->get_routes();
$new_namespace = $this->hippoo_namespace . '/ext';
foreach ($endpoints as $route => $handlers) {
if (strpos($route, $this->hippoo_namespace) === 0) {
continue;
}
foreach ($handlers as $handler) {
$default_permission_callback = array($this, 'is_user_wordpress_admin');
$permission_callback = apply_filters(
'hippoo_extension_permission_check',
$default_permission_callback,
$route,
$handler
);
register_rest_route(
$new_namespace,
$route,
array(
'methods' => $methods,
'callback' => $handler['callback'],
'args' => $handler['args'],
'permission_callback' => $permission_callback,
)
);
}
}
}
```
इच्छित सुरक्षा मॉडल है:```text
Original protected REST route
→ cloned into Hippoo namespace
→ permission callback still denies unauthenticated access
```
असुरक्षित व्यवहार इसलिए होता है क्योंकि Hippoo `1.9.4` दो अलग-अलग अवस्थाओं के लिए समान वापसी मान का उपयोग करता है:```text
administrator / unrestricted access
unauthenticated visitor / no user
```
Hippoo `1.9.4` में, अनुमति सहायक `null` लौटाता है जब कोई लॉग-इन वर्डप्रेस उपयोगकर्ता नहीं होता है:```php
public static function get_user_permissions()
{
$user = wp_get_current_user();
if (empty($user) || !$user->exists()) {
return null;
}
if (in_array('administrator', (array) $user->roles)) {
return null; // Full access
}
$settings = get_option('hippoo_permissions_settings', []);
foreach ((array) $user->roles as $role) {
if (!isset($settings[$role])) {
continue;
}
return $settings[$role];
}