Vulnerabilidade zero-day no Magento: o que fazer agora

Em 7 de setembro de 2026, a Adobe confirmou algo que administradores de lojas Magento temem mais do que qualquer outra coisa: uma vulnerabilidade crítica sendo explorada ativamente antes de existir uma correção oficial disponível. A falha foi batizada de StyleSmuggler pela equipe de pesquisa da Sansec, que identificou as primeiras tentativas de exploração em 4 de setembro. Ela recebeu o identificador CVE-2026-75650, nota máxima de severidade (CVSS 10.0) e afeta praticamente todas as versões atualmente suportadas de Magento Open Source e Adobe Commerce.

O motivo de esse caso merecer atenção imediata, e não apenas mais um item de checklist de patch, é simples: lojas que já haviam aplicado as atualizações de segurança de julho e agosto de 2026 foram comprometidas mesmo assim. Isso muda a pergunta que todo gestor de e-commerce Magento precisa fazer esta semana. Não é “minha loja está atualizada?”. É “minha loja está sendo monitorada?”.

Aqui na Trezo, acompanhamos boletins de segurança Magento como rotina operacional, não como notícia isolada. Neste artigo, reunimos o que está confirmado sobre o StyleSmuggler, o que a Adobe já corrigiu e o que priorizar na sua operação nas próximas 48 horas.

Principais pontos do artigo

• O StyleSmuggler é uma vulnerabilidade de execução remota de código (RCE) que não exige autenticação para ser explorada.
• A Adobe confirma exploração ativa e já publicou um hotfix específico via boletim APSB26-146, com CVE-2026-75650.
• Lojas com todos os patches recentes aplicados ainda foram comprometidas, porque a falha era desconhecida até a campanha de ataques começar.
• O backdoor instalado após a invasão foi desenvolvido em Rust e usa técnicas específicas para se disfarçar de processos legítimos do Linux.
• Além do hotfix emergencial, a Adobe também publicou a atualização mensal regular de setembro (APSB26-138), com oito vulnerabilidades adicionais classificadas como críticas ou importantes.

Como funciona o ataque StyleSmuggler

O ataque acontece em duas etapas e não depende de uma senha válida em nenhum momento.

Na primeira etapa, o invasor insere código malicioso escondido em propriedades de estilo dentro do sistema de criação de páginas do Magento. Parte da cadeia de exploração pode utilizar o GraphQL para introduzir esse conteúdo especialmente preparado, que acaba sendo armazenado em arquivos usados pela própria plataforma, como registros em var/log/system.log ou relatórios internos.

Na segunda etapa, o gatilho é um comportamento absolutamente rotineiro de qualquer loja: o envio do e-mail automático “Payment Transaction Failed Reminder”, que notifica o cliente sobre uma falha no pagamento. Quando o Magento prepara ou reenvia essa mensagem, os componentes responsáveis por renderizar o template processam o conteúdo malicioso armazenado anteriormente, e o PHP acaba interpretando esse conteúdo como código executável.

O ponto mais perigoso dessa cadeia é que o e-mail não precisa ser aberto pelo destinatário, nem sequer entregue com sucesso. A execução ocorre durante a preparação da mensagem, dentro do próprio servidor. Isso também explica por que uma varredura tradicional em busca de um arquivo shell.php óbvio dentro da raiz do site não é suficiente para detectar o comprometimento.

Por que uma loja com patches em dia também pode estar vulnerável

Esse é o ponto que mais gera confusão entre equipes técnicas, e é também o que torna esse caso diferente de uma falha comum.

Aplicar as atualizações de segurança disponíveis continua sendo indispensável, mas um patch só existe depois que uma vulnerabilidade é conhecida. O StyleSmuggler é, por definição, uma falha zero-day: ela foi explorada antes de a Adobe publicar qualquer correção. Segundo a investigação da Sansec, foram observados comprometimentos em instalações que já utilizavam versões recentes e os patches de segurança de julho e agosto de 2026.

Na prática, isso significa que a mensagem “nenhuma atualização pendente” no painel administrativo não pode ser interpretada como sinônimo de “servidor seguro” diante de uma campanha zero-day em andamento. Enquanto o patch corrige o que já é conhecido, é a monitoração contínua do ambiente, fora do calendário de atualizações, que consegue flagrar um comportamento anômalo antes de virar um incidente.

Como o backdoor se esconde depois da invasão

Depois de conseguir executar código no servidor, o invasor instala um segundo estágio bem mais difícil de detectar: um malware desenvolvido em Rust, projetado especificamente para se misturar aos processos legítimos do Linux.

As primeiras versões identificadas usam um nome semelhante ao de uma thread legítima do kernel, como [kworker/u:8:0], e se instalam em uma pasta oculta fora dos diretórios normalmente associados à aplicação, como public_html, htdocs ou pub. Uma análise mais cuidadosa revela as inconsistências: o processo costuma rodar sob o usuário responsável pelo Magento em vez de root, e apresenta um consumo de memória incompatível com o de uma thread real do kernel.

Uma variante mais recente, identificada em 6 de setembro, adota outro nome e outra pasta, além de configurar uma tarefa agendada via cron para se reiniciar automaticamente a cada 30 minutos. Isso significa que encerrar o processo manualmente não resolve o problema: sem remover a persistência, o backdoor volta sozinho.

Para se comunicar com o servidor de comando e controle, o malware disfarça seu tráfego como se fosse uma sincronização de horário (NTP), usando portas comuns e nomes que imitam servidores de tempo, o que dificulta sua identificação por firewalls tradicionais. Antes de enviar qualquer dado, ele verifica se está sendo monitorado ou analisado; se detectar sinais de rastreamento, simplesmente não transmite informações, que normalmente incluem identificador do host, nome do computador, versão do sistema, uso de memória e se há acesso de administrador disponível.

O que a Adobe já corrigiu

A Adobe confirmou publicamente que está ciente da exploração ativa do CVE-2026-75650 e publicou, em 7 de setembro de 2026, o boletim APSB26-146 com prioridade 1, a classificação mais alta da empresa. O boletim disponibiliza um hotfix específico para Adobe Commerce e Magento Open Source, cobrindo as versões com suporte ativo, da linha 2.4.4 até a 2.4.9.

No dia seguinte, 8 de setembro, a Adobe também lançou o pacote mensal regular de segurança de setembro, o boletim APSB26-138, que resolve oito vulnerabilidades adicionais classificadas como críticas ou importantes, entre elas falhas de cross-site scripting armazenado com potencial de escalonamento de privilégio e problemas de autorização incorreta. A Adobe não relata exploração ativa conhecida para esses itens específicos, mas recomenda a atualização para a versão mais recente em ambos os boletins.

Na prática, isso significa dois pacotes de correção para aplicar, não apenas um: o hotfix emergencial do CVE-2026-75650 e a atualização mensal regular de setembro.

O que fazer agora na sua operação Magento

Diante de uma vulnerabilidade com exploração ativa confirmada, a resposta precisa cobrir contenção e investigação ao mesmo tempo, não uma depois da outra.

Aplique o hotfix do CVE-2026-75650 com prioridade máxima. Esse é o item que resolve a causa raiz. A atualização mensal regular (APSB26-138) deve ser aplicada em seguida.

Reduza a superfície de ataque enquanto o patch é aplicado. Se a operação da loja não depende de GraphQL, desativar ou restringir temporariamente esse endpoint reduz a exposição. Essa decisão precisa ser avaliada com cuidado em lojas headless, PWA ou com integrações externas que dependem dele.

Restrinja funções perigosas do PHP. Funções como exec, system, shell_exec, passthru, proc_open e popen podem ser limitadas via disable_functions quando tecnicamente viável, com atenção especial ao proc_open, que costuma ser esquecido nessa configuração. Teste antes de aplicar em produção, para não interromper tarefas legítimas.

Monitore o volume de e-mails de falha de pagamento. Um pico incomum de mensagens “Payment Transaction Failed Reminder” pode indicar tentativas de exploração em andamento.

Procure sinais de comprometimento antes de qualquer limpeza. Vale checar processos que imitam threads do kernel sem rodar como root, tarefas agendadas inesperadas no crontab e conteúdo PHP injetado em arquivos de log ou relatório. Encerrar um processo suspeito não é o mesmo que remover sua persistência.

Troque as credenciais administrativas se houver qualquer suspeita de comprometimento. E, diante de evidência concreta de invasão, reconstruir o servidor a partir de uma imagem confiável costuma ser mais seguro do que tentar garantir manualmente que todos os vestígios foram removidos.

A leitura da Trezo sobre o StyleSmuggler

O que o StyleSmuggler expõe não é uma falha de disciplina técnica. As lojas comprometidas neste caso não estavam desatualizadas, elas tinham acabado de aplicar os patches disponíveis. O problema é que patch corrige o que já é conhecido, e um zero-day, por definição, não é conhecido até virar campanha ativa de ataque.

Isso muda o que realmente separa uma operação Magento resiliente de uma vulnerável. Não é apenas a velocidade de aplicar a correção quando ela chega, embora isso continue sendo indispensável. É a capacidade de observar o ambiente continuamente, processos, tarefas agendadas, tráfego de rede e comportamento fora da raiz da aplicação, mesmo quando não existe nenhum CVE publicado apontando para onde olhar. Quando essa vigilância já é rotina de infraestrutura, um pico anômalo no envio de e-mails de pagamento ou um processo com nome de thread de kernel rodando fora do root vira sinal de alerta antes de virar incidente, não depois.

Fale com quem trata segurança Magento como rotina, não como notícia

Sua operação já aplicou o hotfix do CVE-2026-75650? Se ainda não tem certeza sobre a exposição real da sua loja, ou precisa de suporte para investigar sinais de comprometimento, Fale com nossos especialistas. A Trezo opera infraestrutura Magento sobre AWS Partner Network e mantém certificação ISO 27001, o que estrutura como monitoramos e respondemos a esse tipo de incidente antes que ele afete sua operação.

Perguntas frequentes