Zero-day no Adobe Commerce: aplicar o patch em horas, não em semanas

A 4 de setembro de 2026, atacantes começaram a explorar uma falha do Adobe Commerce que ninguém conhecia ainda. A correção de emergência chegou no dia 7; o boletim mensal do dia 8 acrescentou oito vulnerabilidades críticas. Um mês depois, o episódio merece uma releitura a frio — menos pelos números dos CVE do que pelo que revela sobre a sua organização: o intervalo entre a publicação de uma correção e a sua aplicação tornou-se uma métrica de sobrevivência.

Três dias de avanço para os atacantes

Primeiro, a cronologia. A campanha, batizada StyleSmuggler pela Sansec, arrancou a 4 de setembro: vários grupos instalavam já portas traseiras e webshells abusando de uma injeção no motor de modelos, acionada através de um e-mail transacional padrão — o lembrete de falha de pagamento — sem qualquer ação da vítima (o relato da SecurityWeek). A Adobe reagiu a 7 de setembro com uma correção fora de ciclo, o boletim APSB26-146: a falha CVE-2026-75650 apresenta a pontuação CVSS máxima de 10,0 e permite execução remota de código sem autenticação. São afetados o Adobe Commerce 2.4.4 a 2.4.9, o Magento Open Source 2.4.6 a 2.4.9 e a extensão B2B 1.3.3 a 1.5.3 — ou seja, praticamente todo o parque instalado, mesmo atualizado até agosto.

No dia seguinte, o boletim mensal APSB26-138 corrigia mais oito falhas, todas classificadas como críticas: dois XSS armazenados com nota 9,3, cinco defeitos de autorização, uma travessia de diretórios. Seis das oito exploram-se sem qualquer conta.

A armadilha das duas correções

Um pormenor operacional conta: a correção de emergência não faz parte do comboio mensal. A Adobe indica que se instala separadamente — aplicar o nível de setembro sem o hotfix deixa aberta a única falha ativamente explorada, e o hotfix sozinho não cobre as outras oito. Desde 2026, as correções agrupadas saem todos os meses e passaram a ser nomeadas pela data (2.4.9-2026-sep, por exemplo) em vez de números p. É mais legível, mas pressupõe que alguém — na sua equipa ou no seu integrador — leia realmente os boletins e saiba distinguir um hotfix prioritário de um prazo de rotina.

A janela fechou-se

Mesma estação, no ano passado: SessionReaper (CVE-2025-54236), corrigida a 9 de setembro de 2025. Os primeiros ataques em massa esperaram seis semanas; nessa altura, apenas 38% das lojas estavam atualizadas, e as vagas automatizadas acabaram por visar mais de uma loja em cada duas no mundo, segundo os números publicados então pela Sansec. Em 2026, o guião inverteu-se: a exploração antecedeu a correção em três dias. A conclusão é dura mas simples — «aplicamos o patch no próximo sprint» já não é uma política de segurança, é uma aposta contra adversários automatizados.

O que isto exige à sua organização

Três consequências muito concretas, vistas da cadeira do arquiteto:

• Um SLA de correções por escrito. Hotfix ativamente explorado: aplicação em horas. Boletim crítico: em dias. Nomeie quem lê os boletins, quem decide, quem aplica, quem verifica — uma correção sem responsável designado espera sempre.
• Uma arquitetura que torna o patch barato. Ambiente de testes fiel à produção, testes automatizados dos percursos de compra, implantação repetível e sem interrupção. O verdadeiro custo de uma correção é o medo de partir alguma coisa; esse medo constrói-se — ou desmonta-se — na arquitetura.
• O suficiente para aguentar as primeiras horas. Uma firewall aplicacional à frente do admin e das API, monitorização de integridade dos ficheiros, revisão regular das contas de administrador. E depois de um zero-day explorado, aplicar o patch não chega: procure vestígios de uma visita anterior à correção — webshells, contas desconhecidas, tarefas agendadas, módulos modificados.

A checklist de outubro

• Registe o nível de patch exato de cada ambiente, extensão B2B incluída: se for anterior a setembro de 2026, está exposto.
• Confirme que o hotfix CVE-2026-75650 está aplicado em todo o lado — produção, pré-produção, ambientes de demonstração acessíveis pela internet.
• Mande inspecionar qualquer loja que tenha ficado vulnerável depois de 4 de setembro como se tivesse sido visitada: a exploração começou antes de a correção existir.
• Escreva o SLA e cronometre a equipa no comboio de outubro: é o exercício em condições reais mais barato do mercado.

Um boletim de segurança é, no fundo, um teste gratuito à sua cadeia de entrega. As organizações que aplicam uma correção em poucas horas têm uma arquitetura e uma governação saudáveis; as que demoram semanas descobrem, num setembro qualquer, que a dívida técnica também se paga em incidentes de segurança.