Tem uma loja Magento? Esta falha crítica troca a sessão dos seus clientes

Uma vulnerabilidade crítica no Adobe Commerce e no Magento Open Source está a ser alvo de tentativas de exploração poucos dias depois de ter sido corrigida. A falha, identificada como CVE-2026-71362 e com pontuação CVSS de 9.1, foi tapada no boletim APSB26-92, publicado pela Adobe a 11 de agosto de 2026, e permite, segundo a análise técnica da empresa neerlandesa Sansec, que um atacante sem qualquer conta na loja assuma o controlo da conta de um cliente. A Adobe classificou a atualização com prioridade 2 e afirma não ter conhecimento de exploração ativa; a Sansec diz o contrário, o que coloca os comerciantes num cenário familiar: patch disponível, janela de exposição aberta.

O que faz a CVE-2026-71362

A descrição oficial é sóbria: trata-se de uma vulnerabilidade de autorização incorreta que pode resultar em escalamento de privilégios, permitindo a um atacante obter acesso elevado a recursos sensíveis sem necessidade de interação do utilizador. Traduzido para a prática do comércio eletrónico, o impacto é bem mais concreto. A Sansec, que revisou o patch, indica que a exploração não exige conta existente, privilégios de administrador nem interação do utilizador, e que a falha permite ao atacante trocar uma sessão de cliente para outra conta de cliente, obtendo acesso à conta da vítima e aos respetivos dados privados. A correção da Adobe incide sobre a forma como o Magento trata a identidade do cliente na sessão de conta.

Numa loja online, isso significa potencial acesso a nome, endereços de entrega e faturação, histórico de encomendas, número de telefone e correio eletrónico — matéria-prima ideal para fraude subsequente, phishing altamente credível e engenharia social contra os próprios clientes. Análises técnicas independentes publicadas por desenvolvedores da comunidade Magento apontam o problema para o controlador de edição de conta do cliente, que preenchia o objeto de dados do cliente a partir de dados de formulário em sessão sem uma lista de permissões adequada. Não há, para já, um relatório forense público com casos confirmados de lojas comprometidas por esta via.

Adobe e investigadores divergem sobre a exploração

Este é o ponto que os responsáveis de lojas devem ler com atenção, porque as fontes não dizem o mesmo. A Adobe atribuiu prioridade 2 à atualização e declarou não ter conhecimento de exploração das vulnerabilidades corrigidas no APSB26-92, embora a natureza não autenticada e a baixa complexidade de ataque da CVE-2026-71362 tornem a aplicação rápida do patch determinante. Do lado da investigação, a Sansec afirma que a sua solução Shield já bloqueia tentativas de exploração.

Há ainda um indicador indireto de pressão real: pelo menos um alojador especializado em Magento reagiu ao nível da infraestrutura. O Hypernode indicou ter implementado uma regra a nível de Nginx em todos os seus nós, ativa por omissão, para bloquear tentativas de exploração antes de chegarem à aplicação Magento. Em rigor, «tentativas bloqueadas» não é o mesmo que «lojas comprometidas» — mas, no historial recente do Magento, o intervalo entre uma coisa e outra tem sido curto.

Cronologia do caso

Versões afetadas e as outras falhas do boletim

O boletim abrange as linhas atualmente suportadas de Adobe Commerce, Adobe Commerce B2B e Magento Open Source. Análises da comunidade indicam que a Adobe disponibilizou patches para 2.4.4-p18, 2.4.5-p17, 2.4.6-p15, 2.4.7-p10, 2.4.8-p5 e 2.4.9. No caso do Adobe Commerce B2B, a orientação passa por aplicar os pacotes correspondentes de agosto de 2026 nas linhas 1.3.3 a 1.5.3; no Magento Open Source, as instalações suportadas vão de 2.4.6 a 2.4.9. A lista exata deve ser sempre confirmada no boletim oficial APSB26-92, publicado no portal de segurança da Adobe.

Sobre o número total de problemas há convergência; sobre a contagem de «críticas», não. A Sansec fala em sete vulnerabilidades corrigidas, cinco delas críticas, enquanto outras leituras do boletim referem quatro críticas num total de sete. Entre as restantes falhas destacam-se, de acordo com análises publicadas: a CVE-2026-48416, de autorização incorreta e explorável sem autenticação, com pontuação 7.5 e possível contorno de mecanismo de segurança; as CVE-2026-48413 (8.7, que exige autenticação com privilégios baixos e interação do utilizador) e CVE-2026-48414 (7.7, que exige privilégios administrativos), ambas de cross-site scripting armazenado com potencial de execução de código em certas condições; e a CVE-2026-48412, de severidade baixa (2.7), que exige autenticação e privilégios de administrador.

Como mitigar sem quebrar a loja

A parte operacional tem um detalhe que já causou problemas em julho e que convém não ignorar: os patches de segurança do Adobe Commerce não são cumulativos e têm de ser aplicados em sequência. Quem saltou o APSB26-73 tem de o aplicar primeiro e só depois avançar para o de agosto. Além disso, as correções de agosto para as versões 2.4.9, 2.4.8, 2.4.6, 2.4.5 e 2.4.4 foram classificadas como isolated security fixes, o que significa que a Adobe fornece apenas ficheiros de patch isolados, sem publicar pacotes Composer em paralelo.

• Confirmar a versão e o nível de patch em produção e verificar se o APSB26-73 está aplicado antes de instalar o de agosto.
• Aplicar o isolated patch do APSB26-92 correspondente à linha de versão, testando previamente em ambiente de staging com os módulos de terceiros ativos.
• Validar o resultado com a Quality Patches Tool, executando vendor/bin/magento-patches -n status e confirmando o estado «Applied» para o patch correspondente.
• Usar o Commerce Version Tool, executável incluído em cada patch mensal, que reporta quais patches estão instalados, quais faltam e contra que CVE a instalação está protegida.
• Se o patch não puder ser aplicado de imediato, colocar mitigação na camada de edge (WAF, regras ModSecurity ou Nginx) e confirmar com o alojador se já existe proteção ativa.
• Rever atividade de contas privilegiadas, alterações de configuração inesperadas e integridade das extensões instaladas, prática recomendada em análises deste boletim.
• Invalidar sessões ativas após a aplicação do patch e monitorizar pedidos anómalos para os endpoints de edição de conta de cliente.

Nota importante sobre indicadores de comprometimento: não existe, no momento em que escrevemos, uma lista pública de IOCs (endereços IP, ficheiros ou hashes) associada especificamente à CVE-2026-71362. Qualquer «lista de IOCs» que circule sem atribuição a um relatório de investigação verificável deve ser tratada com desconfiança.

Um padrão que já se repetiu demasiadas vezes

O ecossistema Magento tem um historial que explica a urgência. Em 2025, a falha SessionReaper (CVE-2025-54236, CVSS 9.1) permitiu tomada de contas de clientes e execução remota de código não autenticada em certas condições, levando a Adobe a quebrar o calendário habitual com uma correção de emergência. Dez dias depois do patch, menos de uma em cada três lojas Magento estava corrigida; os primeiros ataques surgiram a 22 de outubro, após a publicação de uma análise técnica, e a 23 de outubro apenas 38% das lojas estavam protegidas. A Akamai contabilizou mais de 300 tentativas de exploração contra mais de 130 hosts distintos em 48 horas, a partir de 11 endereços IP. Em março de 2026 repetiu-se o guião com a falha batizada PolyShell: a Sansec observou exploração ativa desde 16 de março, com scanning massivo automatizado três dias depois, e ataques com ficheiros poliglota — imagens GIF ou PNG válidas com código PHP embutido — que instalavam web shells. A lição é sempre a mesma: o fator decisivo não é a gravidade do CVE, é a velocidade da aplicação do patch.

Porque é que isto importa às lojas em Portugal

O Magento e o Adobe Commerce continuam a sustentar lojas de retalhistas médios e grandes em Portugal, muitas delas geridas por agências externas com contratos de manutenção de âmbito variável. Uma tomada de conta de cliente é, em termos legais, um acesso não autorizado a dados pessoais: se se confirmar, aciona as obrigações do RGPD, incluindo a avaliação do risco para os titulares, a notificação à CNPD em 72 horas quando aplicável e a comunicação aos clientes afetados se o risco for elevado. Uma loja não pode fazer essa avaliação sem logs aplicacionais suficientes — o que, na prática, obriga a verificar hoje se a retenção de registos permitiria distinguir um acesso legítimo de uma sessão trocada por um atacante.

Há também o enquadramento nacional de cibersegurança. Com a entrada em vigor do Regime Jurídico da Cibersegurança, aprovado pelo Decreto-Lei n.º 125/2025 que transpõe a NIS2, as entidades abrangidas passam a ter deveres explícitos de gestão de riscos, gestão de vulnerabilidades e notificação de incidentes significativos ao CNCS. Mesmo as lojas que não caem diretamente no âmbito da lei podem ser afetadas por via da cadeia de fornecimento, quando servem clientes empresariais que passam a exigir garantias contratuais de patching e resposta a incidentes. O CERT.PT, no âmbito do CNCS, é o ponto de contacto nacional para reportar e obter apoio na resposta a incidentes. A isto acresce o PCI DSS 4.0 para quem processa pagamentos, com requisitos reforçados de integridade de páginas de checkout. Traduzindo em ação: se a sua loja corre Adobe Commerce ou Magento, a pergunta a fazer esta semana ao fornecedor não é «estamos seguros?», mas «que isolated patch foi aplicado, em que data, e como o confirmamos?».

Perguntas frequentes

A minha loja Magento está vulnerável à CVE-2026-71362?

Se corre Adobe Commerce, Adobe Commerce B2B ou Magento Open Source numa linha suportada e ainda não aplicou o patch de agosto de 2026 (boletim APSB26-92), deve assumir que está exposta. Confirme a versão e o nível de patch e valide a lista exata de versões afetadas no boletim oficial da Adobe.

Já existem ataques confirmados a explorar esta falha?

As fontes divergem. A Adobe afirma não ter conhecimento de exploração das falhas corrigidas no APSB26-92, enquanto a Sansec diz estar a bloquear tentativas de exploração da CVE-2026-71362. Não há, até agora, relatório forense público com lojas comprometidas confirmadas por esta via.

Basta instalar o patch de agosto ou preciso do de julho primeiro?

Os patches de segurança do Adobe Commerce não são cumulativos e devem ser aplicados em sequência. Se ainda não aplicou o APSB26-73, de julho de 2026, tem de o instalar antes do APSB26-92. Teste sempre em ambiente de staging, porque estes patches podem colidir com extensões e código personalizado.

Se houver tomada de contas de clientes, tenho de notificar a CNPD?

Um acesso não autorizado a dados pessoais de clientes é uma violação de dados nos termos do RGPD. Se o incidente for confirmado e representar risco para os titulares, existe obrigação de notificar a autoridade de controlo em 72 horas e, quando o risco for elevado, comunicar aos clientes afetados. As entidades abrangidas pelo Regime Jurídico da Cibersegurança têm ainda deveres de notificação ao CNCS.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Adobe (boletim APSB26-92 e documentação da Experience League), pela Sansec e por análises técnicas independentes da comunidade Magento.