Sun, 06 Sep 2026
← VoltarOs invasores estão explorando uma nova vulnerabilidade não corrigida no Magento Open Source e no Adobe Commerce que lhes permite executar código malicioso no servidor de uma loja online sem fazer login, disse a empresa holandesa de segurança de comércio eletrônico Sansec em um comunicado publicado em 5 de setembro.
Os invasores estão explorando uma nova vulnerabilidade não corrigida no Magento Open Source e no Adobe Commerce que lhes permite executar código malicioso no servidor de uma loja online sem fazer login, disse a empresa holandesa de segurança de comércio eletrônico Sansec em um comunicado publicado em 5 de setembro. Sansec, que descobriu a falha e a nomeou StyleSmuggler, disse que os ataques começaram em 4 de setembro. Até 6 de setembro, a Adobe não publicou um comunicado, um identificador CVE, um patch ou uma solução alternativa, e seu índice de boletins de segurança do Adobe Commerce não lista nada após a atualização de 11 de agosto. Um ataque bem-sucedido dá ao invasor a execução do código no servidor da loja e instala um backdoor persistente.
Sansec disse que todas as versões atuais foram afetadas, incluindo 2.4.9, e que reproduziu toda a cadeia não autenticada em instalações limpas de código aberto do Magento 2.4.7, 2.4.8 e 2.4.9. Sua primeira vítima executou 2.4.6-p15 com as atualizações de segurança de julho e agosto de 2026 da Adobe aplicadas, que é o nível de patch mais recente que a Adobe oferece para essa linha de lançamento e aquele que o boletim de agosto da Adobe rotula como 2.4.6-2026-ago. A Sansec não publicou uma reprodução no Adobe Commerce ou no Adobe Commerce on Cloud, e a Adobe não confirmou quais versões foram afetadas. A Sansec não informou quantas lojas foram comprometidas.
O conselho provisório dos pesquisadores para lojas que não executam seu produto Shield é desativar temporariamente o GraphQL até que a Adobe libere uma correção. O Disrex Group, uma empresa de hospedagem e desenvolvimento Magento que hospeda e responde a duas das lojas comprometidas, observa que as vitrines de aplicativos da web progressivas e sem cabeça exigem GraphQL, enquanto a maioria das vitrines clássicas e Hyvä não. O próximo lançamento de segurança agendado da Adobe será em 8 de setembro, disse Sansec, e ainda não se sabe se esse lançamento cobrirá esse bug. As descobertas da Disrex são evidências independentes de exploração externa à Sansec.
Num repositório de resposta a incidentes publicado em 5 de setembro, a empresa disse que administrou duas lojas comprometidas e uma terceira que foi atacada, mas não violada, e que as regras do seu servidor web se baseiam no tráfego de ataque capturado numa das lojas comprometidas. Em respostas às perguntas do The Hacker News, a Disrex disse que ambas as lojas executam Magento Open Source em vez de Adobe Commerce, e que ela mesma as hospeda por meio de sua marca de hospedagem RexHosting. A loja Disrex rotula Store A rodava Magento Open Source 2.4.8 e era cliente Sansec Shield, com o módulo instalado, habilitado e licenciado. Ele foi atingido às 23h10 UTC do dia 4 de setembro, horas antes das primeiras regras de bloqueio da Sansec para essa falha entrarem em vigor, e Disrex disse que o Shield estava ativo e bloqueando outro tráfego malicioso contra a loja no momento.
A Loja B, que não era cliente Shield, executava Magento 2.4.7-p2, um nível de patch de segurança cujo histórico de versão da Adobe data de agosto de 2024, oito níveis atrás do atual 2.4.7-p10. Ele foi atingido pela primeira vez às 00h55 UTC de 5 de setembro, disse Disrex, e é a loja de onde foram retiradas as regras do servidor web da empresa e a leitura do código vulnerável. Ambas as lojas foram violadas dentro do intervalo de aproximadamente oito horas entre a primeira exploração observada pela Sansec e o momento em que existia qualquer defesa, disse Disrex. “O status do patch era irrelevante aqui, que é a parte que os comerciantes mais precisam ouvir”, disse a empresa ao The Hacker News.
O repositório carrega seu próprio aviso. “Este repositório foi escrito com assistência de IA, durante um incidente ao vivo, em poucas horas”, diz seu README, acrescentando que não foi revisado, que suas regras Apache nunca foram executadas em um servidor Apache ativo e que a maioria de seus comandos de limpeza foram escritos em vez de executados. Os indicadores da Sansec descrevem o implante como um processo em segundo plano disfarçado em [kworker/u:8:0], um nome que pertence a um thread do kernel Linux, com um binário instalado em ~/.local/share/.gvfsd/gvfsd-user no diretório inicial do usuário do site em vez da raiz da web, e uma entrada cron que o reinicia a cada cinco minutos. Disrex descreveu o binário como um programa Rust despojado e estaticamente vinculado de aproximadamente 1,9 MB construído para x86-64 e arm64, e disse que a entrada do cron é gravada diretamente no arquivo de spool em /var/spool/cron/crontabs/, portanto, o log do sistema não mostra nenhuma substituição do crontab.
Uma loja carregou a mesma linha 1.728 vezes, e o implante a adicionou novamente um segundo após a remoção. Em uma das duas lojas, o implante não fez nenhuma conexão de saída. Ele mantinha 28 conexões com a própria instância Redis da loja na porta 6379 e lia o armazenamento de sessão do Magento a partir dela, disse Disrex, e nenhuma de suas duas capturas de pacotes, cada uma com mais de 200 MB e tiradas enquanto o implante estava ativo, continha um único pacote para o host de download ou o endereço de comando e controle listado pela Sansec. Disrex disse ao The Hacker News que cada loja funcionava em sua própria conta isolada com um único proprietário de site, sem direitos sudo e sem caminho para qualquer outro cliente, que o implante funcionava como usuário do site sem privilégios e não conseguia alcançar nada além daquela loja, e que não confirmou nenhum movimento lateral e nenhum outro site afetado em sua plataforma.
Ambas as lojas foram contidas no mesmo dia, cerca de onze e quatorze horas após o primeiro contato, disse a empresa, e não encontrou nenhuma evidência de exfiltração de dados, nenhuma conta de administrador desonesta, nenhum skimmer de pagamento injetado e nenhum backdoor de banco de dados. Todas as sessões foram invalidadas e a rotação de credenciais está em andamento por precaução. Como administra várias lojas Magento em sua própria plataforma e encontrou o primeiro compromisso rapidamente, disse Disrex, varreu todo o seu patrimônio em uma hora e encontrou a segunda loja na mesma tarde. A empresa também publicou um relatório do incidente.
Sansec disse que para clientes do Shield atacados antes de suas regras entrarem em vigor, não há indicação de que o backdoor foi realmente usado e recomendou a rotação de credenciais Magento sempre que o processo foi identificado. O ataque funciona em duas etapas, conforme esquema da Sansec. Primeiro ele planta o código PHP em um arquivo que o próprio Magento escreve, por exemplo, ao gerar um relatório de falha. Em seguida, faz com que o Magento execute esse arquivo, acionando o e-mail padrão "Lembrete de falha na transação de pagamento" da plataforma.
O código é executado enquanto o Magento renderiza a mensagem, para que ninguém precise abri-lo e o ataque pode ter sucesso mesmo se a entrega do email falhar. A Sansec ainda não publicou a cadeia completa de exploração e disse que uma análise da cadeia, do conta-gotas e do implante seguirá em uma atualização. A leitura da cadeia por Disrex, publicada em um artigo sobre o mecanismo junto com suas regras, é que uma diretiva dentro do texto injetado conduz uma sequência das próprias classes do Magento em um código que existe apenas para servir ao compilador de injeção de dependência de linha de comando. Esse código termina incluindo um caminho de arquivo escolhido pelo invasor: o log envenenado um momento antes.
O conta-gotas PHP executado tenta seis funções PHP por vez para iniciar um processo, depois baixa e inicia o implante. Disrex nomeia três arquivos em setup/src/Magento/Setup/Module/Di/Code/ como o ponto onde a cadeia termina, e disse ao The Hacker News que identificou esse coletor por conta própria lendo a fonte do Magento na loja comprometida. A Sansec não confirmou essa leitura e a Disrex não publica o pedido montado. Dois locais são importantes para a primeira fase.
O cheque publicado da Sansec pesquisa em var/report/ o marcador X_TRACE_. Disrex disse que ambas as infecções foram envenenadas por meio de var/log/system.log e teriam sido perdidas por essa verificação, portanto, ambos os diretórios precisam ser pesquisados. O marcador já mudou: Disrex viu um cabeçalho de gatilho no formato X-TRACE - seguido por dez caracteres hexadecimais na manhã de 5 de setembro e o mesmo cabeçalho sem a palavra TRACE à tarde, portanto, uma pesquisa deve corresponder à forma e não à string exata. Um TypeError de array_merge() com um argumento inteiro em system.log, imediatamente após a inclusão, é uma evidência de que a exploração foi bem-sucedida, Disrex sa eu ia.
No entanto, uma variante mais furtiva retorna um array vazio e não deixa nada no log. Para o processo, Disrex disse que um thread de kernel genuíno pertence ao root e não possui memória residente, portanto, um nome entre colchetes no usuário do site com uso real de memória é o implante. O implante define sua linha de comando para a string literal entre colchetes, de modo que uma verificação escrita no campo de comunicação do processo não corresponde a nada. Disrex também descobriu que o binário em execução na memória em um armazenamento era uma construção diferente do arquivo no disco e recomenda fazer hash do processo em execução de /proc/<pid>/exe, bem como do arquivo.
Explosões inesperadas de e-mails de “Lembrete de falha na transação de pagamento” são um motivo para investigação, disse Sansec, embora pagamentos legítimos recusados gerem a mesma notificação. Um dos dois compromissos da Disrex veio à tona exatamente por esse e-mail. Rick Bouma, cofundador da Disrex, disse ao The Hacker News que a loja enviou por e-mail ao seu próprio proprietário um aviso de transação fracassada em que as variáveis do modelo nunca foram resolvidas: um corpo cheio de tags {{var ...}} brutas, um endereço de cliente em um domínio .invalid e um total de zero. Parece um pedido quebrado, disse Bouma, mas é o resultado da tentativa de exploração que passou pelo filtro de modelo do Magento, e o encaminhamento desse e-mail pelo comerciante iniciou a investigação que encontrou o implante dentro de uma hora.
Disrex publicou uma cópia anônima em um artigo de alerta antecipado, que adiciona o próprio texto substituto "ocorreu um erro ao gerar este conteúdo" do Magento aparecendo dentro do bloco de endereço como um terceiro aviso, e chama o e-mail de o sinal de alerta precoce mais útil para os comerciantes porque perceber que ele não precisa de ferramentas. Os seguintes indicadores foram publicados pela Sansec e na lista de indicadores da Disrex – a Sansec recomenda seu scanner eComscan para detectar o implante, e a versão 1.9.7 encerrará o processo para clientes do Shield. Disrex relatou um resultado limpo na Loja A. eComscan foi executado lá às 10:00 UTC do dia 5 de setembro, cerca de onze horas após a primeira execução do implante e enquanto 1.728 linhas cron estavam presentes, e relatou que a loja estava limpa.
A causa foi o escopo e não uma falha do scanner, disse Disrex ao The Hacker News: a varredura agendada foi apontada para a raiz do documento da loja e o implante foi instalado um diretório acima dele, no diretório inicial da conta. Desde então, a Disrex ampliou o caminho da varredura e disse que confirmaria o número de compilação do eComscan separadamente. Não há nenhuma correção do fornecedor para instalar. Até que a Adobe lance um, as opções são o desligamento temporário do GraphQL da Sansec; mitigações não oficiais publicadas por Disrex, ProxiBlue e Graycore; e duas configurações de servidor que não dependem da falha.
A Disrex publicou regras nginx e Apache que bloqueiam solicitações que transportam os parâmetros do exploit na string de consulta da URL. Seu próprio teste em uma loja ativa mostrou o limite: os mesmos parâmetros enviados em um corpo POST chegaram ao PHP, assim como um corpo JSON, porque o nginx e o Apache inspecionam apenas a string de consulta, disse Disrex. Disrex descreve as regras como a interrupção da campanha no momento em que ela é executada, em vez da vulnerabilidade. A principal mitigação do Disrex adiciona uma verificação a três métodos nos scanners de código de injeção de dependência do Magento, evitando que sejam executados fora da linha de comando.
A edição manual é revertida a cada instalação do compositor, então o Disrex também o envia como um patch de origem dos patches do compositor que é reaplicado na implantação e, segundo ele, se aplica inalterado de 2.4.6 a 2.4.9. Um dos três arquivos, ClassesScanner.php, é chamado por HTTP por pelo menos um módulo de terceiros, mageplaza/module-admin-permissions, e protegê-lo quebra a tela de administração desse módulo, então Disrex diz aos administradores para pesquisar o diretório de seu fornecedor antes de tocá-lo. A proteção foi testada em um arnês, e não dentro de uma loja de corrida, e a Disrex diz que não é uma solução completa por si só. Um usuário do GitHub, ProxiBlue, publicou separadamente o mesmo protetor em 5 de setembro como três patches não oficiais.
Bouma disse ao The Hacker News que ProxiBlue, a quem ele identifica como o desenvolvedor do Magento, Lucas van Staden, chegou à guarda idêntica sem coordenação, nos mesmos três métodos de scanner, com a mesma verificação PHP_SAPI !== 'cli' e a mesma mensagem de exceção, e que a própria versão do Disrex foi escrita durante sua resposta. Desde então, a Disrex reproduziu os três patches do ProxiBlue em seu repositório com crédito para que a convergência possa ser verificada em um só lugar, e alerta que os dois são a mesma correção e não devem ser aplicados um sobre o outro. A Disrex considera duas partes que chegam à mesma solução separadamente como uma forte corroboração de que é a pessoa certa. Nem a Sansec nem a Adobe confirmaram que esses scanners são o ponto final da cadeia.
Graycore, LLC publicou um módulo Magento no GitHub e Packagist em 5 de setembro cujo código atual, diz Graycore, fortalece três pontos da cadeia: a diretiva de bloco de modelo de e-mail recusa blocos de back-end, o gerador de URL de linha de grade verifica uma classe antes de construí-la, e as tags de abertura do PHP nos relatórios de erros fatais da API da Web estão quebradas. A versão no Packagist no momento em que este artigo foi escrito era uma versão anterior cuja única atenuação visava um resolvedor GraphQL do PayPal que já foi removido. O README diz “Isso é um reforço, não uma solução” e avisa que outros caminhos através da vulnerabilidade permanecem abertos e que uma loja já pode estar comprometida. Duas configurações de servidor não dependem do conhecimento da cadeia, disse Disrex.
Em uma de suas duas lojas, as primeiras quatro das seis funções PHP que o dropper tentou foram desativadas; proc_open não era, e o conta-gotas o usou para iniciar o implante, com open_basedir não fazendo nada para conter o processo filho. Adicionar proc_open às disable_functions do PHP e montar /tmp, /var/tmp e /dev/shm com noexec para que um binário baixado não possa ser executado são as camadas que o Disrex coloca à frente de cada regra em seu repositório. Para uma loja que já está infectada, o guia de limpeza do Disrex define a ordem: preserve a evidência primeiro, remova a entrada do cron antes de encerrar o processo porque o processo o restaura, não reinicie porque a cópia em /proc pode ser o único binário restante e não execute o compositor install para limpar porque ele substitui os carimbos de data e hora que mostram o que foi tocado. Em seguida, ele recomenda liberar o armazenamento da sessão desde que o implante o leu e girar a cripta/chave em app/etc/env.php, bem como todas as senhas de administrador, todas as chaves de API do provedor de pagamento e todas as outras credenciais de integração nesse arquivo.
Os provedores de hospedagem Nexcess e Liquid Web publicaram avisos de incidentes idênticos em 5 de setembro, informando que estavam revisando seus ambientes de servidores e implementando medidas de precaução. Nenhum deles reivindica um comprometimento confirmado do cliente ou sua própria reprodução da falha. A Disrex registrou 26 endereços de origem distintos em suas duas lojas, retirados dos próprios logs de acesso nginx das lojas e desduplicados, dois deles hospedando envio de infraestrutura em massa e o restante um pool de proxy residencial enviando de duas a seis solicitações cada, e disse que bloquear o endereço do único invasor no comunicado da Sansec teria interrompido menos de um quarto do tráfego que viu. Uma contagem anterior de 28 incluía dois servidores do próprio Disrex fazendo solicitações de verificação durante a resposta, que foram removidas.
Nenhuma fonte revelou os nomes dos agressores. O Hacker News entrou em contato com Adobe, Sansec e Graycore para comentar e atualizará a história se recebermos resposta. (A história foi atualizada após a publicação com respostas de Rick Bouma do Disrex Group, que corrigiu as versões, o status do Shield e os tempos de primeiro contato das duas lojas comprometidas, explicou o erro do eComscan, descreveu o e-mail de alerta antecipado que revelou um dos comprometimentos e confirmou que os patches do ProxiBlue, agora incluídos no repositório Disrex, foram obtidos de forma independente.) Veja como testar novos CVEs em seu ambiente, confirmar o que os invasores podem realmente explorar e corrigir as exposições que representam o problema. maior risco.
Aprenda como identificar riscos exploráveis mais rapidamente, priorizar o que é mais importante e reduzir ce exposição antes que ataques alimentados por IA acelerem a ameaça. Receba as últimas notícias, insights de especialistas, recursos exclusivos e estratégias de líderes do setor, tudo gratuitamente.