StyleSmuggler e os ataques recentes a lojas Magento: como atuam os hackers e como reduzir o risco

Os últimos dias mostraram algo que os administradores de lojas online sabem há muito tempo, mas que é fácil ignorar na manutenção diária: um sistema atualizado nem sempre significa um sistema seguro. Quando surge uma vulnerabilidade 0-day, os atacantes não esperam por um comunicado oficial do fabricante, por um número CVE organizado nem por uma data conveniente para implementar a correção. Bots analisam a internet, procuram endpoints vulneráveis e tentam instalar acesso persistente mais depressa do que a maioria das empresas consegue convocar uma reunião.

É precisamente este o caso do StyleSmuggler, uma vulnerabilidade ativamente explorada comunicada pela Sansec em 5 de setembro de 2026. Segundo a Sansec, os ataques começaram em 4 de setembro e afetam Magento Open Source e Adobe Commerce. A informação mais importante para os proprietários de lojas é dura: a vulnerabilidade também foi observada em instalações consideradas totalmente atualizadas.

Este texto não é um guia de ataque. É um resumo prático de como se apresenta hoje uma intrusão numa loja e-commerce e do que pode ser feito aqui e agora, antes de surgir ou ser confirmada uma correção oficial do fabricante.

O que aconteceu?

O StyleSmuggler é descrito como um RCE não autorizado, ou seja, a possibilidade de executar código no servidor sem iniciar sessão no painel de administração. Em termos simples: o atacante não precisa da palavra-passe do administrador, de uma conta de colaborador comprometida nem de acesso SSH. Basta uma aplicação vulnerável exposta à internet.

Segundo análises públicas, o ataque é composto por várias fases:

1. O atacante envia um pedido preparado para o Magento, explorando o endpoint GraphQL.
2. O código malicioso é colocado num local que o próprio Magento processa posteriormente.
3. A aplicação executa o código durante o mecanismo padrão de tratamento de e-mails, entre outros, no cenário de erro de pagamento.
4. É instalado no servidor um backdoor, ou seja, um mecanismo persistente de regresso.

É um modelo particularmente perigoso, porque não exige que um colaborador clique num link nem que uma tentativa de login seja bem-sucedida. A loja pode ser atacada simplesmente por estar publicamente acessível.

Como atuam hoje os hackers?

As intrusões em lojas online cada vez se parecem menos com o hacking manual de um único alvo. Com mais frequência, parecem uma campanha automatizada:

• análise da internet à procura de um endpoint específico,
• envio de tentativas prontas para explorar a vulnerabilidade,
• instalação de um processo que se faz passar por um elemento legítimo do sistema,
• manutenção do acesso através do cron ou de outro mecanismo de arranque automático,
• recolha de sessões, segredos, chaves API ou dados de pagamento,
• eventual instalação adicional de um webshell, skimmer ou outro backdoor.

No caso do StyleSmuggler, há dois detalhes especialmente importantes. Em primeiro lugar, o backdoor pode estar fora do diretório da loja, pelo que uma simples verificação dos ficheiros Magento não é suficiente. Em segundo lugar, o processo pode fingir ser um elemento do sistema, por exemplo, com um nome semelhante a kworker, fc-cache ou chronyd. Para um olhar pouco treinado, isto parece inofensivo, mas se estiver em execução sob o utilizador web deve acender um sinal de alerta.

Porque é que o patch level por si só não chega?

Perante uma vulnerabilidade comum, a resposta é simples: verificamos a versão, atualizamos e fechamos o assunto. Com um 0-day, a situação é diferente. Durante algum tempo, a vulnerabilidade é explorada antes de o fabricante publicar uma correção ou antes de a correção ser associada de forma inequívoca a um ataque específico.

Por isso, após um incidente deste tipo, é necessário separar duas perguntas:

• a loja continua vulnerável?
• a loja já foi comprometida anteriormente?

Não é a mesma coisa. Um WAF, o bloqueio do GraphQL ou um patch posterior podem limitar novas tentativas, mas não removem automaticamente um backdoor que possa ter sido instalado antes.

O que fazer imediatamente?

1. Limite ou desative temporariamente o GraphQL

Se a loja não utiliza GraphQL, a decisão mais simples é bloquear temporariamente /graphql até haver uma correção confirmada. Muitas lojas Magento clássicas, incluindo várias implementações baseadas em Hyvä, não precisam de GraphQL público para o frontend funcionar. A situação é diferente em lojas headless e PWA — aí o bloqueio pode interromper as vendas, pelo que é necessário aplicar regras WAF mais precisas ou restrições de tráfego.

Exemplo de orientação para nginx:

map $uri $gql_block { default 0; ~*^/+(index\.php/+)?graphql(\.php)?(/|$) 1;}

Em cada vhost Magento, antes dos restantes location:

if ($gql_block) { return 403;}

Depois de alterar a configuração:

nginx -t && systemctl reload nginx

Se houver Varnish à frente da loja, vale a pena limpar também a cache:

varnishadm ban 'req.url ~ .'

Após a implementação, é necessário verificar diferentes variantes do caminho, não apenas o /graphql ideal. O teste deve incluir, entre outros, /graphql, /GraphQL, /graphql/, /graphql.php, /index.php/graphql e variantes com barras duplas. O resultado esperado para GraphQL é 403, e para a página inicial da loja uma resposta normal, por exemplo 200.

2. Bloqueie o vetor conhecido styles[...]

Se não puder desativar todo o GraphQL, aplique pelo menos regras que bloqueiem o parâmetro observado styles[...] na query string e padrões pós-exploração conhecidos.

Para nginx, podem ser usadas regras nesta linha:

if ($query_string ~* 'styles(\[|%5[bB])') { return 403;}if ($request_uri ~* '/paypal/transparent/response/.*(eval|base64_decode|%3[cC]%3[fF])') { return 403;}if ($request_uri ~* '%3[cC]%3[fF]|<\?') { return 403;}

Para Apache, um mecanismo análogo pode basear-se em mod_rewrite, bloqueando ocorrências em bruto e codificadas de styles[ e tentativas de introduzir uma tag PHP no URL.

Nota importante: este tipo de regras vê o URL e a query string. Se uma variante do ataque mover o payload totalmente para o body do pedido POST, a regra do servidor web por si só pode não ser suficiente. Nesse caso, é necessário um WAF que analise o body, ModSecurity, uma solução como Sansec Shield ou a desativação temporária do GraphQL.

3. Verifique se a loja já foi comprometida

Bloquear novas tentativas é apenas metade do trabalho. A outra metade é verificar se o ataque já deixou vestígios.

Execute a verificação como utilizador de sistema do Magento:

crontab -l | grep -i gvfsdls -la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc-cache /tmp/.kw_* /tmp/.cache_* /tmp/.gvfsd-* /tmp/.fc-*/fc-cache /tmp/fc-cache 2>/dev/nullps -eo pid,comm,args | grep -iE 'kworker|fc-cache|chronyd'grep -ril 'x_trace_' var/report/

Dê especial atenção a:

• ficheiros em ~/.local/share/.gvfsd/,
• ficheiros fc-cache em localizações invulgares,
• diretórios temporários do tipo /tmp/.kw_*, /tmp/.cache_*, /tmp/.fc-*,
• entradas cron executadas de poucos em poucos minutos,
• processos que se fazem passar por processos do sistema, mas que correm como utilizador da loja,
• ficheiros PHP em pub/media, onde normalmente não deveriam existir.

Exemplo de verificação rápida de webshells:

find pub/media -name '*.php' -print

Se o resultado não estiver vazio, isto deve ser tratado como um incidente, e não como uma anomalia cosmética.

4. Verifique os logs de acesso

Nos logs, procure tentativas dirigidas ao GraphQL e pedidos invulgares para caminhos de pagamento. A simples presença de um pedido suspeito nem sempre significa uma intrusão bem-sucedida, mas mostra que a loja foi alvo.

Na prática, vale a pena verificar:

• pedidos POST para /graphql com parâmetros invulgares,
• ocorrências de styles[ e da versão codificada styles%5B,
• pedidos para /paypal/transparent/response/ com fragmentos suspeitos,
• séries repentinas de pedidos a partir de muitos endereços IP,
• tráfego proveniente de endereços conhecidos de IOC públicos.

Em materiais de trabalho surgem, entre outros, estes IOC: 185.157.160.251, 99.84.67.186, windwsecurity.run, ntp.timesync.to. No entanto, a defesa não deve limitar-se apenas a estes valores. Segundo descrições dos incidentes, parte do tráfego teve origem num conjunto maior de endereços e em infraestrutura intermediária.

5. Primeiro preserve as provas, depois limpe

É um erro frequente: o administrador vê um processo suspeito, termina-o, elimina ficheiros e só depois começa a análise. Com um backdoor bem escrito, isto pode destruir os vestígios mais importantes e, por vezes, até dificultar a recuperação de uma amostra.

A ordem deve ser mais conservadora:

1. Preserve os logs de nginx/Apache, PHP-FPM, sistema, Magento e cron.
2. Guarde a lista de processos, ficheiros abertos e ligações de rede.
3. Faça uma cópia dos ficheiros suspeitos para análise.
4. Remova as entradas cron responsáveis por recriar o processo.
5. Só depois pare os processos e remova os mecanismos de persistência.
6. Force o logout das sessões de utilizadores e administradores.
7. Rode os segredos: crypt/key, palavras-passe de administradores, chaves API de pagamentos, integrações, SMTP, ERP, PIM e marketplace.

Se a loja processa pagamentos ou dados de clientes, após uma comprometimento confirmado é necessário tratar o caso como um incidente de segurança completo, e não como uma simples remoção de vírus.

Algumas regras que reduzem realmente o risco

Minimize a superfície pública de ataque

Endpoints que a loja não utiliza não devem estar publicamente acessíveis. Isto aplica-se a GraphQL, painéis de administração, ambientes staging, domínios demo antigos e cópias esquecidas da loja. No e-commerce, muitas vezes não é a produção que falha, mas sim um staging antigo com uma base de dados real e os mesmos segredos.

Separe ambientes e permissões

O processo Magento não deve ter mais acesso do que aquele de que necessita. Ausência de sudo, uma conta de sistema separada para cada loja, separação do Redis, bases de dados separadas e comunicação de saída limitada podem transformar a comprometimento de uma loja num incidente limitado, em vez de uma catástrofe para toda a infraestrutura.

Monitorize processos, cron e ficheiros fora do webroot

Analisar apenas o diretório Magento é insuficiente. O backdoor pode estar no diretório home do utilizador, em /tmp, na cache de fontes ou noutro local acessível ao processo da aplicação. A monitorização deve abranger:

• novas entradas cron,
• processos invulgares sob o utilizador web,
• novos ficheiros executáveis em diretórios temporários,
• ligações ao Redis, bases de dados e internet,
• alterações em app/etc/env.php,
• novas contas de administradores.

Atualize, mas não confunda atualização com análise de incidente

Quando a Adobe publica uma correção, é necessário implementá-la. Mas, após um ataque 0-day, a simples implementação da correção não responde à pergunta sobre se alguém já esteve dentro do sistema. Por isso, depois do patch, continua a ser necessário verificar IOC, logs, sessões e segredos.

Prepare regras de emergência prontas a usar

Vale a pena ter no repositório ou na documentação operacional fragmentos prontos para nginx, Apache, Varnish e WAF. Em crise, não há tempo para escrever regras do zero. Também é uma boa prática testar os bloqueios em staging antes de serem necessários em produção.

O que deve fazer hoje o proprietário de uma loja?

Se gere Magento ou Adobe Commerce, faça pelo menos o seguinte:

1. Crie uma lista de todas as instâncias: produção, staging, demo, cópias de trabalho.
2. Verifique onde o GraphQL está público e se é realmente necessário.
3. Implemente um bloqueio temporário do GraphQL ou regras que bloqueiem styles[...].
4. Valide o bloqueio com testes HTTP.
5. Analise o servidor em busca de processos, cron, ficheiros e logs que indiquem StyleSmuggler.
6. Se encontrar IOC, preserve as provas e trate o caso como um incidente.
7. Após a correção oficial do fabricante, atualize todas as instâncias, incluindo staging e cópias antigas.
8. Depois da atualização, faça nova verificação e rode os segredos, se a loja puder ter sido comprometida.

A pior decisão é esperar até que o assunto fique esclarecido. Com um 0-day ativamente explorado, o tempo joga a favor do atacante. Mesmo um bloqueio temporário, se for bem testado e implementado de forma consciente, pode comprar horas preciosas.

Resumo

O StyleSmuggler é um bom exemplo do risco moderno no e-commerce: o ataque não começa no painel de administração, mas sim num endpoint público; não termina num único ficheiro no diretório da loja, mas num processo persistente fora do webroot; e um patch level atualizado não dá automaticamente resposta sobre se a loja esteve segura durante a janela de ataque.

A defesa tem de ser igualmente prática: limitar a superfície, bloquear o vetor conhecido, verificar a comprometimento, preservar provas, rodar segredos e só então considerar o assunto controlado.

Nestas situações, não ganha quem tem a política de segurança mais bonita, mas sim quem tem procedimentos prontos, logs, separação de ambientes e capacidade de implementar rapidamente regras de emergência sem parar todo o negócio.

Fontes e materiais

• Sansec: https://sansec.io/research/stylesmuggler-0day
• The Hacker News: https://thehackernews.com/2026/09/unpatched-magento-and-adobe-commerce.html
• Adobe Security Bulletin para Adobe Commerce: https://helpx.adobe.com/security/products/magento/apsb26-138.html