Falha crítica no Adobe Commerce permite comprometer servidores de lojas virtuais
Uma vulnerabilidade de dia zero no Adobe Commerce e no Magento Open Source está sendo explorada ativamente para executar código remotamente e instalar backdoors em servidores de comércio eletrônico. Batizada de StyleSmuggler, a falha não exige autenticação e pode colocar em risco lojas virtuais mesmo quando os administradores aplicaram as atualizações regulares mais recentes.
Os primeiros ataques identificados ocorreram em 4 de setembro. A exploração aproveita o sistema de templates da plataforma para inserir código PHP malicioso em arquivos gerados pelo Magento. Em seguida, os invasores induzem a própria aplicação a interpretar esse conteúdo como parte legítima do processamento.
A cadeia de ataque pode ser acionada durante a criação do e-mail padrão enviado quando uma transação apresenta falha. O usuário não precisa abrir a mensagem para que a exploração funcione. Em determinados cenários, o ataque também é executado mesmo quando o envio do e-mail não chega a ser concluído.
Versões afetadas e risco de exploração
Pesquisadores conseguiram reproduzir o problema em instalações limpas do Magento Open Source nas versões 2.4.7, 2.4.8 e 2.4.9. Além disso, uma das primeiras vítimas identificadas utilizava o Magento 2.4.6-p15 com as atualizações liberadas em julho e agosto.
Esse detalhe indica que a aplicação de patches convencionais não era suficiente para bloquear a vulnerabilidade antes da disponibilização da correção específica. Como o ataque não depende de credenciais, lojas expostas à internet podem ser atingidas sem que o criminoso precise acessar previamente um painel administrativo.
Depois de obter acesso ao servidor, o invasor pode instalar um implante desenvolvido em Rust fora do diretório principal da loja. O malware tenta se camuflar usando o nome de processo [kworker/u:8:0], semelhante ao de uma tarefa legítima do kernel do Linux.
Para garantir persistência, uma tarefa do cron é configurada para reiniciar o código malicioso a cada cinco minutos. Dessa forma, o implante pode voltar a funcionar mesmo após uma interrupção temporária do processo ou uma reinicialização parcial dos serviços da aplicação.
Possíveis consequências para as lojas
Um servidor comprometido pode expor sessões de clientes, credenciais administrativas, configurações internas e dados armazenados pela aplicação. O acesso também permite instalar cargas adicionais, modificar arquivos da loja, criar novos usuários privilegiados e alterar o comportamento do checkout.
Até o momento, não foi confirmada a ocorrência de roubo de dados ou a instalação de skimmers para capturar informações de pagamento nos incidentes analisados. Isso, porém, não elimina o risco: a ausência de evidências pode significar apenas que a investigação ainda não foi concluída ou que os invasores atuaram de forma discreta.
Em ambientes de comércio eletrônico, o comprometimento do servidor pode afetar não apenas a confidencialidade dos dados, mas também a disponibilidade da operação. Alterações aparentemente pequenas em módulos, temas ou arquivos de configuração podem redirecionar compradores, adulterar valores, interromper pedidos ou capturar informações durante o pagamento.
Adobe disponibiliza correção emergencial
A Adobe publicou a correção em 8 de setembro. A vulnerabilidade recebeu o identificador CVE-2026-75650 e a pontuação máxima de severidade, CVSS 10.0.
O hotfix foi distribuído no pacote VULN-39341-composer-patches.zip, acompanhado de orientações para a rotação das chaves de criptografia. A medida é importante porque, após uma invasão, não basta corrigir o código vulnerável: credenciais, tokens e chaves que possam ter sido acessados também devem ser substituídos.
O pacote contempla as seguintes linhas de produto:
– Adobe Commerce das versões 2.4.4 a 2.4.9;
– Adobe Commerce B2B das versões 1.3.3 a 1.5.3;
– Magento Open Source das versões 2.4.6 a 2.4.9.
Administradores devem aplicar o hotfix imediatamente, seguindo as instruções de compatibilidade e validação do ambiente. A atualização precisa ser testada em uma cópia controlada da loja, mas não deve ser adiada em sistemas que permanecem acessíveis pela internet.
Como verificar sinais de comprometimento
Antes e depois da instalação do patch, a equipe técnica deve revisar arquivos recentemente modificados, tarefas agendadas e processos ativos no servidor. Nomes de processos que imitam componentes do sistema, especialmente aqueles executados fora dos diretórios esperados, merecem atenção especial.
Também é recomendável examinar:
– entradas recentes no cron e em outros mecanismos de inicialização;
– arquivos PHP criados ou alterados sem relação com implantações autorizadas;
– contas administrativas adicionadas recentemente;
– alterações em módulos, temas e arquivos de configuração;
– conexões de saída desconhecidas;
– registros de acesso com padrões incomuns;
– atividades realizadas por usuários ou tokens fora do horário habitual.
A análise deve incluir cópias de segurança, registros do servidor web, banco de dados e ferramentas de monitoramento. Se houver indícios de invasão, o ideal é preservar evidências antes de remover arquivos suspeitos, pois a exclusão precipitada pode dificultar a identificação da origem e da extensão do ataque.
Medidas recomendadas após a atualização
A aplicação do hotfix deve ser acompanhada por uma troca imediata das credenciais potencialmente expostas. Isso inclui senhas administrativas, chaves de API, credenciais de banco de dados, tokens de integração e chaves criptográficas utilizadas pela plataforma.
As sessões ativas também devem ser invalidadas para impedir que tokens capturados continuem funcionando. Em seguida, a equipe deve revisar permissões de arquivos e diretórios, limitar acessos administrativos por rede e exigir autenticação multifator sempre que o ambiente permitir.
Outra medida importante é separar o servidor da loja de outros sistemas corporativos. A segmentação reduz o impacto caso o invasor tente avançar pela rede interna ou alcançar serviços de pagamento, armazenamento e gestão de pedidos.
As lojas também devem manter monitoramento contínuo para identificar mudanças inesperadas no código. Ferramentas de integridade de arquivos, alertas de execução de processos incomuns e inspeção de tarefas agendadas podem ajudar a detectar persistência mesmo depois da correção.
Por fim, empresas que processam pagamentos precisam revisar os registros de transações e considerar uma investigação independente quando houver sinais de acesso indevido. A vulnerabilidade deve ser tratada como um incidente potencialmente grave até que a organização consiga confirmar que não houve comprometimento.