Em 11 de agosto de 2026, a Adobe encerrou o suporte regular das linhas 2.4.5 e 2.4.6 do Magento. A data passou praticamente sem repercussão no mercado brasileiro, e é justamente esse silêncio que chama atenção: boa parte das operações que atravessou esse marco não sabe que atravessou.
Nada parou de funcionar naquele dia. Nenhuma loja saiu do ar, nenhum checkout travou, nenhum alerta apareceu no painel administrativo. O que mudou foi mais silencioso e, dependendo da sua edição, definitivo: vulnerabilidades descobertas a partir de agora nessas versões não recebem correção oficial.
Principais pontos do artigo
- O suporte regular das linhas 2.4.5 e 2.4.6 terminou em 11 de agosto de 2026.
- Existe uma assimetria decisiva entre as duas edições da plataforma, e quase toda a cobertura publicada até agora embaralha isso.
- O boletim de segurança publicado pela Adobe na mesma data torna essa separação visível na prática.
- A primeira providência não é contratar um upgrade. É confirmar edição e versão exata, com sufixo de patch.
- Nossa recomendação de rota é usar a 2.4.8 como degrau, não migrar direto para a 2.4.9.
A assimetria que quase toda a cobertura embaralha
O fim do suporte Magento 2.4.6 não significa a mesma coisa para todo mundo, e essa é a informação que mais falta nos textos que circularam nas últimas semanas.
Quem opera sob licença comercial ganhou prazo adicional. A política de ciclo de vida da Adobe prevê um ano de suporte extra sem custo adicional para clientes da edição paga nas versões 2.4.6 e 2.4.7, cobrindo correções de qualidade e de segurança, seguido de um período transitório apenas com segurança. Na prática, quem está nessa condição tem espaço até 2027 para planejar.
Quem roda a edição comunitária não ganhou nada. O suporte estendido é benefício contratual da edição paga e não se aplica ao código-base do Magento Open Source. Para essas lojas, 11 de agosto de 2026 foi parede, não rampa.
Essa distinção importa porque determina se você tem um ano de planejamento ou se está operando sem rede desde a semana passada. E a nossa experiência é que muita gente responde essa pergunta errado. Já entramos em ambientes onde a liderança acreditava ter cobertura contratual e não tinha, e em ambientes onde a preocupação era desnecessária porque a cobertura existia.
O boletim de agosto deixou a separação visível
Em 11 de agosto de 2026, no mesmo dia em que o suporte terminou, a Adobe publicou o boletim APSB26-92, classificado como prioridade 2. Ele corrige sete vulnerabilidades, cinco delas críticas, com impacto de escalação de privilégio, bypass de mecanismo de segurança e execução arbitrária de código.
O detalhe relevante está nas tabelas de versões. A edição comercial aparece com as linhas 2.4.4 e 2.4.5 entre as versões afetadas e entre as versões corrigidas. A edição comunitária, não: a lista começa na 2.4.6 e vai até a 2.4.9. A mesma assimetria de suporte que existe em política de ciclo de vida agora está registrada, linha por linha, em documento técnico de segurança.
Vale registrar o que isso implica para quem está na 2.4.6 comunitária: a versão recebeu o patch de agosto no mesmo dia em que perdeu o suporte regular. Não existe declaração da Adobe afirmando que esse foi o último, e não vamos afirmar por ela. Mas a leitura razoável, olhando o calendário de releases, é que a próxima vulnerabilidade descoberta nessa linha não terá correção oficial.
O que verificar antes de discutir upgrade
A conversa sobre migração costuma começar antes da conversa sobre diagnóstico, e isso produz orçamento errado. Quatro verificações vêm primeiro.
Sua edição. Licença comercial ou edição comunitária. Não confie na memória de como a loja foi construída: edição e versão mudam ao longo da vida de um projeto, e a resposta define se você tem doze meses ou zero.
Sua versão exata, com sufixo. Não basta saber que é 2.4.6. Precisa saber se é 2.4.6-p13, 2.4.6-p15 ou 2.4.6-2026-aug. O sufixo determina quais correções já estão aplicadas e se você tem acesso ao formato de patch isolado, que exige estar na última versão de segurança da linha.
Todos os patches ainda disponíveis para você. Antes de qualquer projeto de upgrade, esgote o que ainda pode ser aplicado na versão atual. É a única ação que reduz exposição em dias, não em meses.
O volume real de customização. O upgrade do core raramente é o gargalo. O prazo é definido pelo volume de código customizado, pela quantidade de extensões de terceiros que precisam de compatibilização e pela profundidade das integrações com ERP e PIM. Uma loja com pouca customização se move em seis a oito semanas. Uma implementação B2B com integração fiscal e de retaguarda profunda leva de quatro a seis meses, incluindo teste.
Por que recomendamos a 2.4.8 como degrau
A 2.4.9 está disponível desde 12 de maio de 2026 e já recebeu três rodadas de patch de segurança. Ainda assim, não é para onde recomendamos ir direto.
Ela é a atualização mais significativa em arquitetura desde a 2.0. Três componentes fundacionais do framework foram substituídos: o Laminas MVC por implementação nativa, o TinyMCE pelo HugeRTE e o Zend_Cache pelo componente de cache do Symfony. Junto disso, a pilha suportada avançou para PHP 8.5, OpenSearch 3 e Valkey.
Traduzindo para termos de projeto: subir para a 2.4.9 é reconstrução de servidor tanto quanto mudança de código. Quem estima esse trabalho como upgrade de versão vai errar prazo, errar orçamento e queimar credibilidade interna no meio do caminho.
A 2.4.8 tem suporte regular até abril de 2028. Ela resolve o problema de exposição agora, com risco de compatibilidade muito menor, e compra tempo para tratar a 2.4.9 como o que ela é: um projeto de infraestrutura com janela própria, teste de extensão e ambiente de homologação. Fazer as duas coisas no mesmo trimestre, com a pressão de uma EOL já vencida, é a receita para transformar um projeto normal em incidente.
Esperar não postergou o trabalho, mudou o momento dele
O argumento mais comum para adiar é orçamentário, e ele é legítimo. O que costuma ficar de fora da conta é que adiar não elimina o trabalho, apenas garante que ele aconteça em condição pior.
Um upgrade planejado, com escopo definido e janela negociada, é projeto. O mesmo upgrade feito às pressas, porque uma auditoria de conformidade apontou versão sem suporte ou porque um incidente de segurança forçou a mão, é operação de emergência. O escopo técnico é idêntico. O custo, a exposição e o desgaste interno não são.
Há também um efeito de ecossistema que aparece devagar. Fornecedores de extensão passam a testar contra versões novas e param de testar contra a sua. Cada decisão futura de integração começa a ser tomada em torno de uma plataforma que não se move mais. Sua postura de conformidade com PCI vai derivando sem que ninguém tome uma decisão explícita a respeito.
Como a Trezo trata esse cenário
A Trezo trabalha exclusivamente com Magento há mais de 16 anos, em operações de médio e grande porte nos setores de eletrônicos, beleza, farma, alimentos, agronegócio e autopeças. Somos parceiros AWS Partner Network e certificados ISO 27001, o que significa que infraestrutura e tratamento de dados seguem processo auditado, não improviso.
Se você não tem clareza sobre em qual versão sua loja está, quanto tempo de cobertura ainda existe ou o que precisa entrar no roadmap dos próximos noventa dias, essa conversa vale meia hora. Fale com nossos especialistas.
Perguntas frequentes
Não. A loja continua operando normalmente. O que cessa é o fornecimento de correções oficiais para vulnerabilidades descobertas a partir da data. O risco é cumulativo e cresce com o tempo, não instantâneo.
Provavelmente não, mas isso depende do seu contrato. A política de ciclo de vida do Adobe Commerce prevê suporte adicional para as linhas 2.4.6 e 2.4.7. Como entitlements variam por contrato e já foram ajustados ao longo do tempo, confirme sua cobertura específica com a Adobe ou com seu parceiro de implementação, em vez de se apoiar em orientação genérica.
Faz sentido em casos específicos, principalmente quando a operação já vai passar por reconstrução de infraestrutura por outro motivo e o inventário de extensões é enxuto. Fora disso, a 2.4.8 reduz exposição mais rápido e com muito menos risco de regressão. A decisão depende do diagnóstico da sua base de código, não de preferência por versão mais nova.
