A falha de autorização do Drupal Commerce Core já está a ser explorada

As lojas online construídas sobre o Drupal Commerce estão a ser atacadas através de uma vulnerabilidade de autorização classificada como "highly critical" no módulo Commerce Core. A equipa de segurança do Drupal confirmou que a falha já está a ser explorada e existem versões corrigidas para os dois ramos suportados.

O que aconteceu

A vulnerabilidade, identificada como CVE-2026-118539, é uma falha de falta de autorização no Commerce Core, o módulo que dá a um site Drupal o carrinho de compras, o fluxo de checkout e as API usadas pelas lojas desacopladas (headless). Certas rotas e campos de entidade não estão devidamente protegidos, pelo que um pedido que devia ser rejeitado pode passar. O resultado prático é um contorno do controlo de acesso que pode atingir diretamente a carteira do comerciante.

Versões afetadas:

• Commerce Core 2.x (ramo 8.x-2.x), até à 2.41 inclusive
• Commerce Core 3.x, anteriores à 3.3.13

Ainda não foi atribuída uma pontuação CVSS, mas os responsáveis pelo projeto classificam o problema como "highly critical", o nível máximo da escala de severidade do Drupal. A exploração em ambiente real está confirmada. Não há detalhes públicos sobre quem está por trás dos ataques, quantas lojas foram afetadas ou o que os atacantes fazem depois de entrarem.

Porque é que importa

Os módulos de comércio estão exatamente no caminho do dinheiro. Uma lacuna de autorização nessa camada não é um risco abstrato: consoante as rotas e campos expostos, um atacante pode ler ou alterar encomendas, manipular preços e promoções ou aceder a dados de clientes que normalmente exigem uma conta autenticada.

Este tipo de ataque é também silencioso. Não há malware para detetar nem falhas de serviço que chamem a atenção, apenas pedidos HTTP que parecem tráfego normal da loja. Se a deteção depende de anomalias no comportamento do servidor, um contorno de acesso pode passar semanas sem ser notado.

As correções de segurança do Drupal são alvo de engenharia inversa muito depressa. Assim que a correção é pública, o diff mostra aos atacantes exatamente onde procurar, e é por isso que o intervalo entre "aviso publicado" e "exploração em massa" não para de encurtar.

Entretanto, o PHP2Shell continua a ser testado

O aviso do Drupal surge enquanto duas falhas críticas no próprio PHP, CVE-2026-109618 e CVE-2026-109619 (ambas com CVSS 9.2 e conhecidas em conjunto como PHP2Shell), continuam a atrair tentativas de exploração.

A 25 de outubro, cerca de 52% das organizações monitorizadas continuavam a ser consideradas significativamente expostas, um valor em queda mas longe de zero. Destacam-se dois tipos de atividade: tentativas que reproduzem a cadeia pública de prova de conceito e ferramentas "de marca PHP2Shell" que, na realidade, assentam no envenenamento de sessões e numa falha independente de inclusão local de ficheiros, e não nos erros do PHP.

A boa notícia, para já, é a fiabilidade. Provocar o esgotamento de memória por si só não completa a cadeia, e as diferenças entre compilações de PHP, limites de memória e comportamento dos processos worker costumam quebrar as fases seguintes. A má notícia é que os atacantes oportunistas estão a trabalhar ativamente para transformar as PoC públicas em ferramentas fiáveis, e a história diz que normalmente conseguem.

O que fazer

1. Atualize o Commerce Core hoje. Passe os sites 3.x para a 3.3.13 e os 2.x para a 8.x-2.41. Trate a mudança como uma emergência, não como uma intervenção agendada.
2. Se não puder atualizar de imediato, restrinja o acesso às rotas do Commerce no proxy inverso ou na WAF, reveja as permissões dos papéis anónimo e autenticado e pondere colocar o checkout offline durante as poucas horas que um deploy exige.
3. Procure sinais de abuso. Reveja os registos web à procura de pedidos não autenticados ou com poucos privilégios a rotas de encomendas, pagamentos, promoções e produtos, e verifique alterações inesperadas em preços, descontos, encomendas ou fichas de clientes.
4. Feche também a brecha do PHP. Confirme que o runtime de PHP em cada servidor web está numa versão que corrige o PHP2Shell e procure eventuais falhas de inclusão local de ficheiros no seu próprio código, porque é nelas que parte das ferramentas usadas em ataques reais se apoia.
5. Conheça todas as instâncias Drupal que possui. Os sites de staging, demo e de marketing esquecidos correm muitas vezes o mesmo módulo Commerce sem nenhuma das proteções de produção.

Falhas como a CVE-2026-118539 são exatamente o que o nosso serviço de análise de vulnerabilidades foi concebido para expor: identifica versões desatualizadas do núcleo do Drupal e dos módulos contribuídos em todos os seus hosts públicos, para que um checkout vulnerável seja assinalado antes que alguém o encontre.