Falha zero-day crítica no Magento é explorada para instalar backdoors e web shells
A Adobe publicou uma atualização emergencial para corrigir uma vulnerabilidade crítica que afeta o Adobe Commerce e o Magento Open Source. Identificada como CVE-2026-75650, a falha já está sendo explorada contra lojas virtuais e recebeu a pontuação máxima de 10,0 no CVSS, indicando risco extremo para os ambientes vulneráveis.
A vulnerabilidade foi batizada de StyleSmuggler pela empresa de segurança Sansec, responsável por identificar a exploração como um ataque zero-day a partir de 4 de setembro. A Adobe confirmou que comerciantes que utilizam o Adobe Commerce já foram alvo de campanhas maliciosas.
Falha permite execução remota de código
O problema está relacionado ao mecanismo de templates do Magento. A exploração utiliza uma injeção de código PHP associada à geração de mensagens de e-mail enviadas quando uma transação de pagamento falha.
Por meio dessa cadeia, os invasores abusam de funções legítimas de processamento de templates e de recursos de injeção de dependências do Magento. O resultado é a execução remota de código no servidor, sem que seja necessário realizar autenticação prévia.
Na prática, um atacante pode explorar uma loja vulnerável para executar comandos, acessar dados internos, alterar arquivos, criar usuários, modificar páginas de pagamento ou instalar ferramentas que garantam acesso persistente ao ambiente.
Versões afetadas
A CVE-2026-75650 atinge várias edições e ramificações do Adobe Commerce, Adobe Commerce B2B e Magento Open Source. No caso do Magento Open Source, estão entre as versões vulneráveis:
– 2.4.6-2026-aug e anteriores dentro da mesma linha;
– 2.4.7-2026-aug e versões anteriores correspondentes;
– 2.4.8-2026-aug e edições anteriores da série;
– 2.4.9-2026-aug e versões anteriores relacionadas.
As linhas equivalentes do Adobe Commerce e do Adobe Commerce B2B também podem estar expostas. Como a nomenclatura das versões varia conforme a distribuição e o ciclo de atualização, os administradores devem confirmar diretamente qual pacote está instalado antes de aplicar a correção.
Adobe disponibiliza hotfix emergencial
Para corrigir a vulnerabilidade, a Adobe liberou o hotfix VULN-39341. A recomendação é instalar o pacote correspondente à versão em uso e validar, posteriormente, se a aplicação continua funcionando normalmente.
A empresa também orienta a rotação das chaves de criptografia depois da atualização. Essa etapa é importante porque, caso um invasor tenha acessado o ambiente antes da instalação do hotfix, credenciais, tokens ou dados protegidos podem ter sido expostos.
A simples aplicação do patch não deve ser tratada como garantia de que o servidor está limpo. Como a exploração começou antes da correção oficial, é necessário investigar se houve acesso indevido ou alteração de arquivos.
Ataques instalam backdoors e web shells
As campanhas observadas demonstram que os criminosos não estão apenas testando a falha. Em um dos ataques analisados, os invasores instalaram um backdoor para Linux desenvolvido em Rust. O malware estabelece comunicação com um servidor externo e permanece aguardando comandos dos operadores.
Em outra campanha, a exploração foi utilizada para implantar um dropper escrito em PHP. Esse componente grava uma web shell no servidor, permitindo executar código PHP remotamente e manter controle sobre o ambiente comprometido.
Uma web shell pode ser usada para navegar pelos diretórios, alterar arquivos, capturar informações, criar novos mecanismos de persistência e executar comandos sem depender novamente da falha original. Por isso, sua presença costuma indicar comprometimento grave.
Exploração ocorre rapidamente após a descoberta
A velocidade dos ataques é um dos aspectos mais preocupantes do caso. Segundo a Disrex, um servidor Magento administrado pela empresa foi comprometido apenas 50 minutos depois do primeiro caso confirmado de exploração do StyleSmuggler.
O incidente inicial foi registrado em 4 de setembro, às 22h20 UTC. Esse intervalo reduzido mostra que a disponibilidade de informações sobre uma vulnerabilidade crítica pode ser rapidamente aproveitada por grupos automatizados e operadores especializados.
Lojas virtuais expostas à internet devem ser consideradas alvos prioritários, especialmente quando utilizam módulos adicionais, integrações de pagamento ou componentes personalizados que ampliam a superfície de ataque.
O que os administradores devem fazer
A primeira providência é identificar todas as instalações de Adobe Commerce e Magento Open Source presentes na organização, incluindo servidores de teste, ambientes de homologação e cópias esquecidas em subdomínios. Em seguida, deve-se confirmar quais versões estão instaladas e aplicar o VULN-39341 de acordo com a linha correspondente.
Também é recomendável:
– restringir temporariamente acessos administrativos desnecessários;
– revisar registros de aplicação, servidor web e sistema operacional;
– procurar arquivos PHP recentes ou modificados fora do processo normal de implantação;
– verificar tarefas agendadas, usuários do sistema e chaves SSH;
– analisar conexões de saída para endereços desconhecidos;
– alterar senhas de administradores, bancos de dados e serviços integrados;
– rotacionar as chaves criptográficas após a aplicação da correção;
– preservar evidências antes de remover arquivos suspeitos.
A análise deve abranger não apenas o diretório principal da loja, mas também pastas de mídia, áreas temporárias, extensões de terceiros e arquivos que possam ser carregados pelo servidor web.
Como identificar possíveis sinais de comprometimento
Entre os indícios mais comuns estão alterações inesperadas em arquivos do Magento, códigos PHP ofuscados, chamadas para funções de execução, novos scripts em diretórios públicos e conexões frequentes com servidores externos desconhecidos.
Também merecem atenção contas administrativas criadas recentemente, mudanças não autorizadas em métodos de pagamento, redirecionamentos para páginas externas, aumento repentino de processos no servidor e modificações em tarefas automatizadas.
Caso existam sinais de invasão, o ideal é retirar o sistema comprometido da exposição pública, preservar uma cópia para análise forense e restaurar a operação a partir de uma versão confiável. A remoção isolada de uma web shell pode não ser suficiente, pois o invasor pode ter criado outros mecanismos de persistência.
Risco para dados de clientes e pagamentos
Uma loja comprometida pode expor informações cadastrais, endereços, pedidos, registros de acesso e dados relacionados a integrações financeiras. Mesmo quando os dados completos do cartão não são armazenados no Magento, o atacante pode alterar o fluxo de checkout, inserir scripts maliciosos ou redirecionar pagamentos.
Por esse motivo, empresas afetadas devem avaliar o impacto sobre clientes, parceiros e provedores de pagamento. Dependendo da legislação aplicável e da natureza dos dados acessados, também pode ser necessário conduzir procedimentos internos de resposta a incidentes e comunicação.
A combinação de exploração ativa, ausência de autenticação, execução remota de código e pontuação CVSS 10,0 torna a atualização uma tarefa urgente. Organizações que utilizam versões afetadas devem instalar o hotfix, rotacionar as chaves e realizar uma investigação completa para determinar se houve comprometimento anterior à correção.