CVE-2026-84186: falha de autenticação no PrestaShop — Tools::getRemoteAddr atrás de proxy ou CDN
PrestaShop e CVE-2026-84186: explico a falha de autenticação em Tools::getRemoteAddr atrás de proxy ou CDN, o impacto real, as versões afetadas e os passos para corrigir sem complicar a tua loja.

// nesta página (8)
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-84186 é um aviso de segurança relacionado com Tools::getRemoteAddr atrás de proxy ou CDN. 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?
A interpretação de X-Forwarded-For podia aceitar um IP controlado pelo visitante e contornar verificações baseadas na origem.
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
A autenticação só é segura quando cada operação importante valida o contexto certo: sessão, token, identidade, assinatura e eventual ligação entre o utilizador e o recurso pedido. Verificar apenas se existe um cookie ou se o pedido vem de uma rota conhecida não chega.
Em cenários com proxies, serviços externos ou pagamentos, também é fundamental validar a origem lógica da informação em vez de confiar automaticamente em cabeçalhos HTTP ou valores enviados pelo cliente. Um bypass de autenticação não implica sempre privilégios totais: o impacto depende da funcionalidade atingida.
Qual é o impacto real?
Em determinadas condições, o problema pode permitir contorno de verificações de identidade, sessão ou assinatura numa funcionalidade sensível. 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: Tools::getRemoteAddr atrás de proxy ou CDN
- Versões abrangidas no registo: 8.0 anterior a 8.2.8; 9.0 anterior a 9.1.5
- Versão de correção: 8.2.8 e 9.1.5 segundo advisory GHSA
- Divulgação do registo: 2026-09-07
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-84186?
- 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 Tools::getRemoteAddr atrás de proxy ou CDN.
- Compara as versões. O registo refere como afetadas: 8.0 anterior a 8.2.8; 9.0 anterior a 9.1.5. Cruza este dado com o aviso do fabricante: condições especiais podem limitar o impacto.
- 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.
- Aplica a correção. A versão com correção indicada para este registo é 8.2.8 e 9.1.5 segundo advisory GHSA. 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.
- Testa o que interessa. Valida login, carrinho, checkout, área de cliente, back office, emails e integrações usadas pela loja.
- 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?
Consulta os logs de autenticação, back office e API para identificar pedidos anormais ao ponto de entrada. Revê as permissões atribuídas e procura operações incompatíveis com o perfil do utilizador. Guarda evidência antes de fazer alterações num possível incidente.
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.
// Fontes
- Registo CVE — CVE-2026-84186 cve.org ↗
- PrestaShield — base de vulnerabilidades PrestaShop prestashield.com ↗