No dia 7 de setembro, uma segunda-feira, a Adobe publicou fora do calendário um boletim de segurança que pouca gente esperava. O APSB26-146 corrige a CVE-2026-75650, uma falha de injeção no motor de templates com nota máxima de gravidade (CVSS 10.0), explorável sem autenticação e, segundo a própria Adobe, já usada em ataques reais contra lojas. Um dia depois veio o pacote mensal regular, o APSB26-138. Quem opera um zero-day no Magento aprendeu nessas 48 horas que aplicar o patch é só a primeira linha da resposta.
Este artigo trata do que vem depois. Porque a pergunta que um diretor de e-commerce deveria fazer ao seu time técnico em setembro não é “o patch foi aplicado?”, e sim “o que aconteceu entre o dia em que a falha começou a ser explorada e o dia em que fechamos a porta?”.
Principais pontos do artigo
- O APSB26-146 corrige uma falha crítica explorada ativamente, que permite executar código no servidor sem login.
- A própria Adobe recomenda rotacionar as chaves de criptografia e as credenciais associadas, não apenas aplicar a correção.
- Um zero-day no Magento exige investigação retroativa: o patch fecha a porta, mas não diz se alguém já entrou.
- O tempo entre a publicação do boletim e o aviso ao cliente é um indicador de maturidade da operação.
- Com a Black Friday a oito semanas, o incidente de setembro deve virar protocolo para os boletins de outubro e novembro.
O que o boletim de setembro realmente disse
Boletins de segurança costumam ser lidos pela nota de gravidade e arquivados. O APSB26-146 merece leitura completa por três detalhes que mudam a resposta.
O primeiro é a combinação de fatores. Uma falha de execução remota de código já é grave. Uma falha que dispensa autenticação é pior, porque qualquer visitante anônimo pode tentar explorá-la. E uma falha que a fabricante confirma estar sendo explorada “in the wild” deixa de ser risco teórico. Os três juntos colocam o incidente no topo da escala de prioridade.
O segundo detalhe é a recomendação adicional. A Adobe orienta, além da correção, a rotação das chaves de criptografia e das credenciais associadas como parte da remediação. Essa frase é o reconhecimento implícito de que uma loja pode ter sido comprometida antes de receber o patch. Rotacionar chave é o que se faz quando não dá para garantir que o segredo continua secreto.
O terceiro é o calendário. O boletim saiu na segunda-feira, fora da cadência mensal que a Adobe adotou em 2026, e o pacote regular chegou no dia seguinte. E aqui está uma armadilha: a correção da CVE-2026-75650 é um hotfix à parte, que a Adobe orienta aplicar junto com o pacote isolado de setembro. Quem aplicou apenas o pacote regular de terça-feira, confiando no calendário, continuou exposto. Voltaremos ao tema do calendário no fim do texto.
Por que o patch sozinho não encerra o incidente
Um patch fecha a vulnerabilidade daqui para frente. Ele não desfaz nada do que aconteceu antes de ser aplicado. Se a falha estava sendo explorada e a sua loja ficou exposta por dias, a pergunta honesta é se alguém usou esse intervalo.
Em falhas de execução remota, o padrão de ataque mais comum no ecossistema Magento não é derrubar a loja. É ficar dentro dela sem ser notado. Os objetivos típicos são três: instalar um skimmer que copia dados de cartão no checkout, criar um usuário administrativo discreto para acesso posterior e extrair a chave de criptografia do arquivo de configuração, o que permite ler dados cifrados no banco.
Nenhuma dessas ações quebra a experiência do cliente. A loja continua vendendo, o painel continua verde e o incidente só aparece semanas depois, quando uma bandeira de cartão aponta a sua loja como ponto comum de fraude. Por isso a resposta a um zero-day no Magento tem uma parte que olha para trás.
O que fazer além de aplicar o patch
Na nossa experiência com operações de eletrônicos, beleza, farma e autopeças, a resposta completa tem cinco frentes. Elas não dependem do tamanho da loja, dependem de disciplina.
1. Rotacionar a chave de criptografia com método
O Magento guarda a chave no arquivo de configuração do ambiente e a usa para cifrar dados sensíveis no banco, como credenciais de integrações e tokens de meios de pagamento. A rotação pode ser feita pelo painel administrativo ou por linha de comando, mas não é um clique inocente: dados cifrados com a chave antiga precisam ser recifrados, e integrações que dependem de valores armazenados precisam ser testadas depois. Faça em homologação primeiro, com cópia recente do banco, e só então em produção.
2. Trocar as credenciais que a chave protegia
Se a chave pode ter vazado, tudo o que ela protegia também pode. Isso inclui chaves de API de gateway, antifraude, ERP, transportadoras e ferramentas de marketing. Gere credenciais novas nos painéis dos fornecedores, atualize a loja e revogue as antigas. Parece burocracia, e é, mas é a burocracia que evita o segundo incidente.
3. Auditar usuários administrativos e integrações
Liste todos os usuários do painel, com data de criação e último acesso. Qualquer conta criada no período de exposição sem justificativa clara é suspeita. Faça o mesmo com as integrações e tokens de API. Aproveite para confirmar que a autenticação em dois fatores está ativa para todos os administradores.
4. Procurar sinais de alteração no código e no banco
Compare os arquivos do ambiente de produção com o repositório versionado. Arquivos novos ou alterados fora do pipeline de deploy precisam de explicação. No banco, revise blocos de conteúdo, configurações de cabeçalho e rodapé e scripts incluídos por painel, que são locais clássicos para esconder skimmers. Revise também os logs do servidor web no intervalo entre a divulgação da falha e a aplicação do patch.
5. Registrar tudo e comunicar
Um incidente bem tratado termina com um documento curto: quando o boletim saiu, quando a loja foi corrigida, o que foi verificado, o que foi encontrado e o que foi trocado. Esse registro é útil para o seu time, para o jurídico em caso de questionamento sob a LGPD e para a próxima vez, que vai acontecer.
Quem avisou quem primeiro
Existe um teste simples para medir a maturidade de uma operação de e-commerce diante de um boletim crítico. Pergunte ao diretor da loja como ele soube do APSB26-146. Há três respostas possíveis.
Na primeira, ele soube pela agência ou pelo time técnico, no mesmo dia, com uma mensagem que dizia o que era, se a loja estava exposta e o que seria feito. Na segunda, ele soube por um grupo de mensagens, por um portal de notícias ou por um fornecedor, e foi ele quem perguntou ao time. E na terceira, ele está sabendo agora, lendo este texto.
A correção técnica pode ter sido a mesma nos três casos. A diferença está em quem carregou a preocupação. Numa operação madura, o diretor não precisa monitorar boletins de segurança; ele precisa ser informado de que alguém está monitorando. É por isso que tratamos o aviso proativo como parte do serviço, e não como cortesia. O intervalo entre a publicação do boletim e a primeira comunicação ao cliente é uma métrica que vale a pena acompanhar, tanto quanto o tempo de aplicação do patch.
O que setembro ensina para outubro e novembro
A Adobe publica correções mensais para o Magento, e o próximo pacote regular está previsto para a segunda terça de outubro, dia 13. O de novembro deve cair no dia 10, dezessete dias antes da Black Friday. Como mostramos no nosso cronograma reverso para a Black Friday 2026, há uma chance real de um boletim relevante chegar dentro da janela de congelamento de código.
O incidente de setembro é o ensaio perfeito para essa decisão. Três perguntas deveriam estar respondidas antes de outubro:
- Critério de severidade: que tipo de falha justifica romper o congelamento? Nossa recomendação é clara: falha explorável sem autenticação e com exploração ativa confirmada entra em qualquer janela, com teste em horário de baixo tráfego.
- Janela de emergência: quem aprova um deploy fora do calendário e em quanto tempo? Se a resposta exige três reuniões, a janela não existe.
- Ambiente de homologação atualizado: um patch emergencial só é seguro se puder ser testado em um ambiente que espelha a produção. Homologação desatualizada transforma correção em aposta.
Lojas que ainda rodam versões fora do suporte têm um problema adicional. A linha 2.4.6 saiu do suporte regular em 11 de agosto de 2026, então correções para falhas descobertas depois dessa data não chegam pelo caminho normal. Para essas operações, cada boletim novo aumenta a distância entre a loja e uma versão protegida.
Como a Trezo trata esse cenário
A Trezo acompanha os boletins de segurança da Adobe desde o momento da publicação e comunica os clientes antes que eles precisem perguntar. Em setembro, o protocolo incluiu avaliação de exposição por versão, aplicação do hotfix em homologação e produção, rotação de chaves e credenciais e revisão de usuários administrativos. Operamos com infraestrutura gerenciada na AWS e certificação ISO 27001, o que significa processos de segurança documentados e auditados, não improvisados na hora do incidente.
Se a sua operação não sabe dizer hoje se a loja ficou exposta ao APSB26-146, ou se ninguém avisou você quando ele saiu, vale uma conversa. Fale com nossos especialistas.
Perguntas frequentes
Sim. O boletim cobre o Adobe Commerce e o Magento Open Source, incluindo versões anteriores, para as quais a Adobe publicou hotfix específico. A recomendação é aplicar o hotfix da CVE-2026-75650 junto com o pacote isolado de setembro (APSB26-138).
A Adobe recomenda a rotação como parte da remediação. Como a falha era explorada ativamente e não deixava rastros óbvios, a ausência de sinais não garante que a loja não foi acessada. A rotação é a medida que protege o que pode ter sido copiado.
A aplicação do patch costuma levar horas. A resposta completa, com rotação de chaves, troca de credenciais, auditoria de usuários e revisão de código, leva de um a três dias em uma operação organizada. O que mais atrasa é a falta de homologação atualizada e de inventário das integrações.
