Falha crítica no Adobe Commerce permite comprometer servidores de lojas virtuais
Uma vulnerabilidade de gravidade máxima no Adobe Commerce e no Magento Open Source está sendo explorada para executar código remotamente e instalar backdoors em servidores de comércio eletrônico. Identificada como StyleSmuggler, a falha não exige autenticação e pode permitir que invasores assumam o controle da infraestrutura responsável por uma loja virtual.
Os primeiros ataques foram detectados em 4 de setembro. A exploração ocorre por meio da injeção de código PHP malicioso em arquivos gerados pelo Magento. Em seguida, os criminosos fazem com que a própria plataforma interprete esse conteúdo usando o mecanismo interno de templates.
A cadeia de ataque pode ser iniciada durante a criação da mensagem automática enviada quando uma transação apresenta erro. O cliente não precisa abrir o e-mail, clicar em qualquer conteúdo ou sequer receber a comunicação. Em determinados cenários, a exploração é concluída mesmo quando o envio da mensagem falha antes de ser finalizado.
Pesquisadores conseguiram reproduzir o problema em instalações limpas das versões 2.4.7, 2.4.8 e 2.4.9. Uma das primeiras lojas afetadas executava o Magento 2.4.6-p15 e tinha instalado os pacotes de segurança distribuídos em julho e agosto. O caso demonstra que a aplicação das atualizações anteriores não é suficiente para bloquear a nova ameaça.
Depois de obter acesso ao servidor, os invasores podem instalar um implante desenvolvido em Rust fora do diretório principal da loja. Para dificultar a identificação, o malware pode assumir um nome semelhante ao de um processo legítimo do Linux, como [kworker/u:8:0]. Além disso, uma tarefa agendada no cron é configurada para reiniciar a carga maliciosa a cada cinco minutos.
O comprometimento pode expor sessões de usuários, credenciais administrativas, informações da aplicação e outros dados armazenados no ambiente. O acesso também permite instalar componentes adicionais, alterar arquivos da loja e preparar ataques contra clientes. Até o momento, os incidentes analisados não confirmaram o roubo de dados nem a implantação de skimmers para capturar informações de pagamento.
A Adobe publicou a correção em 8 de setembro. A vulnerabilidade recebeu o identificador CVE-2026-75650 e classificação CVSS 10.0, considerada crítica. 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 correção contempla as versões 2.4.4 a 2.4.9 do Adobe Commerce, 1.3.3 a 1.5.3 do Adobe Commerce B2B e 2.4.6 a 2.4.9 do Magento Open Source. Administradores devem aplicar o pacote emergencial o quanto antes, sem aguardar a próxima janela regular de manutenção.
Antes e depois da instalação do hotfix, é importante preservar registros do servidor, do sistema operacional, do PHP, do banco de dados e do painel administrativo. A análise deve procurar arquivos PHP recentes, alterações inesperadas em temas e templates, tarefas cron desconhecidas e processos executados a partir de diretórios temporários ou fora da estrutura habitual do Magento.
Também é recomendável revisar contas administrativas, tokens de integração, chaves de API e credenciais usadas por serviços externos. Caso exista qualquer indício de invasão, as senhas devem ser substituídas e as chaves criptográficas rotacionadas conforme as instruções de segurança da plataforma. A simples aplicação do patch não elimina necessariamente um backdoor que já tenha sido instalado.
As equipes responsáveis devem verificar alterações em arquivos de configuração, módulos, extensões de terceiros e rotinas de envio de e-mail. Comparar os arquivos atuais com uma cópia conhecida como íntegra pode ajudar a encontrar modificações discretas. O monitoramento deve incluir conexões de saída incomuns, novos processos persistentes e tentativas de acesso a dados de clientes.
Como medida adicional, o acesso ao painel administrativo deve ser protegido com autenticação multifator, restrição por rede ou VPN e privilégios mínimos. Serviços que não precisam estar expostos à internet devem ser isolados, enquanto permissões de escrita em diretórios da aplicação devem ser reduzidas ao necessário para o funcionamento da loja.
Se houver suspeita de comprometimento, a loja deve ser colocada em modo de manutenção de forma controlada, preservando evidências para investigação. A equipe pode precisar reinstalar componentes a partir de pacotes confiáveis, revisar o banco de dados, invalidar sessões ativas e acompanhar transações recentes em busca de alterações indevidas.
O incidente também reforça a necessidade de manter inventário atualizado de versões, extensões e integrações. Ambientes de desenvolvimento, homologação e produção precisam ser avaliados separadamente, pois uma instalação esquecida ou uma cópia antiga acessível pela internet pode oferecer uma nova porta de entrada.
A falha representa risco especialmente elevado para lojas que processam pagamentos, armazenam dados pessoais ou mantêm integrações com sistemas de logística, atendimento e gestão. Mesmo sem evidência de skimmers nos casos conhecidos, o acesso ao servidor pode permitir que os criminosos alterem o fluxo de checkout posteriormente. Por isso, a verificação deve incluir páginas de pagamento, scripts carregados no navegador e registros de alterações no código-fonte.