Falha no Magento expõe lojas que estavam em dia

Uma brecha ainda sem correção na plataforma Magento passou a ser explorada em 4 de setembro. Quem deu o alerta foi a Sansec, empresa holandesa de segurança para comércio eletrônico: no dia 5 publicou o aviso, apelidou o problema de StyleSmuggler e explicou a pressa — havia lojas sendo comprometidas naquele momento.

O detalhe que muda o tom da história é a resposta do fornecedor. Até 6 de setembro, a Adobe, dona do Magento e do Adobe Commerce, não havia divulgado boletim, número de CVE, atualização nem instrução provisória; o índice de avisos de segurança da plataforma parava no dia 11 de agosto. A próxima entrega de segurança estava marcada para 8 de setembro, e nem isso era certeza de solução. Se você vende pela internet, isso é urgente; se não vende, a lição vale para qualquer sistema seu exposto na internet.

O que essa falha no Magento permite

Em linguagem de dono de empresa: o atacante faz o servidor da loja rodar comandos dele sem precisar de senha nem de conta. Não é painel invadido, não é senha fraca, não é funcionário que clicou em link. É a própria plataforma sendo convencida a executar o que o estranho mandou.

Segundo o desenho publicado pela Sansec, o golpe tem duas etapas. Primeiro, o código malicioso é depositado em um arquivo que o próprio Magento escreve — um relatório de erro, por exemplo. Depois, o atacante provoca o disparo de um e-mail padrão da plataforma, o aviso de transação de pagamento não concluída. O trecho hostil roda quando a mensagem é montada: ninguém precisa abrir nada, e a jogada funciona mesmo que o envio falhe. Sobra execução de código no servidor e uma porta dos fundos que se mantém sozinha.

A Sansec diz que todas as versões atuais estão expostas, inclusive a 2.4.9, e afirma ter reproduzido a cadeia inteira, sem login, em instalações limpas do Magento Open Source 2.4.7, 2.4.8 e 2.4.9. Não houve reprodução divulgada no Adobe Commerce nem na versão em nuvem, a fabricante não confirmou as edições atingidas e o total de lojas comprometidas segue desconhecido. Para quem não usa o produto de proteção da Sansec, a orientação provisória foi desligar o GraphQL até sair a correção. Antes de mexer, confirme com quem cuida da sua loja: vitrines headless e aplicativos web progressivos dependem desse recurso; a maioria das clássicas, não.

Estar em dia não é a mesma coisa que estar defendido

Aqui está a parte desconfortável. A primeira vítima identificada rodava a 2.4.6-p15 com os pacotes de segurança de julho e agosto de 2026 aplicados, o nível mais recente que a Adobe oferece naquela linha. Estava em dia e caiu.

A Disrex Group, que hospeda e desenvolve para Magento, atendeu duas lojas comprometidas e uma terceira atacada sem sucesso. A que ela chama de loja A rodava 2.4.8 e era cliente do produto de bloqueio da Sansec, com o módulo instalado, ativo e licenciado; foi atingida às 23h10 (UTC) de 4 de setembro, horas antes de a primeira regra contra essa falha entrar no ar. A loja B não usava o produto e estava na 2.4.7-p2, nível de agosto de 2024 pelo histórico da Adobe, oito degraus atrás do 2.4.7-p10 atual; foi atingida às 00h55 (UTC) do dia 5. As duas caíram na janela de cerca de oito horas entre a primeira exploração observada e a existência de qualquer defesa.

Isso não quer dizer que atualizar perdeu o sentido — a loja B estava muito atrasada, e essa é uma dívida que ninguém deveria carregar. Quer dizer que só atualizar não cobre o intervalo entre o ataque começar e a defesa existir. Quem cobre esse intervalo é a arquitetura, com contas isoladas e privilégio mínimo, o controle de borda e a segmentação da rede e a capacidade de perceber cedo. Vale registrar que o próprio repositório da Disrex avisa ter sido escrito com apoio de inteligência artificial, durante o incidente e sem revisão.

O sinal que o próprio dono consegue notar

Um dos dois comprometimentos apareceu por causa de um e-mail esquisito. Rick Bouma, cofundador da Disrex, contou que a loja enviou ao próprio dono um aviso de transação recusada com as variáveis do modelo sem preenchimento: marcações cruas no corpo, endereço de cliente em domínio .invalid e valor total zero. Parece pedido defeituoso; é resíduo da tentativa de ataque passando pelo filtro de modelos. O lojista encaminhou a mensagem, e o implante foi achado em uma hora.

Rajadas inesperadas desse aviso de pagamento são motivo para investigar, com a ressalva de que recusas legítimas de cartão produzem a mesma notificação. A lição custa zero: e-mail automático saindo torto do seu sistema é assunto de TI, não de lixeira.

Há um segundo aprendizado. Na loja A, a varredura recomendada pela Sansec rodou cerca de onze horas depois de o implante entrar em ação e devolveu resultado limpo. Não foi defeito da ferramenta, e sim escopo: ela mirava a pasta pública do site, e o programa hostil estava um diretório acima, na pasta da conta. Ferramenta apontada para o lugar errado devolve calmaria falsa; por isso monitoramento com gente olhando os alertas vale mais do que relatório verde.

O que fazer nesta semana

Não existe correção oficial para instalar. O que existe são camadas, e todas cabem numa conversa curta com quem cuida do seu ambiente.

• Descubra a sua exposição. Qual versão a loja roda, quem hospeda, se a vitrine realmente precisa do GraphQL e se dá para desligá-lo por alguns dias.
• Feche as saídas do servidor. Em uma das lojas, o código intruso tentou seis funções do PHP até conseguir iniciar um processo; as quatro primeiras estavam bloqueadas, a proc_open não. Bloquear a proc_open e montar as pastas temporárias sem permissão de execução independem de conhecer o detalhe da falha.
• Trate mitigação não oficial como remendo. Circulam ajustes de Disrex, ProxiBlue e Graycore, e a própria Graycore diz que aquilo é endurecimento, não conserto. Regras de servidor barram o ataque pela URL, mas os mesmos parâmetros no corpo da requisição chegaram ao PHP.
• Confirme o isolamento. Cada loja rodava em conta separada, com usuário sem poderes administrativos e sem passagem para outro cliente; foi isso que travou a propagação.
• Tenha o plano do dia seguinte. Evidência preservada antes da limpeza, sessões invalidadas, senhas trocadas e backup com restauração testada, para não descobrir na pior hora que a cópia não volta.

Outro dado importa para quem confia só no registro de tráfego: em uma das lojas o implante não fez nenhuma conexão externa. Ele manteve 28 conexões com o Redis da própria loja, na porta 6379, lendo ali as sessões do Magento, e duas capturas de rede acima de 200 MB não trouxeram um único pacote ao endereço de comando divulgado.

Silêncio na borda não é prova de casa limpa. E a lição não é só do comércio eletrônico: troque loja Magento por sistema de agendamento da clínica, ERP da indústria ou portal do escritório e o desenho se repete. Nas duas lojas, a contenção veio no mesmo dia, cerca de onze e quatorze horas após o primeiro contato, sem indício de vazamento de dados e sem administrador clandestino. Responda hoje o que está publicado com o seu nome, quem olha fora do horário comercial e em quanto tempo a operação volta.

Fonte: The Hacker News — Unpatched Magento and Adobe Commerce Zero-Day Exploited to Backdoor Online Stores, 6 de setembro de 2026.

A Ragnatela cuida da infraestrutura que sustenta essas respostas: projeto de rede, firewall gerenciado, nuvem privada em data center Tier III, backup com restauração testada e NOC acompanhando o ambiente 24 horas. Se você não sabe o que da sua empresa está exposto na internet, fale com a gente.