Hackers estão explorando uma nova vulnerabilidade sem patch no Magento Open Source e no Adobe Commerce que permite executar código malicioso no servidor de uma loja online sem necessidade de login, informou a empresa holandesa de segurança para e-commerce Sansec em um comunicado publicado em 5 de setembro.
A Sansec, que descobriu a falha e a batizou de StyleSmuggler, disse que os ataques começaram em 4 de setembro. “A Sansec está publicando isso cedo porque as lojas estão sendo comprometidas agora”, afirmou a empresa.
Até 6 de setembro, a Adobe ainda não havia publicado um comunicado, um identificador CVE, um patch nem uma alternativa temporária, e o índice de boletins de segurança do Adobe Commerce não mostrava nada após a atualização de 11 de agosto.
Um ataque bem-sucedido dá ao invasor execução de código no servidor da loja e instala um backdoor persistente. A Sansec disse que todas as versões atuais são afetadas, inclusive a 2.4.9, e que reproduziu a cadeia completa sem autenticação em instalações limpas do Magento Open Source 2.4.7, 2.4.8 e 2.4.9.
A primeira vítima da empresa rodava a 2.4.6-p15 com as atualizações de segurança de julho e agosto de 2026 da Adobe aplicadas, que é o nível mais recente de patch oferecido pela Adobe para essa linha e que o boletim de agosto da empresa identifica como 2.4.6-2026-aug.
A Sansec não publicou uma reprodução no Adobe Commerce nem no Adobe Commerce on Cloud, e a Adobe não confirmou quais versões estão afetadas. A Sansec também não informou quantas lojas foram comprometidas.
A orientação provisória dos pesquisadores para lojas que não usam o produto Shield da empresa é desativar o GraphQL até que a Adobe libere uma correção temporária.
A Disrex Group, empresa de hospedagem e desenvolvimento para Magento que atuou em duas das lojas comprometidas, observa que vitrines headless e progressive web app exigem GraphQL, enquanto a maioria das vitrines clássicas e baseadas em Hyvä não exige.
A próxima atualização de segurança programada da Adobe está prevista para 8 de setembro, disse a Sansec, e ainda não se sabe se ela cobrirá esse bug.
As conclusões da Disrex são uma evidência independente de exploração fora da Sansec. Em um repositório de resposta a incidentes publicado em 5 de setembro, a empresa disse ter atendido duas lojas comprometidas em 5 de setembro e uma terceira que foi atacada, mas não invadida, e afirmou que suas regras para o servidor web se baseiam no tráfego de ataque capturado em uma das lojas comprometidas.
Essa loja rodava Magento 2.4.7-p2, um nível de patch de segurança que o histórico de versões da Adobe situa em agosto de 2024, oito níveis atrás da atual 2.4.7-p10. A loja que a Disrex identifica como Store A era cliente do Sansec Shield e foi atingida às 23h10 UTC de 4 de setembro, horas antes de as primeiras regras de bloqueio da Sansec entrarem em vigor.
O repositório traz seu próprio alerta. “Este repositório foi escrito com ajuda de IA, durante um incidente em andamento, em poucas horas”, diz o README, acrescentando que o material não foi revisado, que suas regras para Apache nunca foram testadas em um servidor Apache real e que a maior parte dos comandos de limpeza foi apenas escrita, e não executada.
Os indicadores da Sansec descrevem o implant como um processo em segundo plano disfarçado sob [kworker/u:8:0], nome que pertence a uma thread do kernel Linux, com um binário instalado em ~/.local/share/.gvfsd/gvfsd-user, dentro do diretório pessoal do usuário do site e não na raiz da aplicação web, além de uma entrada de cron que o reinicia a cada cinco minutos.
A Disrex descreveu o binário como um programa Rust ofuscado, vinculado estaticamente, com cerca de 1,9 MB, compilado para x86-64 e arm64, e disse que a entrada de cron é gravada diretamente no arquivo spool em /var/spool/cron/crontabs/, de modo que o log do sistema não mostra substituição do crontab.
Uma das lojas tinha a mesma linha repetida 1.728 vezes, e o implant a recolocava em menos de um segundo após a remoção.
Em uma das duas lojas, o implant não fez nenhuma conexão de saída. Ele manteve 28 conexões com a própria instância Redis da loja na porta 6379. Segundo a Disrex, ele leu dali o armazenamento de sessões do Magento, e nenhuma das duas capturas de pacotes, cada uma com mais de 200 MB e feitas enquanto o implant estava ativo, continha um único pacote para o host de download ou para o endereço de command and control citado pela Sansec.
A Sansec disse que, para clientes Shield atacados antes de suas regras entrarem em vigor, não há indícios de que o backdoor tenha sido de fato usado, e recomendou a rotação das credenciais do Magento sempre que o processo for identificado.
O ataque funciona em duas etapas, segundo o resumo da Sansec. Primeiro, ele injeta código PHP em um arquivo que o próprio Magento grava, por exemplo, ao gerar um relatório de falha. Depois, faz o Magento executar esse arquivo ao disparar o e-mail padrão “Payment Transaction Failed Reminder” da plataforma. O código roda enquanto o Magento renderiza a mensagem, de modo que ninguém precisa abri-la, e o ataque pode ter sucesso mesmo se a entrega do e-mail falhar.
A Sansec ainda não publicou a cadeia completa do exploit e disse que uma análise detalhada da cadeia, do dropper e do implant será divulgada em uma atualização.
A leitura da Disrex sobre a cadeia, publicada em um texto técnico junto com suas regras, é que uma diretiva dentro do texto injetado aciona uma sequência de classes do próprio Magento para chegar a código que existe apenas para atender ao compilador de injeção de dependência da linha de comando.
Esse código termina incluindo um caminho de arquivo escolhido pelo atacante, o mesmo log contaminado um momento antes. O dropper PHP executado tenta seis funções PHP em sequência para iniciar um processo, depois baixa e dispara o implant. A Disrex aponta três arquivos em setup/src/Magento/Setup/Module/Di/Code/ como o ponto final da cadeia. A Sansec não confirmou essa leitura, e a Disrex não publicou a requisição montada.
Dois locais importam para a primeira etapa. A verificação publicada pela Sansec procura o marcador X_TRACE_ em var/report/. A Disrex disse que suas duas infecções foram contaminadas em var/log/system.log e teriam passado despercebidas por essa checagem, de modo que os dois diretórios precisam ser pesquisados.
O marcador já mudou: a Disrex viu pela manhã de 5 de setembro um cabeçalho de gatilho no formato X-TRACE- seguido de dez caracteres hexadecimais e, à tarde, o mesmo cabeçalho sem a palavra TRACE. Por isso, a busca deve considerar o formato, e não a string exata.
Um TypeError de array_merge() com um argumento inteiro em system.log, imediatamente após o include, é prova de que o exploit funcionou, disse a Disrex. No entanto, uma variante mais discreta retorna uma matriz vazia e não deixa nada no log.
No caso do processo, a Disrex explicou que uma thread legítima do kernel é de propriedade de root e não tem memória residente, então um nome entre colchetes em um usuário não privilegiado, com uso real de memória, é o implant. O implant define sua linha de comando como a string literal entre colchetes, de modo que uma checagem baseada no campo comm do processo não encontra nada.
A Disrex também identificou que o binário em execução na memória em uma das lojas era uma compilação diferente do arquivo em disco, e recomenda gerar hash do processo em execução a partir de /proc/<pid>/exe, além de conferir o arquivo. Picos inesperados de e-mails “Payment Transaction Failed Reminder” são motivo para investigação, disse a Sansec, embora pagamentos recusados legítimos gerem a mesma notificação.
Os seguintes indicadores foram divulgados pela Sansec e pela lista de indicadores da Disrex:
Processo: [kworker/u:8:0] pertencente a um usuário não root
Arquivo: ~/.local/share/.gvfsd/gvfsd-user
Arquivo: ~/.local/share/.gvfsd/.gvfsd_<8hex>.lock
Arquivo: /tmp/.gvfsd_<8hex>.lock
Arquivo: /tmp/.kw_<random><random>
Cron: */5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user, com uma variante apontando para /tmp/.kw_
SHA-256: e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7 (amostra da Sansec)
SHA-256: 8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef (no disco em ambas as lojas da Disrex)
SHA-256: 251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220 (em execução na memória em uma loja da Disrex)
Domínio: 247.cdnflare[.]xyz (host de download do malware)
IP: 99.84.67[.]186:443 (command and control via WebSocket e TLS, segundo a Sansec)
IP: 88.216.72[.]181 (origem do atacante, segundo a Sansec)
IP: 5.181.86[.]133 (origem do atacante enviando em massa, segundo a Disrex)
A Sansec recomenda seu scanner eComscan para detectar o implant e disse que a versão 1.9.7 encerrará o processo para clientes Shield.
A Disrex relatou o resultado oposto em uma das lojas: o eComscan foi executado com as verificações de processo em segundo plano e de tarefas agendadas ativadas enquanto o implant estava ativo, com 1.728 linhas de cron presentes, e informou que a loja estava limpa. A Disrex não informou qual versão do eComscan foi usada nem quando.
Não há correção do fornecedor para instalar. Até que a Adobe lance uma, as opções são o desligamento temporário do GraphQL sugerido pela Sansec, três mitigações não oficiais publicadas pela Disrex, pela ProxiBlue e pela Graycore, além de duas configurações de servidor que não dependem da falha.
A Disrex publicou regras para nginx e Apache que bloqueiam requisições com os parâmetros do exploit na string de consulta da URL. O próprio teste em uma loja real mostrou o limite da abordagem: os mesmos parâmetros enviados no corpo de uma requisição POST chegaram ao PHP, assim como um corpo JSON, porque nginx e Apache inspecionam apenas a string de consulta, disse a Disrex. A empresa descreve as regras como uma forma de interromper a campanha como ela está ocorrendo hoje, e não a vulnerabilidade em si.
A principal mitigação da Disrex adiciona uma verificação a três métodos nos analisadores de injeção de dependência do Magento, impedindo que sejam executados fora da linha de comando. A edição manual é revertida a cada composer install, então a Disrex também a disponibiliza como um patch de source via composer-patches, que é reaplicado na implantação e, segundo a empresa, funciona sem alterações da 2.4.6 até 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 proteger esse arquivo quebra a tela de administração desse módulo. Por isso, a Disrex orienta administradores a procurar em seu diretório vendor antes de tocá-lo.
A proteção foi testada em um ambiente de teste, e não dentro de uma loja em execução, e a Disrex diz que ela não é uma correção completa por si só. Um usuário do GitHub, ProxiBlue, publicou a mesma proteção em 5 de setembro, junto com três patches não oficiais. Nem a Sansec nem a Adobe confirmaram que é nesses scanners que a cadeia termina.
A Graycore, LLC publicou em 5 de setembro um módulo Magento no GitHub e no Packagist cujo código atual, segundo a empresa, endurece três pontos da cadeia: a diretiva de bloco do template de e-mail recusa blocos de backend, o gerador de URL de linhas da grade verifica uma classe antes de construí-la, e tags de abertura PHP em relatórios fatais de erro da Web API são quebradas.
A versão no Packagist no momento da publicação era uma versão anterior, cuja única mitigação mirava um resolvedor GraphQL do PayPal que desde então foi removido. O README diz “Isso é endurecimento, não uma correção” e alerta que outros caminhos pela vulnerabilidade continuam abertos e que uma loja pode já estar comprometida.
Duas configurações de servidor não dependem de conhecer a cadeia, disse a Disrex. Em uma de suas duas lojas, as quatro primeiras das seis funções PHP que o dropper tentou estavam desativadas; proc_open não estava, e o dropper a usou para iniciar o implant, com o open_basedir sem efeito para conter o processo filho.
Adicionar proc_open à lista 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 a Disrex coloca antes de qualquer regra em seu repositório.
Para uma loja já infectada, o guia de limpeza da Disrex define a ordem: preservar evidências primeiro, remover a entrada de cron antes de encerrar o processo, porque o processo a restaura, não reiniciar, porque a cópia em /proc pode ser o único binário restante, e não rodar composer install para limpar, porque isso sobrescreve os carimbos de data e hora que mostram o que foi tocado.
Em seguida, a empresa recomenda limpar o armazenamento de sessões, já que o implant o leu, e rotacionar a chave crypt em app/etc/env.php, além de todas as senhas de administradores, todas as chaves de API dos provedores de pagamento e qualquer outra credencial de integração nesse arquivo.
As hospedagens Nexcess e Liquid Web publicaram avisos de incidente idênticos em 5 de setembro, dizendo que estavam revisando seus ambientes de servidor e implementando medidas preventivas.
Nenhuma delas afirma ter confirmado um cliente comprometido ou ter reproduzido a falha internamente. A Disrex registrou 26 endereços de origem distintos em suas duas lojas, dois deles de infraestrutura de hospedagem enviando em massa e o restante de um pool de proxies residenciais que enviava de duas a seis requisições cada, e disse que bloquear o único endereço do atacante citado no comunicado da Sansec teria interrompido menos de um quarto do tráfego observado. Nenhuma fonte nomeou os atacantes.
Segundo reportagens a Adobe, a Sansec, a Disrex e a Graycore foram contatadas para comentar e a matéria será atualizada se houver resposta.
Publicidade
Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...