CVE-2026-93659-writeup

XSS armazenado no Concrete CMS Community Store leva à tomada de controle do painel de administração

O Community Store, um complemento de e-commerce de código aberto para o Concrete CMS, armazenava campos de pedido fornecidos pelo cliente sem sanitizá-los e os renderizava sem escape de HTML em quatro visualizações voltadas ao administrador. Qualquer visitante não autenticado poderia fazer um pedido com um payload de script em um campo como o primeiro nome de cobrança, e o payload seria executado dentro da sessão autenticada do painel de um gerente de loja na próxima vez que ele abrisse aquele pedido, o suficiente para criar uma conta de administrador maliciosa ou exfiltrar dados de sessão.

O Que Está Afetado

Todo pedido carrega campos fornecidos pelo cliente: primeiro nome, sobrenome, e-mail e telefone de cobrança/entrega. Esses campos são armazenados como estão e renderizados de volta em quatro lugares que um gerente de loja costuma consultar:

• a visualização de pedido no admin (single_pages/dashboard/store/orders.php)
• o comprovante de pedido imprimível (elements/order_slip.php)
• o relatório de vendas (single_pages/dashboard/store/reports/*.php)
• a página de confirmação de checkout voltada ao cliente (single_pages/checkout/complete.php)

Crucialmente, fazer um pedido não exige conta. A configuração de checkout como convidado do Community Store tem como padrão always, definida dessa forma pelo próprio instalador do pacote em toda instalação nova, não algo que o operador da loja precise habilitar. Portanto, este não é um bug que exige uma loja mal configurada; é explorável contra uma instalação padrão, pronta de fábrica, sem exigir credenciais.

Mitigação

Atualize o Community Store para 2.7.8 ou posterior. A correção adiciona escape de saída adequado em todos os quatro locais de renderização afetados. Não há solução alternativa por configuração além da atualização, já que o comportamento vulnerável é o próprio escape, não um toggle.

Detalhes Técnicos

Nenhum dos quatro locais de renderização escapava os campos controlados pelo cliente. Uma linha representativa da visualização de pedido no admin:

Nenhuma chamada a h(), o helper padrão de escape de saída do Concrete, em lugar algum próximo, embora o mesmo arquivo usasse h() corretamente algumas linhas adiante para outros valores. A validação de entrada não era melhor: a única verificação aplicada a esses campos era um limite de comprimento (1-255 caracteres), nada que removesse ou rejeitasse HTML.

Um payload <script> com menos de 255 caracteres no campo de primeiro nome de cobrança passa pela validação intacto, é armazenado e depois é renderizado sem escape onde quer que um admin veja o pedido.

O padrão de checkout como convidado é definido diretamente no instalador:

O controlador de checkout só força um login quando essa configuração é off (ou option sem uma flag de convidado), e com o padrão instalado, esse ramo nunca é acionado.

Prova de Conceito

Testado contra o Community Store v2.7.7 no Concrete CMS 9.5.2 (laboratório Docker auto-hospedado, PHP 8.3). Payload enviado como um checkout comum de convidado, sem autenticação de qualquer tipo:

1. O atacante envia um checkout de aparência normal com o payload acima. Sem conta, sem sessão, sem cookies.
2. Um gerente de loja abre Dashboard > Store > Orders e visualiza o pedido (o payload dispara igualmente a partir do comprovante de pedido, do relatório de vendas ou do próprio e-mail de confirmação do cliente; qualquer um dos quatro caminhos de renderização sem escape funciona).
3. O script é executado com a sessão autenticada do gerente de loja e o token CSRF. Para confirmar o impacto real em vez de apenas uma caixa de alerta, hospedei o payload eu mesmo, como faria um atacante externo, e usei-o para enviar programaticamente o formulário "adicionar administrador" de dentro daquela sessão, transformando um único pedido malicioso em uma tomada de controle completa de conta de administrador.

Cronologia de Divulgação

• Reportado ao mantenedor por meio de um aviso de segurança privado no GitHub
• Correção enviada por Ryan Hewitt como commit 2a802d6, adicionando escape com h() em todos os quatro locais de renderização afetados
• Correção incluída na versão v2.7.8
• CVE-2026-93659 publicado via VulnCheck como CNA, com crédito a mim como descobridor

Lições

• O escape de saída precisa ser aplicado de forma consistente em todos os caminhos de renderização de um determinado valor, não apenas nos óbvios. Este bug foi lançado por anos porque três dos quatro locais de renderização aparentemente nunca foram revisitados depois que o quarto foi tratado corretamente.
• "Exige uma conta" não é uma suposição segura na qual basear um modelo de ameaças para um complemento com acesso de convidado configurável. Verifique o padrão realmente distribuído, não a configuração teoricamente segura.
• Complementos de marketplace/comunidade para plataformas CMS populares são um bom ponto de partida para caça a bugs: base de instalação real, genuinamente menos auditados que o núcleo.

Referências

• CVE-2026-93659
• Commit de correção 2a802d6
• Notas de versão v2.7.8
• Repositório do Community Store