Boletim de segurança da Adobe para o Magento: aplicar hoje ou esperar a janela?

APSB do Magento: o que fazer primeiro é ler cinco campos

Os boletins de segurança da Adobe têm código no formato APSB seguido de ano e número, e costumam seguir a mesma estrutura. Para decidir o prazo, você não precisa entender a falha. Precisa achar cinco campos:

• Priority, no topo do boletim: 1, 2 ou 3.
• Summary: o resumo. Quando há ataque em andamento, é ali que a Adobe escreve que tem conhecimento de exploração (exploited in the wild).
• Affected Versions: a tabela de versões afetadas, separada por produto (Adobe Commerce, Adobe Commerce B2B e Magento Open Source), com linhas no formato 2.4.8-p2 and earlier.
• Authentication required to exploit? e Exploit requires admin privileges?, na tabela de detalhes: dizem se o atacante precisa de login e se precisa ser administrador.
• Solution: o que a Adobe entrega para corrigir, seja hotfix, patch ou versão nova.

A nota CVSS e a categoria técnica ajudam o desenvolvedor, mas não mudam a decisão do gestor tanto quanto esses cinco campos.

Patch de segurança do Magento é urgente? A matriz de decisão

A escala de prioridade é da própria Adobe e leva em conta o histórico de ataques ao produto, o tipo de falha e as mitigações existentes. Pela definição publicada, prioridade 1 corrige falhas atacadas ou com risco maior de ataque, e a recomendação é instalar o quanto antes, por exemplo em até 72 horas. Prioridade 2 é produto com risco histórico elevado, sem exploração conhecida, e a recomendação é instalar em breve, por exemplo em até 30 dias. Prioridade 3 fica a critério do administrador.

Em cima dessa escala, eu aplico a matriz abaixo. Ela é a regra que eu uso, não uma norma da Adobe:

O quinto campo, Solution, não muda a urgência. Muda o esforço para cumprir o prazo, e é o assunto da seção seguinte.

Como saber se a minha versão do Magento está vulnerável

A versão aparece no canto inferior direito de qualquer página do admin. Com acesso ao servidor, o comando é bin/magento --version, que devolve algo como Magento CLI 2.4.8-p4. Compare com a tabela de versões afetadas lendo a linha do seu produto e da sua linha de versão: se o boletim diz 2.4.8-p5 and earlier, a 2.4.8-p4 está afetada.

Três armadilhas na comparação:

• Edição errada. Adobe Commerce, B2B e Magento Open Source têm linhas separadas. Loja Adobe Commerce com B2B precisa conferir as duas, e as notas de patch da Adobe lembram que quem usa B2B também precisa atualizar o patch de segurança do B2B.
• Versão sem suporte. Se a sua linha aparece como afetada e já saiu do suporte, pode não haver correção para ela. No Magento Open Source isso pesa mais: pela política da Adobe, os patches de segurança do suporte estendido são só para clientes Adobe Commerce.
• "Estou na última versão". Estar no último -p não livra do boletim mais novo, porque o boletim costuma sair justamente para as versões atuais.

Se a sua versão não tem mais correção, o assunto deixa de ser patch e passa a ser atualização. O checklist para atualizar o Magento para a 2.4.9 é o ponto de partida.

Hotfix, patch isolado ou versão -p: o que muda no esforço

A política de ciclo de vida e a política de versões da Adobe definem três formas de correção de segurança:

• Hotfix de segurança do Adobe Commerce: para falhas críticas, como as de dia zero. Sai para todos os clientes em versão suportada, mesmo que não estejam no último patch. A Adobe avisa que ele não é completo e não resolve tudo que a atualização resolveria.
• Patch de segurança isolado: arquivo avulso e não cumulativo, com correção só de segurança. Para aplicar, a loja precisa estar na última versão -p da sua linha, porque é contra ela que o patch foi testado.
• Versão de patch de segurança (-pN): cumulativa, baseada na versão anterior. Pode trazer mudanças de conformidade que quebram compatibilidade, então pede homologação de verdade.

Um caso real: em setembro de 2025 a Adobe liberou um hotfix para a CVE-2025-54236, do boletim APSB25-88, e a correção entrou depois na 2.4.8-p3. A sequência que ele ilustra: hotfix primeiro, para fechar a falha rápido, e a versão -p depois, numa janela planejada.

A armadilha mais cara está no patch isolado: loja atrasada no -p não consegue aplicá-lo sem antes atualizar a versão, e aí um prazo de 72 horas vira projeto. O guia de upgrade da Adobe lembra ainda que, para manter a conformidade com o PCI, a loja precisa estar no último patch ou patch de segurança.

O que combinar com o fornecedor antes do próximo boletim

A decisão fica fácil quando estas respostas já existem antes do boletim sair:

1. Quem acompanha os boletins e avisa você quando sai um novo?
2. A loja está no último -p da linha? Se não, qual é o plano para chegar lá?
3. Existe homologação atualizada para testar um patch no mesmo dia?
4. Existe backup recente e testado antes de aplicar?
5. Quem autoriza aplicar fora da janela de manutenção?
6. Qual é o roteiro mínimo de teste depois do patch: busca, carrinho, checkout, pagamento e e-mail de pedido?

Se alguma resposta for "não sei", resolva isso agora, com calma, e não no dia de um boletim de prioridade 1. É o tipo de rotina que entra no suporte mensal; os prazos de cada versão estão em versões e prazos de suporte do Magento 2.