Magento 2.4.9, patches e fim de suporte: onde a sua loja está agora

A versão atual: Magento Open Source 2.4.9

A versão mais recente do Magento Open Source e do Adobe Commerce é a 2.4.9, publicada em 12 de maio de 2026. Se você quiser conferir sem intermediário, a página Released versions da Adobe e as tags do repositório magento/magento2 no GitHub batem na mesma data.

Um cuidado para quem for checar: as páginas de release notes na Experience League mostram um campo "Last update" no topo, que é a data da última edição do texto, não a data de lançamento. Já vi gente citar esse campo como se fosse o GA e errar por meses.

O que mudou na stack (e é aqui que dói)

A 2.4.9 não foi uma release de "mais um recurso". Ela trocou peças de fundação. Comparando com a linha anterior:

Repare em duas linhas. A primeira: PHP 8.2 e 8.3 saíram. O PHP 8.4 é aceito só para você conseguir rodar o upgrade, e a Adobe não recomenda deixar em produção. Se o seu servidor está em 8.2, o trabalho começa antes do Magento.

A segunda: Elasticsearch e Redis não aparecem mais na linha da 2.4.9 da tabela oficial de requisitos. Quem busca é o OpenSearch 3, quem guarda cache e sessão é o Valkey — o fork do Redis que a Linux Foundation adotou depois da mudança de licença do Redis. Na 2.4.8 o Elasticsearch 8 ainda consta; na 2.4.9, não. Todo material que ainda diz "Magento usa Elasticsearch e Redis" está descrevendo a geração anterior.

Conforme a tabela oficial de requisitos de sistema da Adobe, a linha da 2.4.9 traz PHP 8.5, OpenSearch 3, Valkey 9, MySQL 8.4, MariaDB 11.8 ou 12.3, RabbitMQ 4.3, Varnish 8 e Composer 2.10, sem Elasticsearch e sem Redis, que continuam listados apenas para a linha 2.4.8.

Fonte: Adobe · System requirements

O que a 2.4.9 mexeu por dentro

Do lado de fora a loja continua parecida. Por dentro, a Adobe trocou quatro bibliotecas de base. Ninguém vê, e todo mundo que mantém módulo sente. Vale conhecer as quatro antes de agendar o upgrade:

• TinyMCE virou HugeRTE. O editor de conteúdo do admin mudou de projeto. O motivo é chato mas simples: o TinyMCE 5 e 6 saíram de suporte e a licença do 7 não servia. Se você tem módulo que estende o editor, é o primeiro candidato a quebrar.
• Zend_Cache virou Symfony Cache. Código que ainda chamava a camada de cache do velho Zend Framework precisa ser reescrito.
• Laminas MVC saiu. A Magento passou a manter a própria implementação de MVC em vez de depender do Laminas.
• OAuth de terceiros saiu. A biblioteca externa de OAuth foi substituída pelas funções nativas do PHP.

Em volume, a Adobe relata 580 issues corrigidas no core do Magento Open Source 2.4.9 e 666 no core do Adobe Commerce 2.4.9. É release de manutenção pesada, não de vitrine.

Coisas que interessam ao Brasil

Duas mudanças pequenas que me fizeram sorrir: o Braintree passou a suportar a bandeira ELO, o que reduz um pouco a dependência de gateway local para quem vende cartão aqui, e o Apple Pay funciona em Chrome e Firefox, não só no Safari. Também entraram vault de cartão do Google Pay via Braintree e o método BLIK (polonês, irrelevante para nós, mas indica onde a Adobe está investindo).

API e admin

A mutation GraphQL clearCart, que era exclusiva do Adobe Commerce, passou a existir também no Magento Open Source. Entraram clearWishlist e exchangeExternalCustomerToken, o campo grand_total_excl_tax nas respostas de pedido, e a validação de reCAPTCHA passou a valer também em chamadas REST e GraphQL. Isso é bom para segurança e é exatamente o tipo de coisa que derruba integração de ERP no dia do upgrade se ninguém avisou o time.

Uma melhoria de segurança que veio antes e pouca gente ligou

Desde a 2.4.7 o Content Security Policy vem em modo restritivo por padrão nas páginas de pagamento — vitrine e admin — e em modo report-only no resto do site. Nas páginas de pagamento o cabeçalho não traz unsafe-inline em script-src, e só script inline em lista de permissão roda. Antes da 2.4.7 tudo era report-only, ou seja, registrava e não bloqueava nada.

Isso importa por dois motivos: é a defesa nativa contra skimmer de cartão no checkout, e é o tipo de controle que auditoria de PCI DSS 4.0 pergunta. Quem está em 2.4.6 ou anterior precisa configurar na mão.

No admin, o 2FA ficou menos irritante: agora basta ter um provider habilitado por usuário. Se você quer o passo a passo de configuração, escrevi separado no guia de segurança e hardening do Magento 2.

De acordo com as release notes da Adobe para a 2.4.9, a versão substituiu o TinyMCE pelo HugeRTE (por fim de suporte do TinyMCE 5 e 6 e incompatibilidade de licença do 7), trocou o Zend_Cache pelo Symfony Cache, passou a manter uma implementação MVC própria no lugar do Laminas MVC e adotou as funções nativas de OAuth do PHP no lugar da biblioteca de terceiros.

Fonte: Adobe · Magento Open Source 2.4.9 release notes

O que a release não resolve

Vale dizer com todas as letras, porque é onde eu vejo loja atualizada sendo invadida: os boletins da Adobe cobrem o core, não as suas extensões. Em 2026 a Sansec divulgou correção em massa de dezenas de extensões de um fornecedor grande, duas delas com execução remota de código. Nenhuma dessas falhas aparece em boletim APSB nem é coberta por patch isolado mensal. Manter composer outdated em dia nos módulos de terceiro é parte do trabalho, não um extra.

As linhas vivas e o que significa cada tipo de patch

No mesmo 12 de maio de 2026 em que saiu a 2.4.9, a Adobe publicou patch para todas as linhas ainda suportadas. Hoje o mapa é este:

Estar "no Magento 2.4.7" não quer dizer nada sozinho. Entre a 2.4.7 crua de abril de 2024 e a 2.4.7-p10 de maio de 2026 tem dez rodadas de correção de segurança. É a diferença entre uma loja atualizada e uma loja que só parece.

Os cinco tipos de entrega da Adobe

Essa parte confunde muita gente, inclusive gente boa. A Adobe entrega correção de cinco jeitos diferentes:

• Patch release (2.4.x): a release completa, com recurso novo. Hoje é uma por ano.
• Security patch release (o sufixo -pN): só correção de segurança e qualidade, sem recurso novo. É o 2.4.8-p5 da vida.
• Isolated security patch file: arquivo avulso, aplicado por cima da última -p da sua linha. Ele não embute os patches isolados anteriores, então a ordem importa: julho antes de agosto. Foi assim que a Adobe entregou os boletins de 2026.
• Hotfix: resposta de emergência a 0-day, normalmente via Quality Patches Tool.
• Individual patch: correção pontual de um bug específico.

A regra que pega todo mundo: para aplicar um patch isolado, a loja precisa estar na última -p da sua linha. Não dá para pular a fila. Se você está em 2.4.7-p6 e quer o patch de agosto de 2026, primeiro vai para a 2.4.7-p10.

Segundo a política de versionamento e a documentação de security patches da Adobe, os patches isolados não são cumulativos e exigem que a instalação esteja na security-only patch release mais recente da linha antes de serem aplicados.

Fonte: Adobe · Security patches overview

Fim de suporte: as datas que decidem o seu orçamento

A Adobe dá três anos de suporte padrão contados da data de lançamento de cada versão. Traduzindo para o calendário:

A pegadinha que custa caro no Open Source

Você vai ler por aí que a 2.4.6 tem "suporte estendido até 31 de agosto de 2027" e correções de segurança até maio de 2028. É verdade: para cliente Adobe Commerce. Esse ano extra é benefício de contrato pago. A base de código do Magento Open Source não recebe esses patches.

Ou seja: se você roda Magento Open Source 2.4.6, o seu suporte acabou em 11 de agosto de 2026 e não tem prorrogação. Toda CVE publicada de lá para cá fica aberta na sua loja até você subir de linha. É a mesma história que eu conto no guia do Magento 1 legado, só que numa escala de tempo mais curta e com muito mais gente exposta.

Quem está na Adobe Commerce on Cloud tem prazo com data

Na nuvem gerenciada da Adobe a coisa é ainda mais dura, porque virou política com consequência operacional: quem está em 2.4.4 ou 2.4.5 precisa ir para a 2.4.9 (ou para o Cloud Service) até 1º de junho de 2027; quem está em 2.4.6 ou 2.4.7, até 1º de junho de 2028. Tem também prazo de dependência: MariaDB/Galera 10.5 ou inferior precisa ir para 10.6+ até 30 de outubro de 2026, e PHP 8.1 ou inferior até 31 de maio de 2027. A Adobe avisa que ambiente fora de conformidade pode ter o tráfego suspenso: a loja sai do ar.

Conforme a política de aplicação de segurança da Adobe para o Commerce on Cloud, ambientes que não cumprirem os prazos de upgrade podem ter o tráfego suspenso e, persistindo a situação, ser descomissionados.

Fonte: Adobe · Security enforcement policy

A cadência mudou: uma release por ano e o resto como serviço

Quem acompanha Magento desde 2015 lembra de quatro, cinco releases por ano. Isso acabou. O modelo atual é: uma release completa por ano, em maio, com um alpha e um beta no meio do caminho, mais patches de segurança conforme a necessidade. A linha 2.4.x virou LTS.

Dá para ver o padrão nas tags do GitHub: em 2025 as datas foram 08/04, 10/06, 12/08 e 14/10; em 2026 foram 10/03 e 12/05, e depois disso a Adobe passou a soltar correção como patch isolado avulso em vez de release nova. Os boletins de 2026 têm saído na segunda terça-feira do mês.

Não existe Magento 2.5

Se alguém te ofereceu "migração para o Magento 2.5", desconfie. Nenhuma página oficial da Adobe menciona 2.5 nem 2.4.10. A estratégia declarada é manter o core em uma release anual e entregar capacidade nova como serviço SaaS componível — Live Search, Catalog Service, Payment Services, Adobe Commerce Optimizer, que você pluga quando quiser, em vez de esperar o core crescer.

Isso muda o cálculo de quem escolhe plataforma hoje. O core parou de inchar; o que muda de verdade está do lado de fora. Comparo as duas edições em detalhe no guia Adobe Commerce vs Magento Open Source.

De acordo com o FAQ da Adobe sobre estratégia de release e ciclo de vida, passa a haver uma release de patch do core por ano, com as novas capacidades entregues como serviços SaaS componíveis que podem ser adicionados a qualquer momento.

Fonte: Adobe · Patch release schedule

O que a Adobe entrega fora do core (e o que ainda é beta)

Se o core só recebe uma release por ano, a pergunta óbvia é: onde é que a Adobe está investindo? A resposta é "em serviços que você pluga por fora". Vale conhecer, porque tem coisa boa, tem coisa que não serve para o Brasil e tem coisa que agência anuncia como pronta e ainda está em beta.

Quais serviços rodam no Magento Open Source (de graça) e quais não

Se você está em Open Source e alguém te ofereceu "Live Search da Adobe", ou está vendendo Adobe Commerce sem dizer, ou está confundindo com outra coisa.

A pegadinha da busca semântica para quem vende em português

Em 8 de junho de 2026 o Live Search ganhou busca semântica, aquela que entende intenção em vez de casar palavra. Notícia boa, com uma letra miúda que muda tudo por aqui: a documentação diz que ela funciona apenas para catálogos em inglês.

Ou seja, para uma loja brasileira com catálogo em português, esse recurso específico ainda não entrega nada. Se busca semântica é o que você precisa, hoje o caminho realista é montar por fora. Falo disso no guia de IA no Magento e Adobe Commerce.

Adobe Commerce Optimizer e Cloud Service: SaaS por cima do que você já tem

O Adobe Commerce Optimizer é uma camada SaaS de catálogo, busca e merchandising que roda por cima do backend que a loja já tem, sem substituir a plataforma. E existe caminho oficial para quem está em Magento: o conector Adobe Commerce → Optimizer chegou em versão estável em 1º de março de 2026 e está na 1.1.0 desde 2 de setembro de 2026, sincronizando catálogo, atributos de categoria e metadados.

Já o Adobe Commerce as a Cloud Service é o SaaS de verdade: sem versão, gerenciado pela Adobe, com release mensal em vez de anual. É para onde a Adobe empurra quem não quer manter servidor. Em setembro de 2026 ele recebeu o 2.4.9 em sandbox.

IA no Adobe Commerce: o que está pronto e o que não está

Aqui é onde eu recomendo ler a documentação e não o material de evento:

• AI Assistant do admin (Merchant Productivity): cria promoção, atualiza metadado de catálogo e responde pergunta operacional em linguagem natural. Está em beta público, não é GA: a página oficial de betas, atualizada em 4 de setembro de 2026, ainda o lista assim.
• Commerce MCP (o servidor que deixaria agente de IA navegar catálogo e fechar pedido): a documentação da Adobe marca como "coming soon". Recap de parceiro do Summit 2026 diz que já está disponível. São afirmações conflitantes; eu não trataria como pronto até a doc mudar.
• Commerce Developer Agent: ferramenta de IA para migrar módulo legado para App Builder. A própria Adobe descreve como gerador de ponto de partida, não desenvolvedor autônomo, e exige revisão humana antes de produção, com atenção redobrada em pagamento e segurança. Assinado embaixo; é o mesmo cuidado que descrevo no guia de IA no desenvolvimento Magento.
• Protocolos de commerce agêntico: em fevereiro de 2026 a Adobe anunciou suporte a UCP e ACP, para que catálogo, preço e estoque fiquem legíveis por agente de IA. Anúncio de direção, sem cronograma detalhado.

Edge Delivery: o número oficial é mais modesto do que o de agência

O storefront em Edge Delivery Services é a aposta da Adobe para performance. Vale saber qual é a promessa oficial: a documentação diz que a arquitetura permite pontuar acima de 90 no Lighthouse e passar nos Core Web Vitals. Só isso.

"Lighthouse 100" e "+37% de conversão" que você vê em post de agência não saem de nenhuma página da Adobe com metodologia. O único caso com número publicado pela própria Adobe relata Lighthouse saindo de 20 para a faixa dos 90 e carregamento caindo de até 15 segundos para menos de 2 em páginas cacheadas. E esse caso não apresenta dado de conversão do cliente, apenas cita um estudo de mercado de terceiros.

A página oficial de recursos em beta do Adobe Commerce, atualizada em 4 de setembro de 2026, lista o AI Assistant de produtividade do lojista como beta público, ou seja, ainda não é disponibilidade geral.

Fonte: Adobe · Beta features

Os boletins de segurança de 2026

A partir de janeiro de 2026 a Adobe mudou o ritmo: o core ganha uma release por ano, e a segurança passou a sair como patch isolado, normalmente na segunda terça-feira do mês. Os boletins de 2026 até agora:

CVE-2026-71362: trocar de conta sem ter conta

Essa merece parágrafo próprio. No registro do NVD ela é uma falha de Incorrect Authorization (CWE-863), CVSS 3.1 de 9.1, vetor AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. Em português: explorável pela rede, sem privilégio nenhum e sem que o usuário precise fazer nada.

A Sansec descreve o efeito prático: o atacante troca a sessão de um cliente para outra conta de cliente. Ele não precisa ter cadastro, não precisa ser admin, e a vítima não clica em nada. Em loja com endereço e cartão salvo, isso deixa de ser incidente de TI e vira incidente de LGPD.

A regra que faz o patch isolado falhar

Cada arquivo corrige só o boletim dele, mas exige os anteriores já aplicados. Para instalar o de agosto de 2026 você precisa estar na última -p da sua linha e já ter passado o de julho. Pular etapa não dá erro bonito: dá conflito de patch às duas da manhã.

Se você deixou os dois para depois, a fila é: subir para a última -p → aplicar julho → aplicar agosto. Nessa ordem, uma coisa de cada vez, com backup entre elas.

Segundo o artigo de base de conhecimento da Adobe sobre o APSB26-92, o boletim foi distribuído como arquivos de patch isolado aplicáveis sobre a última security patch release de cada linha, com os patches isolados anteriores já aplicados.

Fonte: Adobe KB · APSB26-92

Três ondas em dois anos, e o que elas ensinam sobre prazo

"Aplico no fim do mês" é uma frase que já custou muito dinheiro no ecossistema Magento. Três casos recentes mostram, com número, qual é a janela real entre o patch sair e os bots chegarem.

CosmicSting (2024): 4.275 lojas, 5% do mundo

A CVE-2024-34102, apelidada de CosmicSting, é um XXE com CVSS 9.8, corrigida no boletim APSB24-40 em 11 de junho de 2024. Ela permite ler arquivo arbitrário do servidor. Na prática, a chave de criptografia em app/etc/env.php. Com a chave, o atacante gera token de admin da API e faz o que quiser.

Uma semana depois do patch, 75% das lojas ainda não tinham aplicado. A Sansec contabilizou 4.275 lojas invadidas, cerca de 5% de todas as lojas Magento e Adobe Commerce do mundo, com vítimas do porte de National Geographic, Segway, Ray-Ban e Cisco. Sete grupos concorrentes disputavam as mesmas lojas, a uma taxa de 5 a 30 invasões por hora.

Detalhe que explica muita coisa: a Adobe classificou a falha inicialmente como severidade 3. Só em 8 de julho de 2024, quase um mês depois, elevou para prioridade crítica. Quem esperou o rótulo "crítico" para agir já tinha perdido a janela.

SessionReaper (2025): seis semanas de vantagem, desperdiçadas

A CVE-2025-54236, CVSS 9.1, ganhou boletim emergencial (APSB25-88) em 9 de setembro de 2025. A exploração em massa começou em 22 de outubro. No primeiro dia a Sansec bloqueou mais de 250 tentativas, e naquele momento apenas 38% das lojas estavam corrigidas.

De lá a coisa piorou rápido: cerca de 31% das lojas monitoradas atacadas em 24/10, 49% em 26/10, 81% em 1º de novembro, com estimativa de 16% a 18% já com backdoor instalado. A CISA colocou a CVE no catálogo KEV em 24 de outubro de 2025, com prazo obrigatório de correção para órgãos federais americanos.

Dez dias depois do patch original, menos de uma em cada três lojas Magento estava corrigida. Havia seis semanas de vantagem sobre o atacante. Quase ninguém usou.

PolyShell (2026): o que só a 2.4.9 corrige

Esse é o caso que muda a recomendação deste guia, então leia com atenção.

O PolyShell, divulgado pela Sansec em 17 de março de 2026, é um upload irrestrito de arquivo na REST API do Magento que leva a execução remota de código sem autenticação. O problema está no processamento de custom options do tipo arquivo em item de carrinho: a API não valida ID de opção, não impõe restrição de tipo e não bloqueia extensão perigosa. O validador só olha tamanho e MIME type, então um arquivo poliglota — um PNG válido que também é PHP válido — passa. Basta um Guest Cart ID e um SKU.

A exploração em massa começou em 19 de março de 2026. Em 14 de abril, 82% das lojas monitoradas pela Sansec já tinham recebido upload malicioso. Em 30 de março a Sansec registrou 471 lojas comprometidas em uma única hora.

E aqui vem o ponto: a correção saiu na 2.4.9 e não foi retroportada para 2.4.8, 2.4.7 nem anteriores. Ou seja, se a sua loja está em qualquer linha abaixo da 2.4.9, ela continua exposta a essa falha específica mesmo com todos os patches da sua linha aplicados. As mitigações disponíveis são de infraestrutura: bloquear execução de PHP em pub/media (confira o .htaccess em pub/media/ e em pub/media/custom_options/) e regra de WAF.

# nginx: negar execução de PHP dentro de pub/media
location ~* ^/(pub/)?media/.*\.(php|phtml|php5|phar)$ {
    deny all;
}

# procurar arquivo suspeito no diretório usado pelo PolyShell
find pub/media/custom_options/ -type f \( -name '*.php*' -o -name '*.phtml' \) 2>/dev/null
grep -rl '<?php' pub/media/custom_options/ 2>/dev/null | head

De acordo com a pesquisa da Sansec sobre o PolyShell, a correção está associada ao branch 2.4.9 e não foi retroportada para as linhas suportadas anteriores, de modo que lojas em 2.4.8 e abaixo dependem de mitigação — como bloquear a execução de PHP em pub/media — em vez de patch.

Fonte: Sansec · Magento PolyShell

O padrão

Duas conclusões que eu tiro disso, e que uso para decidir prioridade com cliente. Primeira: a janela entre patch e ataque encolheu de semanas para dias, e no PolyShell e no StyleSmuggler o ataque veio antes de existir correção para a sua linha. Segunda: patch em dia não é mais garantia. Precisa de camada de bloqueio na frente e de monitoramento de integridade de arquivo. Detalho isso no guia de segurança e hardening.

StyleSmuggler: o 0-day que está sendo explorado agora

Esta seção tem prazo de validade e eu vou datá-la: escrevo em 7 de setembro de 2026.

Em 5 de setembro de 2026 a Sansec publicou o StyleSmuggler, uma falha de execução remota de código sem autenticação que, na data da publicação, não tinha correção. A primeira exploração confirmada é de 4 de setembro às 22h20 UTC. A Sansec diz ter reproduzido a cadeia completa em instalações limpas de Magento Open Source 2.4.7, 2.4.8 e 2.4.9.

O detalhe que me fez escrever esta seção às pressas: a primeira vítima documentada rodava 2.4.6-p15 com os patches de julho e agosto de 2026 aplicados e com o security:patch-status limpo. Estar em dia não protegeu.

Em linhas gerais, sem entrar em detalhe que sirva de receita: o ataque abusa de propriedades de estilo em requisição GraphQL para plantar código em arquivo que o próprio Magento gera, e depois provoca a renderização interna de um e-mail transacional para que o código rode. Ninguém precisa abrir e-mail nenhum.

A Sansec descreve o StyleSmuggler como um zero-day sem correção de Magento e Adobe Commerce que dá execução remota de código a atacantes não autenticados, afetando todas as versões atuais, incluindo a 2.4.9, com ataques iniciados em 4 de setembro de 2026.

Fonte: Sansec · StyleSmuggler

O que fazer hoje

• Bloqueie na borda, se puder. É a mitigação que não derruba nada da loja. WAF com regra para o padrão de requisição, ou um serviço de proteção específico.
• Desabilite o GraphQL temporariamente se a sua loja não for headless nem usar PWA. A própria Sansec sugere isso até a Adobe publicar a correção. Em loja headless isso derruba a vitrine. Não faça sem pensar.
• Desabilite proc_open no PHP e monte os diretórios temporários com noexec. Não impede a injeção, mas atrapalha bastante o segundo estágio.
• Acompanhe o boletim da Adobe. A próxima publicação de segurança estava agendada para 8 de setembro de 2026 e, no texto da Sansec, ainda não havia confirmação de que ela cobriria essa falha. Quando sair, aplique no mesmo dia.

Como checar se você já foi atingido

O indicador citado é um processo em segundo plano disfarçado de [kworker/u:8:0] ou de fc-cache, com entrada de cron reinstalando o processo periodicamente:

crontab -l | grep -iE 'gvfsd|fc-cache'
ls -la ~/.cache/fontconfig/fc-cache ~/.local/share/.gvfsd/ 2>/dev/null
ps -eo pid,comm,args | grep -iE 'kworker|fc-cache'
grep -ril 'x_trace_' var/report/
tail -200 var/log/system.log

Se algum desses devolver coisa, pare de ler e trate como incidente: a loja está comprometida. O caminho a partir daí é isolamento, perícia e troca de todas as credenciais e chaves. Não é apagar arquivo e seguir a vida. A Sansec avisa, inclusive, que o malware pode manter em memória uma versão diferente da que está em disco, então checagem só por hash de arquivo engana.

Vou atualizar esta seção quando a Adobe publicar a correção.

Como descobrir, em cinco minutos, onde a sua loja está

Chega de teoria. Entre por SSH na loja e rode isto:

# versão instalada
php bin/magento --version

# versão exata do pacote de produto (mostra o -pN)
composer show magento/product-community-edition | head -3

# status dos patches de segurança conhecidos
php bin/magento security:patch-status

# versão do PHP que o CLI e o site estão usando (podem ser diferentes!)
php -v

O --version mostra a linha (2.4.7, por exemplo) mas nem sempre o sufixo de patch. Quem dá a resposta exata é o composer show. Já vi loja que "estava na 2.4.7" e o pacote apontava 2.4.7-p3, com sete rodadas de correção de segurança faltando.

Quality Patches Tool: o atalho que pouca gente usa

A Adobe mantém uma ferramenta que lista e aplica patches individuais sem você subir de versão:

composer require magento/quality-patches
php bin/magento support:patch:status

Ela é a via oficial para hotfix de 0-day e para correção pontual que ainda não entrou numa -p. Vale ter instalada antes de precisar.

Ficar na 2.4.8 ainda é seguro?

Depende do que te preocupa. Para o ciclo normal de boletins, sim: a 2.4.8 recebe patch até 31 de maio de 2028 e, com a última -p e os patches isolados aplicados, você está no mesmo nível de quem está na 2.4.9.

A exceção é o PolyShell. Aquela correção só existe na 2.4.9 e não foi retroportada. Se você fica na 2.4.8, precisa tratar essa falha por infraestrutura (bloqueio de PHP em pub/media e WAF) e saber que está compensando na mão uma coisa que a versão nova resolve na origem. Para loja que processa cartão, essa é a conta que eu colocaria na mesa antes de adiar o upgrade mais um trimestre.

A ordem que eu sigo num upgrade

1. Ambiente antes de aplicação. Confira PHP, banco, busca e cache contra a tabela de requisitos da versão de destino. Subir Magento com PHP fora da tabela não dá erro claro: dá exceção estranha três dias depois, em produção, num fluxo que ninguém testou.
2. Inventário de módulo de terceiro. Liste tudo com composer show e cheque a compatibilidade um por um. Na 2.4.9, olhe com atenção quem toca no editor de conteúdo, em cache e em OAuth.
3. Cópia de produção em staging. Banco e mídia reais. Upgrade em base de teste vazia não revela nada.
4. Suba de -p em -p primeiro. Chegue na última patch release da sua linha atual antes de trocar de linha. Menos variável por vez, menos noite perdida.
5. Teste checkout, integração e busca. Nessa ordem. Checkout paga a conta, integração é o que quebra calado, busca é o que o cliente percebe primeiro.
6. Janela e plano de volta. Backup restaurável testado, não backup que existe.

Se a sua loja está em Magento 1, o caminho é outro e mais longo. Está no guia de migração de Magento 1 para Magento 2.

A base encolheu. E daí?

Falar de versão e patch sem falar do tamanho do ecossistema dá uma foto incompleta. Então vamos ao número desconfortável.

Quantas lojas Magento existem

Em 4 de setembro de 2026, o Store Leads contava 102.875 lojas Magento ativas no mundo. No mesmo trimestre a base caiu 7,6%, e 14% em doze meses. Comparando com o pico, no fim de 2021 (cerca de 162 mil lojas), são 36% a menos.

O W3Techs, medindo por outro método, chega ao mesmo lugar: em 7 de setembro de 2026 o Magento aparece em 0,3% de todos os sites e com 1,5% do mercado de sistemas de e-commerce. Sexto lugar, atrás de WooCommerce (48,1%), Shopify (31,7%), PrestaShop, OpenCart e Nuvemshop.

No Brasil o quadro é mais duro

O Brasil é o sexto maior mercado do Magento, atrás de Estados Unidos, Alemanha, Reino Unido, Holanda e Espanha. Mas aqui a queda é maior que a média global. Enquanto isso, quem cresce é plataforma SaaS de loja pequena e média.

Minha leitura

O Magento perdeu, e não vai recuperar, a faixa de "quero vender online rápido". Nuvemshop e Shopify fazem isso melhor, mais barato e sem servidor. Quem migrou nos últimos três anos, em geral, foi loja que não precisava do que o Magento oferece de diferente.

O que sobrou é uma base menor e mais qualificada: operação com ERP, regra de preço por cliente, B2B, catálogo grande, multi-loja, integração fiscal complicada. Para esse perfil, os motivos de escolher Magento continuam de pé: código aberto, banco na sua mão, zero percentual sobre venda e a possibilidade de modelar o processo em vez de espremer o negócio dentro do que o SaaS permite.

A conclusão prática para quem já está: uma base menor significa menos gente para contratar e menos agência com Magento no portfólio. Isso não é motivo para sair correndo, mas é motivo para não deixar a loja num pântano de versão sem suporte, porque achar quem conserte um Magento 2.4.3 em 2027 vai ser bem mais difícil e bem mais caro do que é hoje.

Três números que você vai ver por aí e que não existem

Já que estamos falando de dados, aproveito para desmontar três coisas que circulam em artigo de agência:

• "250 mil lojas Magento no mundo". Contradiz frontalmente as duas medições datadas que dá para abrir e conferir. O número real, em setembro de 2026, é da ordem de 100 mil.
• "170 mil desenvolvedores Magento". Não existe fonte primária da Adobe para isso, nem hoje nem antes. É número herdado da era Magento Inc. e repetido desde então.
• "O Adobe Commerce processa US$ 173 bilhões de GMV por ano". A Adobe não divulga GMV do Adobe Commerce nos resultados trimestrais: não há linha de Commerce nem métrica de GMV no reporte. Os bilhões que você vê em janeiro são do Adobe Analytics, que mede o gasto do varejo online americano inteiro, não o que passa por lojas Adobe Commerce. Trocar um pelo outro é o erro mais comum do gênero.

Segundo o relatório do Store Leads sobre o estado do Magento, atualizado em 4 de setembro de 2026, há 102.875 lojas ativas rodando a plataforma, com queda de 7,6% no trimestre e de 14% em doze meses.

Fonte: Store Leads · The State of Magento in 2026

Quem mantém o Magento hoje

Base menor não é a mesma coisa que projeto abandonado. Vale separar as duas conversas, porque elas se confundem toda hora. Fui atrás de número em vez de opinião. Tudo aqui foi conferido em 7 de setembro de 2026.

O repositório oficial continua andando

O magento/magento2 tem 12.180 estrelas e 9.351 forks, e o último push foi em 4 de setembro de 2026, três dias atrás. Nos 90 dias anteriores foram mais de 100 commits no branch 2.4-develop.

Do lado da comunidade: 93 pull requests mergeados em 2026 até setembro, vindos de 52 autores diferentes. Não é meia dúzia de pessoas segurando a barra: são dezenas de desenvolvedores de fora da Adobe mandando correção que entra no core.

O sinal contrário, que também é dado

Os mesmos números mostram um gargalo claro: existem 992 pull requests abertos no repositório. Em 2026 foram 434 PRs abertos contra 219 fechados. A comunidade manda trabalho num ritmo cerca de duas vezes maior do que a Adobe consegue processar, e o ritmo de merge caiu de aproximadamente 13,8 PRs por mês em 2025 para 11,6 em 2026.

O código está vivo; o gargalo é a governança do repositório oficial. É justamente essa frustração que fez a comunidade organizar estrutura própria.

Mage-OS: a comunidade montou a própria distribuição

O Mage-OS é uma distribuição comunitária construída sobre o Magento Open Source. Não é fork hostil: o próprio projeto diz que não pretende quebrar compatibilidade. Quem toca é a Mage-OS Association, uma associação sem fins lucrativos registrada na Polônia desde 2022, com conselho eleito pelos membros em assembleia anual.

Está entregando com regularidade: 3.2.0 em 14/07/2026, 3.3.0 em 05/08/2026 e 3.4.0 em 11/08/2026. A 3.4.0 já traz o patch de segurança APSB26-92 portado. A linha 3.x é baseada no Magento Open Source 2.4.9 e acrescentou instalador interativo, módulo de RMA, log de atividade do admin e uma distribuição mínima opcional. A associação declara 215+ contribuintes financeiros e mais de €154 mil arrecadados.

O posicionamento declarado é o que interessa a quem planeja longo prazo: se um dia a Adobe parar de manter o Magento Open Source, o Mage-OS pretende assumir o lugar. Ter esse plano B com estatuto, conselho eleito e caixa é bem diferente de ter uma promessa em fórum.

Hyvä ficou de graça, e isso mexeu no mercado

Em 10 de novembro de 2025 o tema Hyvä passou a ser open source e gratuito, relicenciado sob OSL-3.0 e AFL-3.0. Antes custava por volta de US$ 1.000 por loja, e essa taxa era a maior barreira de entrada para loja brasileira de porte médio.

O efeito aparece no número: 6.400+ lojas em janeiro de 2026, 7.600+ em julho. São mais de 500 agências parceiras e cerca de 6.900 pessoas no Slack da comunidade. O tema base é gratuito; Hyvä Checkout, Commerce e Enterprise seguem pagos.

Na prática isso importa porque o front-end sempre foi o calcanhar de Aquiles do Magento em Core Web Vitals. Com o Hyvä de graça, a conta de uma loja rápida ficou bem mais fácil de fechar. Trato disso no guia de performance e Core Web Vitals.

Eventos: onde a comunidade ainda se encontra

Em 2026 já aconteceram oito edições presenciais do Meet Magento: Índia, Estados Unidos (Flórida), Brasil, Itália, França, Reino Unido, Tchéquia e Ucrânia. A de Kyiv foi em 3 de setembro, com uma trilha inteira dedicada a IA. Ainda vêm Manchester (14/10), Alemanha (22/10), Polônia (29/10) e Holanda (05/11).

O Meet Magento Brasil 2026 foi em 15 de maio, em São Paulo, com nove palestras cobrindo IA no Magento, integrações, performance, pagamentos, reforma tributária e Kubernetes. A Magento Association segue em pé e fez seu primeiro Town Hall do ano em 19 de março de 2026.

O Mage Titans UK, por outro lado, está parado desde abril de 2023 e o site só promete voltar, sem data. E não existe "Mage-OS Summit": o que o Mage-OS promove são hackathons e contribution days, com o próximo marcado para 24 de setembro de 2026.

O pedaço brasileiro

Aqui o quadro é misto.

O que está vivo é o que tem empresa por trás. O módulo oficial do Mercado Pago (mercadopago/adb-payment) lançou a v1.15.6 em 20 de agosto de 2026 e soma 103 mil downloads. O do PagBank (pagbank/payment-magento) está na 101.1.5, de 3 de agosto de 2026. E o mais relevante: o suporte a CNPJ alfanumérico já foi implementado e mergeado em 3 de agosto de 2026. A adaptação regulatória chegou em open source antes de virar problema para a maioria das lojas.

Tem ainda um polo produtivo em torno da O2TI, com cerca de 15 pacotes no Packagist somando aproximadamente 120 mil downloads e releases recentes em agosto de 2026, cobrindo checkout, validação de documento fiscal, endereço por CEP, máscara de campo e Correios.

O que está parado é a parte comunitária difusa. A organização magento-developers-brasil no GitHub, que era o ponto de encontro histórico daqui, não recebe commit desde junho de 2021. E a maioria dos módulos de nicho — NF-e, Correios, boa parte dos de Pix — parou entre 2017 e 2025. A conclusão prática: se a sua loja depende de um módulo brasileiro de nicho, confira a data do último commit antes de instalar, e assuma que talvez você vá manter aquilo sozinho.

Até o Magento 1 ainda tem gente

Sinal curioso de vitalidade: o OpenMage, fork comunitário do Magento 1, teve push em 7 de setembro de 2026 (hoje) e roda 4 mil downloads por mês no Packagist. Uma plataforma que a Adobe abandonou em 2020 ainda tem manutenção voluntária seis anos depois. Não é motivo para ficar em M1 (esse assunto está no guia do Magento 1 legado), mas diz alguma coisa sobre o tipo de gente que esse ecossistema junta.

O FAQ oficial do Mage-OS descreve o projeto como uma distribuição com governança democrática, conselho eleito anualmente pelos membros, e declara que se ou quando a Adobe deixar de dar suporte ao Magento Open Source, o Mage-OS estará bem posicionado para ocupar esse lugar.

Fonte: Mage-OS · FAQ

Resumindo o que eu diria a um cliente

O Magento não é mais a plataforma de todo mundo, e não vai voltar a ser. Mas ele não está órfão: tem release anual com três anos de suporte, tem dezenas de contribuidores externos ativos, tem uma associação com caixa pronta para assumir a manutenção se precisar, tem um tema de front-end que acabou de ficar gratuito e tem os módulos de pagamento brasileiros que importam sendo mantidos por empresa, não por voluntário cansado.

Para operação complexa, isso é ecossistema suficiente. Para loja simples, nunca foi a escolha certa mesmo.