Zero-day em Magento e Adobe Commerce está sendo explorado sem login — e ainda sem patch

Resumo: a Sansec (empresa de segurança especializada em e-commerce) confirmou a exploração ativa de um zero-day em Magento (plataforma de e-commerce open source) e Adobe Commerce (plataforma de e-commerce comercial da Adobe). Batizado de StyleSmuggler, ele permite execução remota de código sem nenhuma autenticação em todas as versões atuais das plataformas, inclusive a 2.4.9 — e, até agora, não existe CVE nem patch oficial.

Introdução

Uma nova vulnerabilidade zero-day — falha desconhecida do público que é explorada antes de existir correção — está sendo usada em ataques reais contra lojas Magento e Adobe Commerce desde o dia 04/09/2026. A Sansec encontrou a campanha ainda na noite de quinta-feira, reproduziu a cadeia completa de ataque em instalações limpas das versões 2.4.7, 2.4.8 e 2.4.9 e publicou a análise na manhã seguinte, dia 05/09, com um aviso direto: lojas estavam sendo comprometidas naquele momento, e por isso a divulgação não podia esperar o fim da investigação técnica.

O StyleSmuggler dá ao atacante execução remota de código (RCE, na sigla em inglês — a capacidade de rodar comandos próprios no servidor da vítima) sem exigir qualquer autenticação, em todas as versões atuais das plataformas, incluindo a mais recente, a 2.4.9. O dado mais perturbador vem da primeira vítima confirmada: ela rodava a 2.4.6-p15, uma instalação com os patches de segurança de julho e agosto de 2026 totalmente aplicados e com o comando de verificação de patches da Adobe limpo. Ou seja, uma loja perfeitamente atualizada caiu exatamente como uma negligenciada.

É preciso ser honesto sobre o estágio da resposta: não há CVE registrado, não há advisory da Adobe e não existe correção oficial disponível — o boletim de segurança mais recente da Adobe para o Commerce ainda é o de 11/08. A divulgação da Sansec foi precoce por necessidade, e a análise técnica completa (a cadeia de gadgets, o dropper e o implante em detalhes) ainda está em desenvolvimento. A próxima janela de correção da Adobe está marcada para 08/09, mas a própria Sansec ressalva que ainda não se sabe se essa atualização cobrirá a falha.

Contexto: por que lojas Magento estão na linha de fogo

O Magento alimenta uma fatia enorme do e-commerce mundial — de grandes marcas a lojas médias e pequenas, incluindo muitas brasileiras — e é um alvo natural para esse tipo de campanha: loja comprometida significa acesso direto a dados de clientes, sessões de compra, histórico de pedidos e, com frequência, a sistemas de pagamento integrados. Uma falha que entrega RCE sem login transforma qualquer loja com a porta de entrada aberta em um prêmio para o atacante.

A gravidade aqui não está apenas na ausência de patch: está no alcance. A exploração não depende de uma versão desatualizada — a Sansec reproduziu o ataque completo em instalações limpas das três versões atuais, e a primeira vítima estava com todas as correções conhecidas aplicadas. Para o lojista, isso significa que "estar em dia" não é mais uma proteção: a defesa, até a Adobe liberar a correção, precisa vir de camadas independentes da existência do fix.

A cadeia do StyleSmuggler em cinco etapas

O StyleSmuggler não explora um único ponto de injeção óbvio: ele abusa de mecanismos legítimos do próprio Magento — o sistema de templates e o sistema de e-mail — para plantar e executar código malicioso. A cadeia tem cinco etapas, começando por uma requisição GraphQL (linguagem de consulta de APIs) e terminando com um implante disfarçado de processo do kernel. O diagrama abaixo resume o fluxo; detalhamos cada etapa em seguida.

A primeira etapa é a injeção. O atacante envia uma requisição GraphQL manipulando as propriedades "styles" de forma a escapar da sanitização — o filtro que o Magento aplica sobre entradas para remover conteúdo perigoso. É esse contorno que deu nome à falha: o código malicioso "passa contrabandeado" dentro de um campo aparentemente inofensivo de estilo.

Em seguida, o PHP malicioso é plantado dentro de um arquivo que o próprio Magento escreve durante a operação normal, como um relatório de falha de pagamento — um arquivo que ninguém suspeitaria. A análise independente do Disrex (grupo de segurança que publicou análise independente do ataque) mostrou que uma diretiva artesanal embutida no texto injetado força uma cadeia de classes do próprio Magento a executar código que, por projeto, só deveria rodar através do compilador de injeção de dependência da linha de comando — e esse caminho acaba incluindo o arquivo de log envenenado.

A terceira etapa é o gatilho. O StyleSmuggler faz o Magento disparar deliberadamente o e-mail padrão "Payment Transaction Failed Reminder" (lembrete de falha de pagamento), e o código malicioso roda no momento em que a plataforma renderiza a mensagem internamente. Ninguém precisa abrir o e-mail — nem sequer recebê-lo: a execução pode acontecer mesmo quando a entrega da mensagem falha.

O dropper e o implante Rust

Com o código executando, entra em cena o dropper — um programa pequeno cuja única função é baixar e executar o malware de verdade. O dropper do StyleSmuggler é um script PHP que testa seis funções diferentes da linguagem, uma a uma, até encontrar uma capaz de iniciar um processo no servidor — uma técnica clássica para contornar configurações que desabilitam funções perigosas do PHP, já que basta que uma delas esteja liberada para o ataque seguir.

A carga final é um binário Rust de aproximadamente 1,9 MB, compilado de forma estática — sem depender de bibliotecas compartilhadas do sistema — para as arquiteturas x86-64 e ARM64, o que o torna executável em praticamente qualquer servidor moderno. Para se esconder, o processo assume o nome "[kworker/u:8:0]", imitando as threads de trabalho do kernel do Linux. O detalhe que denuncia o disfarce é que uma thread de kernel legítima pertence ao usuário root e não consome memória residente; o implante, por outro lado, roda com o usuário da conta do site e com uso real de memória — uma bandeira vermelha para quem sabe olhar.

A persistência é garantida por uma entrada gravada diretamente no spool do crontab — a fila onde o cron armazena os agendamentos de tarefas — que reexecuta o implante a cada cinco minutos sem deixar os logs normais de sistema. E há um agravante descoberto pelo Disrex: o binário rodando em memória às vezes difere do arquivo salvo no disco, o que significa que comparar apenas o arquivo pode não ser suficiente na hora da investigação.

Um caso real mostra como esse implante opera de forma silenciosa. Em uma loja comprometida, o processo não fez nenhuma conexão de saída para a internet: ele abriu 28 conexões simultâneas com a instância local de Redis (banco de dados em memória) para ler as sessões ativas do Magento. O resultado é um backdoor que se alimenta de dados internos da loja sem nunca tocar a rede externa — quase invisível para monitoramento baseado em tráfego.

Como detectar a invasão

A primeira pista vem dos próprios logs do Magento. O guia de detecção da Sansec aponta para um marcador específico dentro do diretório var/report, onde a plataforma guarda relatórios de erros; o Disrex, no entanto, descobriu que as duas lojas que analisou foram envenenadas por outro caminho, o arquivo var/log/system.log. A recomendação prática é verificar os dois locais.

A segunda pista é o processo disfarçado. Um "[kworker]" legítimo é thread de kernel: pertence ao root e não aparece com memória residente. Qualquer processo com esse nome rodando com o usuário do site e consumindo memória é alerta — e a comparação de hash (impressão digital criptográfica do arquivo) entre o binário no disco e o processo em memória fecha o diagnóstico:

# Entrada suspeita no crontab e arquivos ocultos do implante
crontab -l | grep -i gvfsd
ls -la ~/.local/share/.gvfsd/ /tmp/.kw_* /tmp/.gvfsd-* 2>/dev/null
 
# Processo que imita thread de kernel
ps -eo pid,comm,args | grep -i kworker
 
# Marker usado pela Sansec no diretório de relatórios do Magento
grep -rl 'X_TRACE_' var/report/

Para equipes que precisam investigar o artefato sem executá-lo, a mesma trilha que seguimos na análise do XWORM serve: inspeção estática com ferramentas como o pestudio, que permite dissecar o binário e ver suas strings, imports e comportamento sem risco. E, para lojas com mais de um servidor, centralizar os logs em um SIEM — plataforma que agrega e correlaciona eventos de segurança — como o Wazuh ajuda a pegar o processo suspeito e as conexões internas ao Redis antes que o estrago se espalhe.

Como se proteger

Desative o GraphQL se a loja não usa front-end headless. A recomendação da Sansec é temporária, mas direta: lojas que não dependem de um front-end headless (desacoplado, que consome as APIs do Magento para montar a vitrine) — os temas clássicos e o Hyvä não precisam — podem desligar o GraphQL até a Adobe liberar a correção. É a forma mais barata de cortar a superfície de ataque pela raiz.

Bloqueie a função proc_open no PHP. O proc_open é a função usada pelo PHP para executar processos do sistema, e é exatamente o tipo de função que o dropper procura entre as seis testadas. Desabilitá-la na configuração do PHP impede o dropper de lançar o implante — uma proteção no nível do servidor que não depende de entender a cadeia de exploração.

Monte os diretórios temporários com noexec. Montar /tmp e diretórios correlatos sem permissão de execução (noexec, em inglês — a opção de montagem que impede a execução de binários naquele sistema de arquivos) faz com que qualquer binário baixado para ali não rode. É outra camada cega à técnica do ataque, mas efetiva para segurar a carga final.

Monitore logs e processos de forma contínua. Com o ataque ativo e sem patch, a detecção é a defesa que sobra: acompanhe var/report e var/log/system.log, fique de olho em processos "[kworker]" com memória residente e use um SIEM como o Wazuh para correlacionar as conexões internas — especialmente ao Redis.

Trate os "patches" não oficiais como hardening, não como correção. O Disrex Group, o pesquisador ProxiBlue e a Graycore publicaram cada um suas próprias correções de código que protegem classes específicas do Magento e funções de template de e-mail. Os três avisam explicitamente que são medidas de endurecimento: as regras do Disrex, por exemplo, bloqueiam o padrão de tráfego de ataque atual, não a vulnerabilidade subjacente. Vale aplicar como camada extra — nunca como substituto do fix da Adobe.

Prepare a janela de patch. A próxima atualização de segurança da Adobe está marcada para 08/09, sem confirmação de que cobre o StyleSmuggler. Teste a correção em staging assim que ela sair e aplique com prioridade máxima nas lojas de produção.

Conclusão

O StyleSmuggler é o pior tipo de zero-day para quem opera e-commerce: exploração ativa desde o primeiro dia, sem CVE, sem advisory e sem patch — e uma cadeia de ataque que abusa de mecanismos legítimos da plataforma, o que a torna difícil de enxergar para quem só procura falhas óbvias. A primeira vítima confirmada estava totalmente patchada, o que quebra a ilusão de que "atualizar resolve" enquanto a Adobe não publica a correção.

A divulgação precoce da Sansec — que publicou antes de terminar a análise técnica porque lojas estavam caindo naquele momento — foi o que permitiu à comunidade começar a se defender dias antes da janela oficial da Adobe. Até 08/09 (e depois, se a correção não vier), a defesa é uma questão de camadas: desligar o GraphQL onde não é necessário, bloquear o proc_open, usar noexec nos temporários e monitorar os dois logs e os processos suspeitos. Nenhuma dessas medidas é a bala de prata — mas, com um zero-day explorado ativamente, são a diferença entre ser mais uma vítima e sair dessa semana intacto.

Perguntas frequentes

Fontes e leituras adicionais

• Cyber Security News — Hackers Actively Exploiting Magento and Adobe Commerce 0-Day RCE Vulnerability — 06/09/2026
• Sansec — StyleSmuggler: Magento and Adobe Commerce 0-day RCE under active attack — 05/09/2026
• Disrex Group (GitHub) — How StyleSmuggler works — 05/09/2026