Patch de segurança Magento agora é mensal: como adaptar sua operação

O patch de segurança Magento deixou de ser um evento trimestral. Em 2026, a Adobe publica correções de segurança todo mês, na segunda terça-feira (Patch Tuesday), em arquivos de patch isolados. Quem sustenta a loja com uma rotina desenhada para poucas janelas por ano passou a absorver um evento mensal com um processo que não foi feito para isso.

Este artigo explica como funciona o formato atual, usa o boletim de agosto de 2026 como exemplo, mostra o pré-requisito que penaliza quem está atrasado e lista o que revisar no contrato de sustentação, na homologação e na priorização.

Principais pontos

• A Adobe publica patches de segurança do Magento todo mês, na segunda terça-feira, e também fora do calendário quando uma vulnerabilidade crítica já está em exploração.
• O patch isolado corrige só as vulnerabilidades do boletim, mas só é testado contra a última versão de segurança da sua linha de release.
• Para aplicar o patch de um mês, é preciso ter aplicado todos os patches isolados anteriores da linha, na ordem de lançamento.
• Contar CVEs não mede urgência: leia severidade, vetor de exploração e exigência de autenticação, item por item.
• A pergunta certa não é com que frequência você aplica patch, e sim em quantos dias você consegue aplicar um.

Como funciona o patch de segurança Magento

A Adobe distribui as correções de segurança de duas formas. A primeira é o pacote de segurança completo (versões com sufixo, como 2.4.8-p5), que a documentação de lançamentos descreve com publicação anual em maio. A segunda é o patch isolado: um arquivo individual, que não é cumulativo por si só, publicado separadamente para encurtar o tempo até a correção. Os patches isolados são incorporados ao pacote de segurança seguinte.

Na prática, isso significa:

• Todo mês há um arquivo de patch para cada linha de release suportada (2.4.9, 2.4.8-pX, 2.4.7-pX e assim por diante).
• Os arquivos de patch isolado não são publicados como pacotes do Composer. Eles chegam como arquivos para aplicar sobre a instalação.
• Em lojas Adobe Commerce na nuvem, a correção também chega pelo pacote de patches da nuvem. Nesse caso, aplicar o arquivo isolado por cima pode causar falha de instalação, e a Adobe orienta a conferir isso antes.
• Para verificar o que está instalado, a Adobe recomenda a ferramenta Commerce Version Tool (php vendor/bin/patch-status), que informa os patches aplicados e os que faltam.

O boletim de agosto de 2026 como exemplo

Em 11 de agosto de 2026, a Adobe publicou o boletim APSB26-92 para o Adobe Commerce e o Magento Open Source, com correções classificadas como críticas e importantes. Segundo a análise da Sansec, são sete vulnerabilidades, cinco delas críticas. A Adobe informou não ter conhecimento de exploração ativa no momento da publicação.

A mais grave, segundo a Sansec, é a CVE-2026-71362, uma falha de autorização incorreta que permite a tomada de contas de clientes, com pontuação CVSS 9.1. A exploração não exige conta na loja, privilégio de administrador nem interação do usuário.

Em linguagem de operação: ninguém precisa ter conta, enganar alguém ou ter acesso privilegiado. Esse é o perfil de falha que varreduras automatizadas procuram em massa. Falhas anteriores do mesmo tipo mostram o padrão. Em setembro de 2025, a Adobe publicou o boletim APSB25-88 fora do calendário regular, para a falha CVE-2025-54236 (conhecida como SessionReaper), e a Sansec relatou centenas de tentativas de exploração em menos de 24 horas.

As versões afetadas pelo APSB26-92, segundo a Adobe, foram:

• 2.4.9
• 2.4.8-p5 e anteriores
• 2.4.7-p10 e anteriores
• 2.4.6-p15 e anteriores
• 2.4.5-p17 e anteriores
• 2.4.4-p18 e anteriores

No Magento Open Source, a Adobe disponibiliza os patches isolados apenas para a versão 2.4.6 ou posterior. Esse ponto liga o tema de patch ao ciclo de vida da versão, tratado na seção sobre suporte mais adiante.

O pré-requisito que penaliza o atraso

O patch isolado é o caminho mais rápido e de menor risco, porque reduz a superfície de regressão. Mas ele tem condições, e a Adobe as descreve no boletim de agosto de 2026:

1. A loja precisa estar na última versão de segurança (sufixo -p) da sua linha de release, porque as correções isoladas são testadas somente contra essa versão.
2. Todos os patches isolados mensais anteriores da linha precisam estar aplicados, na ordem de lançamento, porque cada um se apoia no anterior.

Quem está atrasado não tem acesso à via rápida. Precisa primeiro subir para a versão de segurança atual e só depois aplicar os patches isolados dos meses pendentes. Esse é um trabalho maior, com mais teste e mais janela. O atraso, portanto, não é só exposição acumulada: ele fecha a opção mais segura justamente quando a pressa é maior.

Como ler um boletim sem se enganar

Priorize pela leitura do conteúdo, e não pela quantidade de itens:

• Vetor de exploração: pela rede, sem autenticação, é urgência. Exige acesso ao admin ou interação do usuário, é prioridade menor, mas não ignorável.
• Autenticação e privilégio: veja o que a Adobe declara sobre conta e permissão necessárias.
• Estado de exploração: a Adobe informa se há conhecimento de exploração ativa. A ausência dessa informação no momento da publicação não significa gravidade baixa.
• Componentes afetados: confira se a falha atinge módulos que a sua loja usa, como B2B.

Priorize também pela prioridade que a Adobe atribui ao boletim. Uma prioridade 2 indica que a Adobe não identificou exploração ativa na publicação, e não que a falha é leve.

O que revisar no contrato de sustentação

Se o contrato nasceu no modelo trimestral, três pontos precisam de revisão.

Prazo contado a partir do boletim

Escreva em quantos dias a loja absorve um patch, contados da publicação do boletim, e não da abertura de um ticket. Se essa resposta não está escrita, ela não existe.

Responsável pelo monitoramento do boletim

Alguém precisa ser dono da leitura dos boletins da Adobe, com nome. Quando a responsabilidade é difusa, o patch é descoberto pelo cliente, e já é tarde.

Homologação viva

Cadência mensal só é sustentável com um ambiente em que a correção é testada contra o seu inventário real de extensões antes de ir para produção. Sem isso, cada patch é uma aposta, e a reação natural é adiar.

Fluxo prático para cada patch

1. Ler o boletim e identificar a linha e o sufixo de cada ambiente.
2. Conferir, com a Commerce Version Tool, se algum patch mensal anterior está pendente.
3. Se a loja não estiver na última versão de segurança da linha, planejar essa atualização primeiro.
4. Verificar a compatibilidade com extensões e integrações.
5. Aplicar e testar em homologação: checkout, pagamento, frete, login e as integrações críticas.
6. Promover para produção em janela combinada, com monitoramento nas horas seguintes.

Uma operação que ensaia esse fluxo todo mês leva o mesmo tempo para um patch rotineiro e para um patch urgente.

Suporte da versão e patch de segurança

Patch e ciclo de vida andam juntos. Segundo a página de ciclo de vida do Adobe Commerce, a versão 2.4.6 chegou ao fim do suporte padrão em 11 de agosto de 2026, e a 2.4.5 chegou ao fim do suporte estendido na mesma data. Confira a data da sua versão na página de lançamentos da Adobe e inclua a troca de versão no planejamento dos próximos meses. Veja também o nosso serviço de upgrade de Magento.

Como a Trezo pode ajudar

A Trezo trabalha só com Magento e Adobe Commerce desde 2009. Na Sustentação e Evolução, acompanhamos os boletins da Adobe, preparamos e testamos o patch em homologação e chegamos à conversa de produção com o trabalho pronto e uma recomendação, respeitando a janela combinada com cada cliente. Monitoramos as lojas dos nossos clientes 24 horas por dia, 7 dias por semana. Somos Adobe Solution Partner e AWS Partner, com certificação ISO 27001.

Se quiser saber em que versão a sua loja está e o que entra no plano dos próximos meses, fale com nossos especialistas.

Perguntas frequentes