Vulnerabilidade ps_facetedsearch: a atualização PrestaShop que não pode adiar

Uma pontuação de 10 em 10, explorável sem qualquer conta

A 3 de junho de 2026, a equipa do PrestaShop publicou uma correção de emergência para o ps_facetedsearch, o módulo de pesquisa por facetas instalado por predefinição em quase todas as lojas desde a versão 1.7.1.0. A vulnerabilidade ps_facetedsearch agora corrigida tem a pontuação máxima da escala CVSS: 10.0.

Três características tornam-na temível:

• não exige qualquer autenticação: nem conta de cliente, nem acesso ao back-office;
• é explorada a partir do front-office, com um simples pedido HTTP;
• conduz à execução de código remoto, ou seja, à colocação de um ficheiro PHP controlável no seu servidor.

Por outras palavras, um robô que percorra lojas PrestaShop pode assumir o controlo da sua sem que nada apareça no histórico de administração.

Como funciona a vulnerabilidade

O módulo guarda em cache os blocos de filtros para não ter de recalcular as facetas em cada visita. Os valores dos filtros de cursor (preço, peso) são lidos no URL e depois armazenados em formato serializado nessa cache.

O problema surge na releitura. Até à versão 4.0.3, o módulo aplicava a esses valores a função nativa do PHP unserialize() sem validação suficiente a montante. Um atacante pode assim forjar um URL que contém um objeto PHP malicioso. Ao ser desserializado, esse objeto desencadeia uma cadeia de gadgets presente nas dependências do PrestaShop e acaba por escrever um ficheiro arbitrário na pasta do módulo.

A correção oficial substitui unserialize() por \Tools::unSerialize(), a camada segura do PrestaShop.

A sua loja está exposta?

Versões vulneráveis: 3.0.0 a 4.0.3. Versão corrigida: 4.0.4.

Confirme a versão instalada em Módulos > Gestor de módulos, procurando por «Pesquisa por facetas». Também pode ler a etiqueta <version> do ficheiro modules/ps_facetedsearch/config.xml.

Na base de dados, basta uma consulta:

SELECT name, version FROM ps_module WHERE name = 'ps_facetedsearch';

Abaixo de 4.0.4, considere a loja exposta, mesmo que os filtros só estejam visíveis nalgumas categorias: o controlador continua acessível.

A correção: dois caminhos possíveis

Atualizar o core. O PrestaShop publicou no mesmo dia as versões 8.2.7 e 9.1.4, que já incluem o módulo corrigido. É a via recomendada se já estiver perto dessas versões.

Atualizar apenas o módulo. Transfira o ps_facetedsearch 4.0.4 do repositório oficial e substitua a pasta. É a opção mais rápida quando subir a versão do core implica um verdadeiro trabalho de testes.

Em ambos os casos, esvazie var/cache/prod/ depois da operação e limpe a cache do módulo. Se não puder intervir de imediato, aplique as medidas de contenção publicadas com o comunicado de segurança: retirar os filtros de cursor dos templates públicos, limpar a cache da pesquisa por facetas e bloquear na firewall aplicacional os pedidos cuja query string contenha padrões de serialização PHP (O:, ;i:).

Verificar se a loja já foi visitada

Uma correção não fecha uma porta que já foi usada. Depois da atualização, procure vestígios da colocação de ficheiros.

Ficheiros PHP alterados recentemente nos módulos:

find modules/ -name "*.php" -mtime -60 -ls

Padrões típicos de backdoor:

grep -rl "eval(\$_POST\|eval(base64_decode\|assert(\$_REQUEST" modules/ themes/ override/

Verifique igualmente:

• a pasta modules/ps_facetedsearch/: qualquer ficheiro .php alheio à distribuição oficial é suspeito;
• os registos de acesso do alojamento, à procura de pedidos com cadeias anormalmente longas;
• a tabela ps_employee: uma conta de administrador desconhecida denuncia um comprometimento instalado há algum tempo;
• os ficheiros .htaccess e robots.txt, muitas vezes alterados para esconder páginas de spam.

Se encontrar alguma coisa, não se limite a apagar o ficheiro. Uma intrusão traz quase sempre uma segunda backdoor. É preciso mudar todas as palavras-passe dos funcionários, regenerar as chaves de config/settings.inc.php, incluindo a _COOKIE_KEY_, e repor uma cópia de segurança anterior à intrusão. O nosso artigo sobre uma loja PrestaShop pirateada descreve o procedimento completo.

A lição: um módulo nativo não é um módulo seguro

Muitos comerciantes vigiam os módulos de terceiros e deixam os módulos nativos entregues a si próprios. Este episódio lembra que o código fornecido por predefinição está presente em centenas de milhares de lojas: é precisamente esse que mais interessa aos atacantes.

Três hábitos reduzem o risco de forma drástica:

• acompanhar os comunicados de segurança do PrestaShop e da Friends-of-Presta;
• aplicar as correções de segurança em menos de 72 horas, passando por um ambiente de pré-produção quando a loja é complexa;
• manter um inventário das versões dos módulos, para responder em cinco minutos à pergunta «isto afeta-me?».

É exatamente isso que cobre um contrato de manutenção PrestaShop.

Precisa de uma auditoria imediata?

Verificamos a sua versão, aplicamos a correção e procuramos vestígios de intrusão. Diagnóstico gratuito, resposta em 1 h, das 9h às 22h, 7 dias por semana.