Uma vulnerabilidade de dia zero (zero-day) não corrigida no Magento Open Source e no Adobe Commerce está sendo ativamente explorada para comprometer servidores e implantar backdoors em lojas virtuais. A falha permite a execução remota de código arbitrário sem a necessidade de autenticação prévia, o que viabiliza a tomada total do ambiente por invasores remotos.
Incidentes em massa começaram a ser registrados nos primeiros dias de setembro, com criminosos injetando scripts maliciosos diretamente na infraestrutura das plataformas. Como o ecossistema Magento é amplamente adotado no comércio eletrônico brasileiro para operações de médio e grande porte, a exposição coloca em risco dados financeiros, credenciais de consumidores e operações de pagamento de diversas marcas nacionais.
O que está em jogo
O ataque explora a ausência de validação rígida em rotinas de processamento de layout e folhas de estilo do Magento, permitindo que atacantes burlem filtros de segurança para carregar e executar instruções maliciosas no servidor web. A técnica dispensa credenciais administrativas e qualquer privilégio no sistema, tornando a exploração inicial direta e silenciosa.
Uma vez que o código malicioso ganha acesso ao servidor, os atacantes estabelecem persistência implantando web shells e backdoors em diretórios de mídia ou arquivos do núcleo da aplicação. A partir desse controle, os criminosos frequentemente alteram páginas de checkout para capturar números de cartões de crédito e informações de identificação pessoal, operação comumente associada a ataques de Magecart e skimming digital.
Versões e condição
O problema atinge implantações ativas do Adobe Commerce e do Magento Open Source, tanto em servidores locais dedicados quanto em ambientes de nuvem. Instalações expostas diretamente à internet pública sem barreiras intermediárias de inspeção HTTP estão entre as mais visadas.
Como a exploração ocorre sem autenticação, a condição necessária para o comprometimento é apenas a conectividade HTTP/HTTPS aberta para as interfaces web da loja. Plataformas que utilizam extensões legadas de terceiros ou personalizações profundas de layout também podem apresentar caminhos adicionais de entrada se compartilharem o mesmo parser vulnerável.
Como conferir
Equipes de SOC e AppSec devem auditar imediatamente os arquivos de log de acesso do servidor web (Nginx ou Apache), buscando requisições anômalas direcionadas a controladores de processamento de estilos, blocos de template ou parâmetros suspeitos no corpo de solicitações POST.
Também é indispensável executar varreduras de integridade de arquivos em todo o diretório de instalação do Magento, comparando o código em execução com o repositório original de produção. Mudanças não registradas em arquivos PHP, arquivos recém-criados em pastas de cache, diretórios de mídia temporários ou alterações em tabelas de configuração do banco de dados (como core_config_data) indicam forte probabilidade de comprometimento ativo.
O que fazer agora
- Implementar regras emergenciais no Web Application Firewall (WAF) para bloquear padrões de requisição suspeitos voltados a manipuladores de layout e elementos CSS dinâmicos.
- Restringir o acesso às rotas administrativas da loja (como o caminho padrão do painel de administração) via lista de permissão de IP e aplicar autenticação multifator rigorosa.
- Revisar permissões de escrita no sistema de arquivos, garantindo que o usuário do servidor web não possua autorização para criar ou alterar scripts executáveis em diretórios estáticos ou de upload.
- Verificar a presença de tarefas agendadas (cron jobs) desconhecidas criadas no servidor ou no agendador nativo do Magento que possam manter a persistência de backdoors.
- Acompanhar a publicação de correções oficiais da Adobe e aplicar os patches de segurança assim que forem disponibilizados pelo fabricante.