Uma falha nota 10 de 10 no Magento e no Adobe Commerce: o que realmente aconteceu

Primeiro, a resposta direta: em 4 de setembro de 2026, invasores começaram a explorar uma falha sem correção no Magento Open Source e no Adobe Commerce, registrada como CVE-2026-75650 com nota de gravidade 10.0 — a mais alta possível. A falha permite executar comandos no servidor da loja sem login e sem nenhum privilégio, e a Adobe lançou a correção na noite de 7 de setembro. Isso deixa três dias inteiros em que as lojas ficaram expostas sem proteção alguma. É exatamente por isso que instalar o patch não basta: se a sua loja roda nessa plataforma, a suposição segura é que você pode ter sido comprometido antes de a correção existir, e a resposta certa é procurar sinais de invasão e trocar suas chaves de criptografia e todas as credenciais — não instalar a atualização e seguir o dia normalmente.

Quem é afetado, exatamente

A lista é incomumente ampla, porque inclui a versão mais recente disponível no momento da descoberta:

  • Magento Open Source e Adobe Commerce: versões da 2.4.4 à 2.4.9, incluindo todas as atualizações de patch até agosto de 2026.
  • Adobe Commerce B2B: versões da 1.3.3 à 1.5.3, até a atualização de agosto de 2026.
  • Qualquer versão anterior à 2.4.4: já fora de suporte, e a categoria mais perigosa porque o hotfix oficial não a cobre.

Em bom português: se você rodava um Magento totalmente atualizado em 1 de setembro, estava exposto. Não é o cenário conhecido de negligência sobre o qual costumamos alertar — é um zero-day genuíno, do qual ninguém tinha como se antecipar.

Como o ataque funciona sem senha

O ataque acontece em duas etapas e abusa da capacidade do Magento de montar modelos de e-mail. Na primeira etapa, o invasor envia uma requisição forjada para um caminho de resposta de pagamento, e todo o conteúdo dessa requisição é gravado em um arquivo de relatório de erro no servidor. Na segunda etapa, uma requisição ao endpoint GraphQL aponta de volta para esse arquivo envenenado, e o conteúdo dele é executado enquanto um e-mail de lembrete de falha de pagamento está sendo preparado.

O que merece a atenção de um empresário não é o detalhe técnico, mas o que ele revela: caminhos públicos que parecem totalmente inocentes — a resposta de um gateway de pagamento, um endpoint de consultas da vitrine, um e-mail automático — combinados em uma rota completa até o servidor. Vulnerabilidades graves raramente são uma única porta escancarada; muito mais vezes são uma cadeia de portas pequenas, cada uma parecendo perfeitamente razoável isoladamente.

O que os invasores plantaram depois de entrar

É aqui que aparece a diferença entre um vândalo e uma operação organizada. As cargas observadas não eram notas barulhentas de ransomware, mas ferramentas silenciosas de persistência:

  • Um backdoor escrito em Rust que se disfarça de um dos processos do kernel do sistema operacional, para não chamar a atenção de quem passa os olhos por uma lista de processos.
  • Tráfego de comando e controle camuflado pela porta de sincronização de horário, de modo que a atividade parece um ajuste rotineiro de relógio nos logs de rede.
  • Web shells em PHP gravados dentro das pastas de cache de imagens de produtos — lugares que ninguém costuma inspecionar porque estão cheios de arquivos temporários.
  • Ferramentas adicionais de acesso remoto de um segundo invasor com ferramentas sem relação com as primeiras, o que significa que a falha estava sendo explorada por mais de um grupo ao mesmo tempo.

O objetivo de cargas como essas em uma loja on-line conhecida é ficar por muito tempo e ler os dados de pedidos e pagamentos à medida que passam — não derrubar o site. Uma loja infectada continua funcionando de forma totalmente normal, e essa é a parte inquietante.

Por que instalar a atualização não basta

Porque, se um invasor entrou antes de 7 de setembro, ele agora tem uma cópia das suas chaves de criptografia e das credenciais armazenadas. O patch fecha a porta por onde ele entrou; não o expulsa lá de dentro. A própria orientação da Adobe foi explícita nesse ponto: aplicar a correção e depois trocar as chaves de criptografia, as senhas do painel de administração, os tokens de API, as credenciais do gateway de pagamento, as senhas do banco de dados e as chaves de acesso ao servidor.

O patch estanca o sangramento. Trocar as chaves é o que tira o convidado indesejado de dentro de casa.

Um plano de ação prático para o dono da loja

  • Primeiro — confirme que a correção está mesmo instalada, e não que alguém disse que estava. Peça à sua equipe uma prova do log de patches no próprio servidor, não uma mensagem tranquilizadora.
  • Segundo — procure vestígios de invasão: processos em execução suspeitos com nomes que imitam processos do sistema, arquivos PHP dentro das pastas de mídia e imagens e arquivos de relatório de erro incomuns.
  • Terceiro — revise o log de e-mails enviados. Um pico repentino de e-mails de lembrete de falha de pagamento é um indicador direto de tentativas de exploração, e qualquer gestor de operações consegue lê-lo sem conhecimento profundo de segurança.
  • Quarto — troque todas as chaves sem exceção, principalmente as credenciais do gateway de pagamento. Isso exige uma janela de manutenção planejada, não uma decisão improvisada no horário de pico.
  • Quinto — se a sua versão é anterior à 2.4.4, pare de esperar um patch oficial que não vai chegar. Defina um plano de atualização com uma data real e, enquanto isso, coloque a loja atrás de um firewall de aplicação web.
  • Sexto — documente o que você fez. Se ficar comprovado que dados de clientes vazaram, você vai precisar de uma linha do tempo do que fez e quando.

O aspecto regulatório na Arábia Saudita: dados de clientes não são só uma questão técnica

Uma loja on-line que guarda nomes, endereços, números de celular e histórico de pedidos dos clientes está tratando dados pessoais regidos pela Lei de Proteção de Dados Pessoais. Um vazamento não fica como assunto interno entre a loja e o provedor de hospedagem; ele gera obrigações perante a autoridade competente e perante os próprios titulares dos dados. Por isso, a pergunta que o dono de uma loja deveria fazer hoje não é só "o servidor recebeu o patch?", mas "consigo demonstrar que os dados dos meus clientes não foram tocados?".

Se a sua loja roda em uma plataforma gerenciada em nuvem como Salla ou Zid, você está fora do escopo desta falha específica, porque aplicar patches na plataforma não é responsabilidade sua. Mas a mesma lição vale para qualquer extensão ou integração de terceiros que você tenha ligado à sua loja: a responsabilidade pelos patches acompanha quem é dono do servidor.

Como lidamos com incidentes assim na Origami

O princípio sobre o qual construímos os sistemas dos clientes é que um incidente de segurança não é uma possibilidade remota, e sim um evento adiado. Na prática, isso significa três coisas: credenciais mantidas fora do código, em um cofre separado, para que trocá-las seja tarefa de minutos e não projeto de uma semana; logs operacionais armazenados fora do próprio servidor, para que um invasor não consiga apagar os próprios rastros; e backups que foram realmente testados por meio de restauração, e não apenas agendados.

E, se você tem uma loja Magento sem uma equipe técnica dedicada, a atitude certa hoje é simples: peça ao seu provedor de hospedagem ou parceiro técnico um relatório por escrito que responda apenas três perguntas — quando exatamente a correção foi instalada, o que a varredura de comprometimento encontrou e se as chaves foram trocadas. Essas três perguntas revelam mais sobre a prontidão de um parceiro técnico do que qualquer apresentação.

Fontes

  • Anúncio oficial da Adobe Commerce sobre a atualização de segurança APSB26-146 e o hotfix urgente: experienceleague.adobe.com
  • Análise técnica da Sansec sobre a CVE-2026-75650 e os indicadores de comprometimento: sansec.io/research/stylesmuggler-0day
  • Catálogo de vulnerabilidades exploradas conhecidas da CISA: cisa.gov
  • Lei de Proteção de Dados Pessoais (PDPL) — Autoridade Saudita de Dados e Inteligência Artificial (SDAIA): sdaia.gov.sa