stylesmuggler-ioc-toolkit

StyleSmuggler (CVE-2026-75650) kit de IOC para Magento Open Source e Adobe Commerce. Detecte lojas comprometidas, implantes Rust, web shells PHP, artefatos de persistência e indicadores de comprometimento conhecidos.

Cobertura do patch oficial da Adobe — verifique isto antes de presumir que está seguro

Se você está em uma versão mais antiga e sem suporte, a Adobe não está enviando uma correção para você, mesmo que você seja igualmente explorável. Veja docs/PATCHING.md para suas opções.

Esta informação muda rapidamente. Verifique cruzadamente as fontes primárias antes de agir: o aviso da Sansec e o boletim da Adobe. Veja docs/TIMELINE.md para um registro contínuo e cite suas fontes ao atualizar qualquer coisa aqui.

O que o StyleSmuggler realmente é

O próprio parâmetro styles do GraphQL do Magento e seu scanner de arquivos baseado em injeção de dependência são abusados como uma primitiva de execução adiada baseada em arquivo em dois estágios, em vez de um único ponto de injeção óbvio:

1. Envenenar. Dados controlados pelo atacante alcançam um arquivo de log ou relatório gerado pelo Magento (var/log/system.log via um código de loja inválido que o Magento registra literalmente, ou var/report/<hash>), contrabandeados através do parâmetro styles[] do GraphQL, um cabeçalho de requisição mutado ou (para o segundo atacante, não relacionado, abaixo) o cabeçalho Store:.
2. Detonar. O atacante aciona o e-mail padrão "Payment Transaction Failed Reminder" do Magento. A renderização desse e-mail (caminho getProcessedTemplate do Magento) percorre um caminho de código que permite que o próprio scanner DI/código do Magento execute include() no arquivo envenenado, executando o PHP do atacante. Você não precisa abrir o e-mail — renderizá-lo no lado do servidor é suficiente — e a cadeia pode disparar mesmo quando a entrega do e-mail falha.

Um sinal de alerta precoce fácil, sem ferramentas: um e-mail distorcido de "Payment Transaction Failed Reminder" em sua caixa de entrada com tags {{var ...}} brutas e não renderizadas e um endereço de cliente terminando em .invalid. Este é frequentemente o primeiro sinal visível, antes que alguém verifique um log.

As atualizações da Sansec confirmaram um segundo caminho de exploração independente para a mesma campanha de implante Rust: mesmo lojas que moveram o armazenamento de sessões do Redis para o banco de dados ainda foram comprometidas — a segunda tentativa do mesmo operador teve sucesso segundos depois usando um arquivo enviado através do recurso de opções personalizadas do cliente do Magento. Mover o armazenamento de sessões não é uma correção por si só.

Separadamente, em 7 de setembro, a Sansec encontrou um atacante completamente não relacionado usando exatamente o mesmo ponto de entrada do StyleSmuggler para um payload muito mais simples: um web shell PHP depositado no cache de imagens de produtos do próprio Magento (pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php), precedido por uma sonda de reconhecimento que esconde seu payload no cabeçalho HTTP Store: e exfiltra suas descobertas via DNS em vez de uma resposta HTTP. Isso é "ferramenta pronta para uso", segundo a Sansec — não uma campanha sustentada — mas significa que um único host vulnerável pode carregar duas intrusões não relacionadas através de uma única falha. Limpar o implante Rust não significa que sua loja está limpa.

O próprio implante Rust também evoluiu: a construção original disfarçada de [kworker/u:8:0] (4 de set.) foi seguida por uma construção disfarçada de fc-cache v2.1.4 (6 de set.) que faz beaconing disfarçado de tráfego NTP, e depois um reimplante disfarçado de chronyd v2.1.5 (7 de set.) do mesmo implante, mesmo ID de agente — evidência de que o atacante está iterando ativamente para evadir qualquer detecção que você publique. A Sansec afirma que ainda não viu evidências de que este implante foi armado além de persistência/reconhecimento — não leia isso como garantia, dado o web shell funcional do atacante não relacionado no mesmo caminho de acesso.

Veja docs/FAQ.md para respostas rápidas, docs/VULNERABILITY.md para o relatório técnico completo e fontes, docs/PATCHING.md para aplicar a correção oficial da Adobe e docs/INCIDENT_RESPONSE.md para o que fazer se o scanner encontrar algo.

Início rápido

1. Corrija, se sua versão estiver coberta:

2. Verifique comprometimento existente independentemente do status do patch — corrigir interrompe nova exploração, não limpa um backdoor ou web shell existente:

Ou a versão Python para saída estruturada (JSON), por exemplo, para alimentar um SIEM:

Ambos os scripts são somente leitura por padrão — eles detectam e relatam, não matam processos nem excluem arquivos a menos que você passe --remediate, porque a limpeza prematura destrói evidências forenses (veja docs/INCIDENT_RESPONSE.md).

O que o scanner verifica

• Artefatos conhecidos de persistência no sistema de arquivos em todas as três construções observadas do implante Rust:
  • Construção [kworker/u:8:0]: ~/.local/share/.gvfsd/gvfsd-user, seus arquivos de bloqueio, /tmp/.kw_*, /tmp/.gvfsd_*
  • Construção fc-cache v2.1.4 (6 de set.): ~/.cache/fontconfig/fc-cache, /tmp/.fc_<8hex>.lock
  • Construção chronyd v2.1.5 (7 de set.): /tmp/.chrony-<8hex>/chronyd
• As entradas crontab auto-restauradoras que o implante escreve diretamente no spool do cron — a cada 5 minutos para a construção gvfsd-user, duas vezes por hora (13,43 * * * *) para fc-cache
• Um processo disfarçado chamado [kworker/u:8:0], fc-cache ou chronyd que não é propriedade de root (ou, para fc-cache/chronyd, não corresponde ao binário real do sistema)
• SHA-256 dos binários em disco e da imagem /proc/<pid>/exe ao vivo (os dois podem diferir — o implante foi observado se atualizando em memória)
• Arquivos de log/relatório envenenados (var/log/system.log, var/report/) para PHP injetado, as duas formas conhecidas de cabeçalho de gatilho (X-TRACE-<10hex> e X-<12hex>) e os marcadores de campanha do segundo atacante, não relacionado (ss5_/ss6_<hex>) e o domínio canário DNS (oast.site)
• Marcadores de resposta de prova de execução (MG<20hex>::...::/MG<20hex>) deixados nos logs quando o payload realmente executou
• Arquivos PHP sob pub/media — que nunca devem conter PHP executável em uma loja Magento configurada corretamente — correspondendo ao padrão de entrega do web shell do segundo atacante
• Conexões estabelecidas com os hosts C2/download publicados — incluindo o beaconing formatado como NTP da construção fc-cache/chronyd para ntp.timesync.to:123/UDP (e alternativas), e suas chamadas HTTP simples para serviços públicos de consulta de IP
• Contagens anômalas de conexões Redis locais (a coleta de sessões foi observada inteiramente sobre 127.0.0.1:6379, com zero tráfego C2 de saída — uma rede silenciosa não é uma rede limpa) — e note que mover sessões do Redis sozinho não fecha o segundo vetor de exploração baseado em upload de arquivo

Lista completa de indicadores com fontes: iocs/.

Correção e mitigação

1. Aplique o hotfix oficial da Adobe (VULN-39341 / APSB26-146) se sua versão estiver coberta — veja docs/PATCHING.md para identificadores, onde obtê-lo e como aplicá-lo. Esta é agora a prioridade, à frente das mitigações provisórias abaixo.
2. Se você não pode corrigir imediatamente, ou sua versão não está coberta, use as mitigações provisórias em mitigations/:
   • Bloqueie ou limite a taxa do caminho de entrega styles[] do GraphQL (nginx / Apache)
   • Bloqueie a execução de PHP sob pub/media/pub/static (nginx / Apache) — defesa direcionada contra a técnica de web shell do segundo atacante, não relacionado
   • Regras ModSecurity para inspeção do corpo POST e fail2ban como salvaguarda reativa
   • Veja mitigations/README.md para limitações de escopo — nenhuma destas fecha o vetor de opções personalizadas do cliente ou a entrega pelo cabeçalho Store: do segundo atacante.
3. Execute o scanner de comprometimento independentemente do status de patch/mitigação. Corrigir e mitigar interrompem a exploração nova; nenhum dos dois limpa um backdoor ou web shell já depositado.
4. Se o scanner encontrar algo, trate o host como totalmente comprometido, não apenas "backdoor presente". A execução de código como o usuário do site expõe tudo o que esse usuário pode ler, começando com app/etc/env.php. No mínimo, após a contenção: limpe o armazenamento de sessões (Redis e/ou banco de dados), rotacione a crypt/key do Magento, todas as senhas de administrador (e invalide as sessões de administrador existentes), a senha do banco de dados, cada chave de API do provedor de pagamento e outra credencial de integração em env.php, e quaisquer chaves SSH/implantação que o usuário do site pudesse ler. Verifique também a tabela admin_user para uma conta rogue e pub/media/ / pub/static/ / diretórios de tema para web shells depositados — tanto do implante Rust quanto do segundo atacante, não relacionado — antes de considerar uma loja limpa. Passos ordenados completos: docs/INCIDENT_RESPONSE.md.

Estrutura do repositório

Termos pesquisados com frequência

CVE-2026-75650, APSB26-146, VULN-39341, zero-day Magento 2026, zero-day Adobe Commerce, patch StyleSmuggler, vulnerabilidade GraphQL Magento, RCE parâmetro styles Magento, malware gvfsd-user, backdoor Magento fc-cache, malware Magento chronyd, malware processo kworker Magento, sequestro de sessão Redis Magento, RCE não autenticado Magento setembro 2026, exploit Magento 2.4.9, remoção de backdoor Adobe Commerce, web shell Magento pub/media, eComscan StyleSmuggler, Sansec Shield StyleSmuggler.

Fontes e proveniência

Cada indicador neste repositório remonta a uma fonte publicada e citada — principalmente o aviso da Sansec (atualizado pelo menos até 07/09/2026 20:50 UTC), o boletim APSB26-146 da Adobe e relatórios comunitários de resposta a incidentes de respondedores que lidaram com infecções ao vivo. Veja a citação no rodapé de cada arquivo em iocs/.

Não trate nada aqui como exaustivo ou final. IOCs (cabeçalhos de gatilho, strings de user-agent, disfarces de implante e agora os marcadores de campanha de um segundo atacante) já mudaram várias vezes dentro de dias da divulgação; espere que mudem novamente. Corresponda formas e comportamentos, não apenas strings literais, onde quer que os scripts permitam.

Contribuindo

Viu uma variante, um novo hash, um novo endereço de origem ou um falso positivo? Abra uma issue ou PR com o que você observou e como observou. Por favor:

• Redija os detalhes de identificação da sua própria organização antes de compartilhar.
• Não poste payloads de exploração ou requisições de gatilho funcionais aqui — apenas indicadores e lógica de detecção.
• Relate a vulnerabilidade subjacente em si à Sansec e ao PSIRT da Adobe, não a este repositório.

Licença

MIT para o código neste repositório (veja LICENSE). Os dados de indicadores são fornecidos "como estão" para uso defensivo, com fontes anotadas ao longo do texto.

Aviso legal

Esta é uma ferramenta defensiva não oficial, construída pela comunidade, não um produto Adobe ou Sansec, e não é afiliada a nenhum dos dois. É fornecida sem garantia. O patch oficial da Adobe (APSB26-146) foi lançado, mas a cobertura é limitada a versões específicas de produto — verifique o boletim de segurança da Adobe diretamente antes de presumir que sua instalação está coberta ou corrigida.