Drupal Commerce Core: falha explorada, atualize para a 3.3.13 agora

Invasores estão explorando uma falha de criticidade alta no Drupal Commerce Core, o módulo de carrinho de compras do sistema de gerenciamento de conteúdo Drupal, para fazer pedidos que nunca pagaram. A equipe de segurança do Drupal publicou o aviso SA-CONTRIB-2026-254 em 28 de outubro de 2026 e diz que o bug «está sendo explorado ativamente». Toda loja que usa o módulo precisa de duas coisas nesta semana: a atualização 3.3.13 ou 8.x-2.41 e uma auditoria dos pedidos recentes.

A falha é rastreada como CVE-2026-118539. O Drupal a pontua com 21 de 25, sua faixa «Highly critical», com o vetor AC:None/A:None/CI:Some/II:Some/E:Exploit/TD:All. Em linguagem simples: não é preciso login nem acesso especial, dados podem ser lidos e alterados, e existe um exploit.

O que a falha permite a um invasor

O módulo «não protege suficientemente certas rotas e campos de entidade», diz o aviso. Isso é um desvio de acesso: um visitante consegue chegar a páginas e campos de dados que deveriam estar bloqueados. O BleepingComputer relata que um invasor não autenticado pode usá-lo para contornar as regras de acesso da loja.

A Centarro, empresa que mantém o Drupal Commerce, descreveu os ataques em um post de seu CEO Ryan Szrama em 29 de outubro. Os lojistas viram quatro tipos de abuso:

• Pedidos feitos diretamente, pulando o checkout, de modo que o pedido existe, mas nunca foi pago.
• Pedidos que aparecem como pagos na tela de gestão sem nenhum registro de pagamento por trás, principalmente em sites que expõem o serviço web JSON:API.
• Preços de produtos reduzidos antes do checkout.
• Descontos, taxas ou outros ajustes que nenhum funcionário nem promoção adicionou.

«Recebemos dois relatos de tentativas de usuários mal-intencionados de fazer pedidos fraudulentos», escreveu Szrama. Alguns pedidos traziam preços claramente errados, como US$ 0,01. Outros usavam preços normais. «Até agora não acreditamos que tenha sido automatizado nem explorado além dos sites iniciais», acrescentou. A equipe de segurança do Drupal coordenou os testes, o empacotamento e o lançamento da correção em 28 de outubro.

Quem é afetado e o que instalar

O Drupal credita Dan Puccetti, Marcus Johansson e Robert Snyder pelo relato da falha. Seis pessoas, incluindo Szrama, são creditadas pela correção. O BleepingComputer estima a base instalada do módulo em mais de 42.000 sites, citando a página do projeto no drupal.org.

Ramo	Versões afetadas	Versão corrigida	Requisito do Drupal (segundo a Rescana)
Commerce Core 3.x	De 3.0.0 até a 3.3.13, sem incluí-la	3.3.13	Drupal 10.3 ou mais recente, ou Drupal 11
Commerce Core 8.x-2.x	Toda versão anterior à 8.x-2.41	8.x-2.41	Drupal 9.3 ou mais recente, ou Drupal 10

A correção não termina no Commerce Core. A Centarro diz que Commerce API, Commerce License, Commerce Shipping e Commerce Stripe também receberam versões de segurança em 28 de outubro e devem ser atualizados ao mesmo tempo. A Rescana observa que o Drupal publicou em paralelo cinco avisos do Commerce Core de menor gravidade, SA-CONTRIB-2026-255 a 259. Um aviso separado do Stripe, SA-CONTRIB-2026-263, é classificado como crítico e pode permitir que um invasor marque um pedido como pago sem pagar.

A Centarro também lembra aos usuários da 8.x-2.x que o suporte desse ramo termina quando o Drupal 12 for lançado. «Recomendamos atualizar para a 3.x o quanto antes», diz o post.

Há quanto tempo a brecha está aberta

O bug é antigo. A Centarro diz que exploits eram «teoricamente possíveis» desde o Commerce Core 8.x-2.18, lançado em 26 de maio de 2020, em sites que usam JSON:API. Para todos os outros sites, a janela se abriu com a 8.x-2.25 em 30 de junho de 2021. A Centarro apresenta essas datas como as mais antigas possíveis, não como datas de ataque confirmadas.

A falha não estava no catálogo de vulnerabilidades exploradas conhecidas (KEV) da CISA na edição de 29 de outubro, relata a Rescana. O rótulo de «explorada ativamente» vem do Drupal e da própria Centarro. A CISA já marcou cinco falhas do Drupal como exploradas ao longo dos anos, diz o BleepingComputer, a mais recente um bug de injeção de SQL, CVE-2026-9082, adicionado em maio de 2026. O próprio núcleo do Drupal corrigiu uma falha crítica de execução de código no Field UI há apenas duas semanas.

Como auditar seus pedidos

O patch fecha a porta. Ele não desfaz os pedidos que já passaram por ela. O aviso do Drupal diz que os sites «devem auditar seus pedidos em busca de inconsistências». O post da Centarro traz quatro verificações de banco de dados, cada uma como uma consulta que donos de loja podem executar:

1. Pedidos feitos fora do checkout que ainda têm saldo devedor.
2. Pedidos cujo valor pago registrado é maior que os pagamentos concluídos em arquivo.
3. Itens de pedido com preço unitário substituído. A Centarro observa que a primeira verificação deixaria passar um preço reduzido a US$ 0,01 e depois pago.
4. Ajustes, como taxas ou descontos personalizados, que não vieram de uma promoção.

Um resultado não é prova de fraude. Pedidos feitos pela equipe e produtos de «pague quanto quiser» também se encaixam, então cada pedido sinalizado precisa de uma revisão humana. A Rescana acrescenta que cruzar os endereços IP e horários dos pedidos sinalizados com os registros de acesso dos caminhos normais de checkout ajuda a separar os dois casos.

O conselho operacional da Centarro é mais direto: não envie um pedido porque ele foi feito ou porque o checkout foi concluído. Confirme o pagamento primeiro. E se o seu site não precisa que o JSON:API aceite alterações, coloque-o em modo somente leitura.

O que isso significa para desenvolvedores

• Aplique o patch hoje e depois audite até 2020. A correção é uma atualização comum do composer para 3.3.13 ou 8.x-2.41, mais os quatro módulos complementares. A auditoria é a parte lenta. Se o seu site expõe o JSON:API desde maio de 2020, as quatro consultas precisam percorrer cinco anos de pedidos, não a última semana.
• Trate «aparece como pago» como uma afirmação, não como fato. O segundo tipo de ataque cria pedidos que a tela de administração informa como pagos sem nenhuma entidade de pagamento por trás. Qualquer automação de envio que dependa apenas do estado do pedido confiava em um campo que o invasor podia definir. Verifique se a etapa de envio lê os registros de pagamento, não o estado do pedido.
• Lojas headless correm mais risco. Os dois tipos de ataque ligados ao JSON:API, e a data de início mais antiga de 2020, valem para sites desacoplados. Se a API só serve dados de produtos a um front-end, coloque-a em somente leitura agora, seja qual for a sua versão do Drupal.
• Fique de olho nos avisos complementares. A correção crítica separada do Commerce Stripe importa a quem usa o Stripe como gateway. Atualize-o no mesmo deploy do Commerce Core.
• Relate qualquer coisa estranha. A Centarro diz que «sempre prefere revisar relatos falsos positivos ou duplicados a não ficar sabendo de uma vulnerabilidade em potencial». Dois relatos de lojistas encontraram esse bug depois de cinco anos no código.