Falha 9.1 no Adobe Commerce permite roubar conta de cliente

A Adobe publicou em 11 de agosto de 2026 o boletim de segurança APSB26-92, que corrige sete vulnerabilidades no Adobe Commerce, no Adobe Commerce B2B e no Magento Open Source. A mais grave é a CVE-2026-71362, uma falha de autorização incorreta com nota CVSS 9.1 que permite a um atacante sem qualquer credencial assumir a conta de um cliente da loja.

No dia seguinte à publicação do boletim, a empresa de segurança para comércio eletrônico Sansec informou que seu firewall de aplicação web, o Shield, já estava bloqueando tentativas de exploração da falha. A Adobe, por sua vez, declara no boletim que não tem conhecimento de exploração ativa para nenhuma das vulnerabilidades corrigidas — uma divergência importante que os administradores precisam considerar ao priorizar a correção.

A análise da Sansec, feita a partir do patch divulgado pela Adobe, identificou a causa: o Magento trata de forma incorreta a identidade do cliente dentro de uma sessão de conta, o que permite ao atacante trocar a sessão de um cliente para a conta de outro cliente, ganhando acesso à conta da vítima e a seus dados privados.

O que o boletim do Adobe Commerce corrige

Segundo o boletim da Adobe, a exploração da CVE-2026-71362 não exige conta existente, privilégios administrativos nem interação do usuário. O vetor CVSS 3.1 publicado é AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, ou seja: ataque pela rede, complexidade baixa, sem privilégios e sem interação, com impacto alto sobre confidencialidade e integridade e nenhum impacto sobre disponibilidade. É a combinação que costuma produzir exploração rápida assim que um exploit público circula.

As demais falhas do boletim são:

Vale registrar um detalhe do processo de divulgação: a Adobe incluiu no boletim uma nota informando que, a partir de 11 de agosto de 2026, poderá atribuir um único identificador CVE a vulnerabilidades descobertas internamente que compartilhem a mesma classificação de gravidade e a mesma categoria CWE quando a versão incluir correções sistêmicas. Isso significa que a contagem de sete CVEs não corresponde necessariamente a sete defeitos isolados no código.

A CVE-2026-71362 foi reportada pelo pesquisador identificado como 0x0.eth. As quatro falhas de XSS e de bypass de autorização de gravidade alta foram creditadas ao pesquisador identificado como wohlie.

Versões afetadas e como corrigir

O boletim recebeu prioridade 2 na escala da Adobe. As linhas afetadas são:

• Adobe Commerce: 2.4.9-2026-jul, 2.4.8-2026-jul, 2.4.7-2026-jul, 2.4.6-2026-jul, 2.4.5-2026-jul e 2.4.4-2026-jul, e versões anteriores de cada linha.
• Adobe Commerce B2B: 1.5.3-2026-jul, 1.5.2-2026-jul, 1.4.2-2026-jul, 1.3.4-2026-jul e 1.3.3-2026-jul, e anteriores.
• Magento Open Source: 2.4.9-2026-jul, 2.4.8-2026-jul, 2.4.7-2026-jul e 2.4.6-2026-jul, e anteriores.

As versões corrigidas seguem o mesmo padrão com o sufixo -2026-aug. Há uma armadilha operacional relevante aqui: como aponta a Sansec, essas correções mensais são distribuídas como arquivos de patch isolados, e não como uma nova versão de segurança ou pacotes atualizados no Composer. Antes de aplicar o patch correspondente, o administrador precisa garantir que a instalação já está na última versão -p disponível para sua linha de release. Aplicar o patch sobre uma base desatualizada tende a falhar ou a deixar a correção incompleta.

Mitigação na camada de hospedagem

Pelo menos um provedor especializado em hospedagem de comércio eletrônico já adotou bloqueio na infraestrutura. A Hypernode publicou em seu changelog, em 11 de agosto, o anúncio de uma regra no nível do Nginx aplicada a toda a plataforma, que bloqueia tentativas de exploração antes que a requisição alcance a aplicação Magento. A empresa deixa explícito que o bloqueio cobre o vetor de tomada de conta na camada da plataforma, mas não substitui o patch da Adobe, já que as demais falhas do boletim — incluindo os dois XSS armazenados — continuam abertas sem ele.

Essa distinção é o ponto prático mais importante desta correção. Uma regra de WAF ou de servidor web mitiga o vetor conhecido no momento em que foi escrita. Ela não corrige a lógica de tratamento de identidade de sessão que originou a falha, e tende a ser contornada assim que uma variante do payload aparecer.

Por que esse tipo de falha importa em comércio eletrônico

Uma tomada de conta de cliente em uma loja online costuma ser subestimada porque não envolve acesso administrativo. O dano, porém, é concreto e direto sobre o titular dos dados: histórico de pedidos, endereço residencial completo, telefone, e-mail, documentos eventualmente cadastrados e, dependendo da configuração da loja, meios de pagamento salvos com os últimos dígitos visíveis. É material suficiente tanto para fraude de identidade quanto para golpes subsequentes de engenharia social altamente convincentes, do tipo em que o criminoso liga citando o pedido real que a vítima acabou de fazer.

Para lojistas brasileiros, há um componente adicional: dados pessoais de clientes acessados indevidamente configuram incidente de segurança sujeito às obrigações da LGPD, incluindo a comunicação à Autoridade Nacional de Proteção de Dados e aos titulares quando houver risco relevante. Isso significa que a decisão de “aplicar o patch na próxima janela de manutenção” precisa ser pesada contra a possibilidade de um incidente notificável em curso.

O Magento e o Adobe Commerce também carregam um histórico particular. A plataforma é alvo recorrente de campanhas de skimming de cartão — o chamado Magecart — em que o atacante injeta JavaScript malicioso na página de checkout para capturar dados de pagamento digitados pelo cliente. Falhas que permitem manipular sessões ou injetar conteúdo armazenado são exatamente o tipo de porta de entrada que esse tipo de operação procura.

O que ainda não está claro

• Não há confirmação independente de comprometimento bem-sucedido. O que a Sansec relata são tentativas de exploração bloqueadas pelo seu produto. Tentativa bloqueada não é o mesmo que loja invadida, e a Adobe mantém a posição de não ter conhecimento de exploração ativa.
• Não há número público de instâncias vulneráveis expostas na internet, nem estimativa de quantas lojas já aplicaram o patch.
• A CVE-2026-71362 não constava do catálogo KEV da CISA no momento em que este texto foi escrito. Uma eventual inclusão mudaria o quadro de prioridade para órgãos públicos norte-americanos e serviria como sinal forte de exploração confirmada.
• Detalhes técnicos do exploit não foram divulgados, e isso é adequado: publicá-los antes que a base instalada esteja corrigida ampliaria o risco sem benefício defensivo proporcional.

Recomendações

• Aplique o patch APSB26-92 assim que possível, começando por lojas com base de clientes cadastrados e dados de pagamento armazenados. Confirme antes que a instalação está na última versão -p da sua linha de release.
• Não trate a regra de WAF como solução definitiva. Se o seu provedor aplicou bloqueio na borda, isso compra tempo — não dispensa a correção, especialmente pelas duas falhas de XSS armazenado que levam a execução de código.
• Revise os logs de acesso em busca de padrões anômalos de troca de sessão, sequências de requisições a endpoints de conta de cliente vindas de um mesmo IP com identificadores de sessão distintos e acessos a áreas de conta sem o login correspondente registrado.
• Invalide sessões ativas após a correção. Se houver suspeita de exploração, forçar a expiração de todas as sessões de cliente é uma medida de contenção barata.
• Verifique a integridade do checkout. Compare os arquivos e o JavaScript servido nas páginas de pagamento com a versão esperada, considerando o histórico de campanhas de skimming contra a plataforma.
• Habilite e retenha logs de aplicação e de servidor web por período suficiente para permitir investigação retroativa, e monitore o boletim oficial da Adobe para eventuais atualizações.
• Prepare o processo de resposta sob a LGPD antes de precisar dele: definir quem avalia risco relevante e quem comunica a ANPD é trabalho que não se faz durante o incidente.

Conclusão

A CVE-2026-71362 reúne as características que costumam antecipar exploração em massa: nota 9.1, nenhum pré-requisito de autenticação, alvo com grande base instalada e correção distribuída por um processo de aplicação de patch que exige atenção manual. O fato de a Adobe e a Sansec divergirem sobre a existência de exploração ativa não deve ser lido como motivo para esperar — na prática, essa divergência é comum e reflete o que cada uma consegue observar a partir da própria telemetria.

O que observar a seguir: a eventual inclusão da falha no catálogo KEV da CISA, a publicação de análises técnicas mais detalhadas por pesquisadores independentes depois que a base instalada estiver majoritariamente corrigida, e a possível conexão da falha com campanhas de skimming, que historicamente aproveitam janelas exatamente como esta.

Fontes e referências

• Adobe — Security update available for Adobe Commerce | APSB26-92: helpx.adobe.com
• BleepingComputer — Hackers exploit critical Adobe Commerce flaw to hijack customer accounts: bleepingcomputer.com
• Hypernode — Release 10921: Magento Account Takeover Block: changelog.hypernode.com
• Sansec — Adobe Commerce account takeover (APSB26-92): sansec.io
• Adobe Experience League — Security update available for Adobe Commerce – APSB26-92: experienceleague.adobe.com