O Magento 2.4.6 perdeu o suporte há um mês. Nada avariou — e esse é o problema.

A 11 de agosto de 2026, a Adobe deixou de lançar patches de segurança para o Magento 2.4.5 e 2.4.6.

Se tens uma loja em qualquer uma destas versões, eis o que aconteceu nesse dia: nada. O site arrancou. As encomendas entraram. O checkout funcionou. O painel de administração carregou exatamente como na semana anterior. Não apareceu nenhum banner, não chegou nenhum email, e nada na aplicação avisou ninguém de que as regras tinham mudado.

Essa é a armadilha, e vale a pena ser preciso sobre o porquê.

O que parou de facto

O fim do suporte não desativa o software. O que acaba é o fluxo de correções que chega até ti.

Antes dessa data, quando um investigador divulgava uma vulnerabilidade no Magento, seguia-se um patch. Aplicava-lo, e a janela entre a divulgação e a exposição media-se em dias. Depois dessa data, para essas duas versões, a divulgação continua a acontecer — o patch não. Cada CVE registado contra a 2.4.5 ou a 2.4.6 a partir de agora fica permanentemente em aberto, seja qual for a severidade.

Há um segundo pormenor que apanha desprevenido quem corre especificamente o Magento Open Source. Os clientes do Adobe Commerce tiveram historicamente acesso a acordos de suporte alargado. O Open Source não tem esse escalão. Não há nada para comprar, nenhuma extensão paga para negociar, nenhum account manager enterprise a quem ligar. O fim do suporte regular é, simplesmente, o fim.

E se estás na 2.4.5, a situação é anterior ao mês passado: essa linha saiu do suporte standard em agosto de 2025. Os comerciantes que leram "2.4.5 e 2.4.6" como um único evento de 2026 estão, no caso da 2.4.5, há um ano a funcionar sem patches.

A assimetria que torna isto caro

Uma loja a funcionar tem exatamente o mesmo aspeto, com ou sem patches. Essa simetria é o que torna o risco difícil de sentir e fácil de adiar.

A assimetria está do lado do atacante, e corre num só sentido:

• A divulgação é pública. As bases de dados de vulnerabilidades, os avisos e as release notes são públicos. O mesmo documento que diz a quem defende o que corrigir diz a quem ataca o que procurar.
• Detetar a versão é trivial. As instalações Magento podem ser identificadas em massa a partir do exterior. Ninguém precisa de adivinhar que lojas estão em que versão; isso pode ser enumerado.
• O patch é o mapa. Quando sai uma correção para uma versão suportada, o diff descreve a vulnerabilidade com precisão. Os atacantes leem os patches das linhas suportadas e aplicam esse conhecimento às não suportadas, onde o mesmo código continua a correr e nenhuma correção vai chegar.
• A distância só aumenta. A janela de exposição de uma loja suportada fecha-se sempre que aplica patches. A de uma loja sem suporte não tem qualquer mecanismo de fecho. Cada mês acrescenta e nada subtrai.

É por isso que "ainda não tivemos nenhum problema" é uma afirmação sobre os últimos doze meses e não uma previsão. O que mudou em agosto não foi a probabilidade de um dado ataque ter sucesso — foi o remédio ter deixado de existir.

O PCI DSS transforma uma questão de segurança numa questão de conformidade

Se a tua loja aceita pagamentos com cartão, a discussão deixa de ser sobre apetite ao risco e passa a ser sobre uma norma com que já te comprometeste.

O PCI DSS exige que os sistemas no âmbito tenham os patches de segurança em dia. Não é uma aspiração vaga da norma — a gestão de patches é um requisito explícito, e uma plataforma sem suporte é o exemplo de manual de não o conseguir cumprir. Não podes aplicar um patch que não existe, e "o fornecedor já não o publica" não é um controlo compensatório aceite. É precisamente a razão pela qual um controlo compensatório seria exigido.

Daí decorrem algumas coisas que os comerciantes costumam perceber mal:

• Ser SAQ A não esvazia o teu âmbito. Passar os campos do cartão para um iframe alojado ou para o JavaScript de um fornecedor de pagamentos reduz aquilo que manipulas, mas a página que carrega esse script continua a ser tua. Se a plataforma que a serve for comprometida, o script pode ser trocado. É exatamente esse o mecanismo por trás de anos de incidentes de skimming digital, e é por isso que a norma agora presta atenção à integridade da própria página de pagamento.
• "Passou no scan" diz menos do que parece. Um scan ASV reporta o que deteta. Não é uma declaração de que a tua plataforma é suportada, e um scan limpo numa versão sem suporte descreve a cobertura do scanner, não a tua posição.
• A pergunta chega no pior momento. Ninguém pergunta em que versão estás enquanto tudo está calmo. A pergunta surge durante uma avaliação, durante a revisão de um fornecedor de pagamentos ou depois de um incidente — três momentos em que a resposta honesta sai cara.

Há também uma dimensão de seguros que vale a pena verificar antes de precisares dela. As apólices de ciber-risco perguntam cada vez mais sobre práticas de aplicação de patches, e correr software que o fornecedor deixou publicamente de suportar é o tipo de pormenor que vem à tona durante uma participação de sinistro e não durante a subscrição.

Porque é que esperar custa mais do que avançar

Quando o orçamento está apertado, o instinto é adiar um ano. Nas atualizações de plataforma, adiar não é neutro — a fatura cresce enquanto esperas, por razões que nada têm a ver com a inflação.

O custo de uma atualização é determinado pela distância, não pelo número da versão atual. Cada release que saltas acrescenta alterações de esquema, APIs descontinuadas e requisitos de PHP que as tuas extensões têm de atravessar de uma só vez em vez de por etapas. Uma loja com uma versão de atraso é um projeto. Uma loja com quatro versões de atraso é um exercício de arqueologia, porque as pessoas que escreveram as personalizações muitas vezes já saíram e as extensões de que dependiam podem já não ter equivalentes mantidos.

Há um segundo custo, mais silencioso. Os fornecedores de extensões de terceiros seguem o calendário de suporte da Adobe. Quando uma versão sai do suporte, os fornecedores que a servem acabam por deixar de testar contra ela também. Quanto mais tempo ficares numa linha sem suporte, maior parte do teu parque de extensões passa a estar genuinamente sem suporte, e não apenas desatualizada — e a substituição, não a atualização, torna-se o único caminho.

A versão que corres também impõe um mínimo à tua versão de PHP, que por sua vez impõe um mínimo a tudo o resto do stack. Adiar a atualização do Magento adia as decisões de PHP, pesquisa e cache que estão por trás dela, e essas têm os seus próprios calendários de fim de vida, que não esperam pelo teu.

A matriz de extensões é o que transforma um intervalo numa data

Pergunta a três agências quanto tempo demora uma atualização de Magento e vais obter três intervalos, todos largos. Não é uma forma de fugir à pergunta. É o reflexo honesto de que a variável não é o Magento.

O caminho de atualização do próprio Magento é razoavelmente conhecido. O que distingue um projeto de seis semanas de um de seis meses é o que está por cima: extensões de terceiros, módulos à medida, overrides do tema e integrações com o ERP, o WMS ou o sistema de contabilidade que alguém construiu à pressa há três anos.

O artefacto que transforma essa incerteza num plano é uma matriz de compatibilidade de extensões — uma linha por cada extensão e módulo à medida e, para cada um, a resposta a quatro perguntas:

1. 1Existe uma versão compatível com a release de destino? Se sim, é uma subida de versão e um teste de regressão.
2. 2O fornecedor ainda a mantém? Uma data de lançamento recente importa mais do que o número da versão atual. Uma extensão atualizada pela última vez em 2023 é um passivo, mesmo que hoje funcione.
3. 3Ainda faz alguma coisa de que o negócio precisa? Os parques de extensões acumulam-se. É comum encontrar extensões que já não servem para nada, e apagar uma é mais rápido e mais barato do que migrá-la.
4. 4Se nada disto se aplicar, o que a substitui? Há funcionalidades que têm de ser reconstruídas, e sabê-lo na primeira semana é muito diferente de o descobrir na nona.

Constrói essa matriz antes de escrever qualquer código. É a diferença entre um projeto com âmbito definido e um projeto sem fim à vista, e é a coisa mais útil que podes produzir, mesmo que não comeces a atualização de imediato. Um dono de loja que tem a matriz pode tomar uma decisão informada sobre o momento. Um que não a tem está a escolher entre opções sem preço.

A outra disciplina em que vale a pena insistir é o ensaio. A atualização deve correr de ponta a ponta num clone de produção antes de correr em produção. Cada surpresa desagradável — um módulo que não instala, um conflito de esquema, uma regressão do tema no checkout — é bastante mais barata na primeira vez que acontece numa máquina onde ninguém está a comprar.

Isto não é, na verdade, um problema do Magento

O modo de falha aqui não é exclusivo do Magento, e reconhecê-lo é útil porque te diz onde mais procurar.

Escrevemos recentemente sobre porque é que os sites WordPress continuam a ser comprometidos através do seu ecossistema de plugins, e a observação central desse artigo aplica-se na perfeição: o software que deixa de ser mantido não o anuncia. Continua a funcionar perfeitamente, e é precisamente esse o problema. Nada no site parece errado até ser divulgada uma vulnerabilidade e não haver nenhum patch a caminho.

Um plugin de WordPress abandonado pelo autor e uma versão do Magento abandonada pelo fornecedor são o mesmo evento a escalas diferentes. Em ambos os casos o software continua a funcionar, o risco acumula-se de forma invisível e o momento da descoberta é escolhido por outra pessoa que não tu.

A defesa é a mesma nos dois casos, e não tem nada de glamoroso: conhece bem o que tens a correr, confirma se cada peça continua a ser mantida e trata "continua a receber atualizações de segurança" como uma propriedade que verificas ativamente em vez de a dares como garantida.

O que fazer este mês

Se estás na 2.4.5 ou na 2.4.6, os próximos passos úteis são pequenos e quase todos gratuitos:

• Confirma a tua versão e o nível de patches exatos. Não o que diz a documentação do último projeto — o que o sistema reporta hoje. É mais comum do que devia uma loja estar uma patch release atrás de onde toda a gente julga que está.
• Faz o inventário das extensões e de quando cada uma foi atualizada pela última vez. É a matéria-prima da matriz, e pode ser produzida numa tarde.
• Decide a release de destino de forma deliberada. As linhas suportadas têm horizontes diferentes e requisitos de PHP diferentes, e a resposta certa depende do teu parque de extensões e não de qual é o número mais alto. Vale a pena ser explícito sobre se estás a comprar dois anos de margem ou quatro.
• Verifica o que dizem realmente o teu fornecedor de pagamentos e a tua documentação PCI. Mais vale seres tu a encontrar o requisito do que alguém encontrá-lo por ti.
• Regista a decisão por escrito, incluindo uma decisão de esperar. Se a resposta for "este trimestre não", é uma decisão de negócio legítima — mas deve ficar registada e com uma data associada, e não ser um adiamento que discretamente se torna permanente.

Em resumo

Nada avariou a 11 de agosto. Amanhã também nada vai avariar, e é essa toda a dificuldade: o custo desta decisão é invisível até deixar de o ser, e nessa altura a escolha do momento já pertence a outra pessoa.

Uma plataforma de e-commerce sem suporte é um problema de conformidade antes de ser um incidente de segurança, e é um problema de orçamento antes de ser qualquer uma das duas coisas — porque quanto mais tempo continuar a correr, mais custa sair dela.

Se queres uma visão clara de onde está a tua loja, a nossa prática de consultoria Magento cobre o planeamento da atualização, a postura de segurança e o pipeline de entrega por baixo de tudo isso, e a avaliação inclui a matriz de compatibilidade de extensões descrita acima. Ou fala com a nossa equipa se preferires começar com uma conversa em vez de um documento.