CVE-2026-44212: cross-site scripting (XSS) no PrestaShop — apoio ao cliente e email do formulário de contacto

Se tens uma loja PrestaShop, há uma diferença entre estar a correr uma versão antiga e estar realmente exposto a uma falha concreta. A CVE-2026-44212 é um aviso de segurança relacionado com apoio ao cliente e email do formulário de contacto. Vou explicar o que foi identificado, que condições importam e como podes agir sem transformar uma atualização numa dor de cabeça.

O que aconteceu?

Um atacante sem conta podia enviar um email malicioso pelo formulário de contacto, persistido e executado ao abrir a conversa no back office.

O problema foi identificado numa funcionalidade associada ao PrestaShop. A presença do ponto de entrada, os direitos necessários e a configuração podem alterar a exposição, por isso não convém tratar todas as instalações como iguais.

O detalhe técnico: como funciona a falha

Em XSS, um valor que devia ser apenas texto chega ao HTML e passa a ser interpretado como código pelo browser. A origem pode ser um formulário, uma variável Twig/Smarty, um anexo ou conteúdo já guardado na base de dados. A diferença entre XSS refletido e armazenado está em saber se o conteúdo malicioso surge diretamente na resposta ou se persiste para ser visto mais tarde.

Uma validação genérica de HTML não basta para todos os contextos: texto HTML, atributos, URLs e JavaScript exigem neutralizações diferentes. Em Twig é importante preservar o escape automático; em Smarty, rever as saídas de variáveis e usar escape apropriado. Evita apresentar dados de clientes como HTML confiável.

O atacante nem precisava de ter conta: bastava submeter o formulário público de contacto com um endereço de email especialmente preparado. O valor era guardado e chegava ao ecrã de apoio ao cliente do back office sem neutralização adequada. Ao abrir a conversa, o funcionário podia executar código JavaScript controlado pelo atacante. É um exemplo clássico de como um dado aparentemente inofensivo, como um email, se torna perigoso no contexto errado. As versões corrigidas são 8.2.6 e 9.1.1.

Qual é o impacto real?

Em determinadas condições, o problema pode permitir execução de JavaScript no browser de quem visualizar o conteúdo e, conforme a sessão, realização de ações com os privilégios dessa pessoa. Isso não significa que a loja já tenha sido atacada, nem que todas as instalações possam ser exploradas da mesma forma. A gravidade depende da versão, da configuração, da autenticação necessária e dos direitos que o processo tem no servidor.

Também convém distinguir o alcance do núcleo da aplicação do alcance de um módulo de terceiros: uma falha numa extensão não transforma automaticamente todas as lojas PrestaShop em alvos vulneráveis.

Que versões estão afetadas?

• Componente: apoio ao cliente e email do formulário de contacto
• Versões abrangidas no registo: anterior a 8.2.6; 9.0 anterior a 9.1.1
• Versão de correção: 8.2.6 e 9.1.1
• Divulgação do registo: 2026-05-14

Estes dados servem para fazer a primeira triagem. Se usas overrides, patches próprios ou versões personalizadas, verifica também o código realmente instalado. O número de versão apresentado no back office nem sempre conta a história toda.

Como corrigir a CVE-2026-44212?

1. Inventaria a instalação. Regista a versão do PrestaShop, a versão do módulo quando aplicável e o ambiente PHP. Confirma se usas apoio ao cliente e email do formulário de contacto.
2. Compara as versões. O registo refere como afetadas: anterior a 8.2.6; 9.0 anterior a 9.1.1. Cruza este dado com o aviso do fabricante: condições especiais podem limitar o impacto.
3. Cria um backup completo. Inclui ficheiros, base de dados e configurações, e ensaia a intervenção numa cópia de staging quando possível.
4. Aplica a correção. A versão com correção indicada para este registo é 8.2.6 e 9.1.1. Se já estás num ramo mais recente, confirma no aviso oficial que a correção está incluída na tua release e que todos os módulos estão atualizados.
5. Testa o que interessa. Valida login, carrinho, checkout, área de cliente, back office, emails e integrações usadas pela loja.
6. Revê a exposição anterior. Não basta a correção funcionar; se a falha esteve acessível, olha para os logs e para alterações inesperadas.

Como saber se houve uma tentativa de exploração?

Confirma a origem dos dados apresentados ou exportados, procura valores inesperados guardados na base de dados e reproduz a visualização apenas numa cópia de testes. No caso de XSS, revê as sessões administrativas afetadas; no caso de CSV, não abras ficheiros suspeitos num posto de trabalho com acesso privilegiado.

Se utilizas Cloudflare ou outra WAF, considera-a uma camada de mitigação: não substitui a atualização do código vulnerável.

Ponto de atenção para developers

A verificação do código deve começar no componente indicado acima. Segue a origem dos dados recebidos por HTTP (Tools::getValue(), pedidos AJAX, uploads ou headers), identifica onde entram numa operação sensível e confirma se existem validações no servidor. Verifica também se os overrides e módulos próprios reintroduzem o mesmo padrão, mesmo depois de aplicar o patch oficial.

E se não quiser mexer sozinho na loja?

Uma intervenção segura não é apenas clicar em «atualizar». É perceber as dependências, preparar rollback, aplicar o patch adequado e garantir que o negócio continua a funcionar.

Queres que verifique e resolva esta vulnerabilidade na tua loja PrestaShop? Posso analisar as versões e os módulos, validar a exposição, aplicar as correções e testar as funcionalidades principais. Fala comigo e vemos a melhor forma de tratar disso, com calma e sem alarmismos.

Nota editorial: o conteúdo explica a informação pública disponível e não constitui prova de exploração da tua loja. Sempre que o aviso não confirma uma versão corrigida, essa limitação é assinalada expressamente.