Hackers infectam 953 lojas Magento com código malicioso hoje

Segurança Digital

Mais de 900 lojas Magento foram comprometidas por código malicioso que evita detecção e ataca usuários reais.

Leia também: Falha em app pirata desativa atualizador em 2 mi de PCs hoje

Uma campanha de hackers em andamento já infecta 953 lojas virtuais que usam a plataforma Magento, inserindo código JavaScript malicioso em blocos CMS das páginas e ativando o ataque apenas para visitantes reais, o que dificulta a detecção por scanners de segurança automáticos.

JavaScript oculto em blocos CMS e ataque só para visitantes reais

A empresa holandesa de segurança Sansec, especializada em comércio eletrônico, identificou que os criminosos embutem pequenos trechos de código em blocos CMS do Magento. Quando o cliente acessa a loja comprometida, esse código carrega um “loader” JavaScript a partir de domínios controlados pelo grupo.

“Quando você visita, esse código faz seu navegador perguntar ao servidor do grupo o que fazer a seguir”, explicou a Sansec. O servidor verifica primeiro se o acesso parece ser de um comprador humano ou de um robô de segurança; se identificar um scanner, não entrega nada, o que mantém as páginas aparentemente limpas em verificações automáticas.

Ao menos cinco domínios diferentes já foram usados na campanha. Um deles é o deepveindrilling[.]com, registrado em 6 de outubro de 2026 e encontrado em blocos CMS de 83 lojas desde então. Em fases anteriores, outro domínio, additionalver[.]com, servia scripts que podiam inclusive apenas marcar o visitante com um cookie por 24 horas. “Solicitar o script additionalver[.]com como visitante Windows desktop retorna ‘QWE=123;’, que apenas define um cookie por 24 horas”, relatou a Sansec.

Como funciona o loader e por que ele é difícil de remover

Os pesquisadores observaram duas versões principais do loader JavaScript. Na primeira, o código malicioso baixado do domínio dos atacantes armazena o payload no localStorage do navegador, uma área de armazenamento persistente. Assim, o código injetado pode ser executado novamente em visitas futuras, mesmo que o domínio malicioso fique fora do ar.

A segunda versão repete esse comportamento e vai além, adicionando técnicas de fingerprinting — uma espécie de “impressão digital” do navegador — para identificar padrões típicos de bots e scanners de segurança. Só depois de concluir que se trata de um comprador real o loader libera o payload, cujo objetivo final ainda não é conhecido. A suspeita é de que possa envolver roubo de dados de clientes, fraudes financeiras ou outros ataques em segundo estágio.

Versões mais antigas da campanha também exploraram a plataforma de rastreamento de anúncios Keitaro como sistema de distribuição de tráfego, variando a resposta para cada visitante: em alguns casos entregavam um payload, em outros redirecionavam ou simplesmente não faziam nada, sempre com o foco em escapar de ferramentas automatizadas.

Como os atacantes entram nas lojas Magento

O levantamento da Sansec indica que 471 das 953 lojas foram comprometidas por meio da falha conhecida como PolyShell (CVE-2026-48356), que permite a injeção de webshells — portas de administração remota — em servidores Magento vulneráveis. Outras 102 lojas tiveram arquivos enviados explorando PolyShell ou outra falha crítica, a SessionReaper (CVE-2025-54236).

Em um dos casos analisados, uma loja rodando Magento 2.4.7-p1 tinha webshells PolyShell disfarçados como imagens PNG no diretório pub/media/custom_options/quote/, ao lado do loader additionalver[.]com em um bloco CMS. “O bloco mudou para deepveindrilling[.]com em 7 de outubro. A loja ainda não aplicou a correção APSB26-73 da Adobe para PolyShell”, apontou a Sansec.

Nem todos os ataques, porém, dependem de falhas não corrigidas. Em outra loja, com a versão 2.4.7-p10 do Magento e sem patches em falta no núcleo, os invasores criaram uma conta de administrador falsa e usaram esse acesso legítimo para injetar o código malicioso nos blocos CMS.

Risco para lojistas e consumidores

A campanha atinge principalmente lojas de comércio eletrônico baseadas em Magento, mas o impacto vai além da plataforma. Para lojistas, a presença de JavaScript malicioso nas páginas pode comprometer a integridade das transações, abrir espaço para fraudes, derrubar a confiança de clientes e gerar prejuízos financeiros e de reputação.

Consumidores que acessam essas lojas correm o risco de ter dados pessoais e financeiros capturados, serem redirecionados para páginas fraudulentas ou virar alvo de ataques mais sofisticados, já que o código só é entregue quando o sistema acredita estar diante de um usuário real. Como parte do payload fica armazenada no navegador, a ameaça pode persistir mesmo após o lojista derrubar o domínio malicioso principal.

Entenda o contexto

A descoberta dessa campanha ocorre em meio a um cenário mais amplo de exploração de falhas graves em tecnologias ligadas ao comércio eletrônico, em especial no ecossistema PHP. Um conjunto recente de duas vulnerabilidades críticas em PHP (CVE-2026-109618 e CVE-2026-109619), apelidadas de PHP2Shell, está sendo alvo de varreduras e tentativas de exploração em massa.

O pesquisador Adel Karimi registrou, em servidores de honeypot, o que descreve como a primeira exploração bem-sucedida dessas falhas em ambiente real. “Pesquisador Adel Karimi registrou a primeira exploração em ambiente real das vulnerabilidades PHP para execução de comandos shell”, disse ele. Os comandos observados usam ferramentas como wget, curl ou o próprio PHP para buscar payloads adicionais em um servidor remoto. Até agora, porém, não foram identificados artefatos de segunda fase baixados com sucesso.

O paralelo entre a campanha contra lojas Magento e as novas explorações em PHP reforça a avaliação de que grupos maliciosos estão investindo em cadeias de ataque mais complexas, com múltiplos estágios e forte ênfase em evasão de detecção.

O que lojas virtuais devem fazer agora

Especialistas recomendam que administradores de lojas online façam auditorias imediatas em seus ambientes. A orientação é revisar as tabelas cms_block e cms_page do Magento em busca de blocos inesperados ou alterados, checar a existência de contas administrativas suspeitas e inspecionar diretórios como pub/media à procura de arquivos que possam esconder webshells.

Também é considerado crítico aplicar as correções de segurança mais recentes, incluindo o boletim APSB26-73 da Adobe para a falha PolyShell, manter o Magento e extensões atualizados e reforçar políticas de senhas fortes e autenticação de administradores. A Sansec segue monitorando a campanha e novos domínios usados pelos atacantes, enquanto equipes de segurança trabalham em ferramentas de detecção mais eficazes para loaders que filtram bots e dependem do comportamento do navegador.