Magento 1 legado em 2026: fim de vida, riscos de segurança, OpenMage e o caminho correto para sair

Fim de vida: o relógio parou em 30 de junho de 2020

O suporte ao Magento 1 — tanto o Magento Open Source 1 (antes Community Edition) quanto o Magento Commerce 1 (antes Enterprise Edition) — terminou oficialmente em 30 de junho de 2020. A Adobe anunciou essa data ainda em setembro de 2018, dando cerca de 18 meses de aviso prévio justamente para que os lojistas planejassem a re-plataforma. Desde o EOL, a Adobe não publica mais patches de segurança, correções de qualidade nem oferece suporte técnico para o Magento 1. Toda vulnerabilidade descoberta a partir de julho de 2020 permanece aberta na sua loja para sempre.

O último patch oficial: SUPEE-11346

O Magento 1 viveu durante anos sob um regime de patches de segurança chamados SUPEE (Security Update / Patch Express Edition). O último bundle oficial emitido pela Adobe foi o SUPEE-11346, lançado em 22 de junho de 2020 — oito dias antes do EOL. Ele está documentado no boletim de segurança Adobe APSB20-41 e corrigiu duas falhas relevantes:

Se você ainda está em Magento 1, o SUPEE-11346 é o piso absoluto: rodar sem ele significa estar exposto a falhas que já tinham correção pública e disponível. Mas não se iluda achando que aplicá-lo resolve — ele é o último patch oficial, e o mundo das CVEs não parou em junho de 2020.

Conforme documentado pela Meetanshi com base no boletim de segurança da Adobe, o Magento lançou o patch final SUPEE-11346 em 22 de junho de 2020 — o último pacote de segurança oficial antes do fim de vida da plataforma, que corrige múltiplas falhas críticas incluindo cross-site scripting e execução arbitrária de código.

Fonte: Meetanshi

"Não responderemos a mais nenhum problema de segurança"

Após o SUPEE-11346, a posição da Adobe foi explícita: a empresa declarou que não responderia a nenhum problema de segurança adicional do Magento 1. Isso é o que diferencia o Magento 1 de um software apenas desatualizado. Não existe um número de telefone, um portal ou um SLA para reportar uma vulnerabilidade nova e receber correção. O fornecedor original (Adobe) fechou a porta. A partir daí, qualquer CVE que apareça em código de core do Magento 1 fica permanentemente sem patch oficial — e cada lojista vira responsável único por seu próprio risco.

Eu costumo dizer aos clientes que o Magento 1 hoje é como dirigir um carro cujo fabricante saiu do mercado: as peças ainda existem no mercado paralelo, mas ninguém vai mais emitir recall quando descobrirem um defeito de fábrica. A diferença é que, no e-commerce, o "defeito" vira roubo de dados de cartão dos seus clientes.

Risco de segurança e PCI DSS: por que software sem suporte é insustentável

Rodar Magento 1 cria dois problemas distintos que se reforçam: exposição técnica (CVEs sem correção) e inconformidade regulatória (PCI DSS). Não são a mesma coisa, e os dois custam dinheiro.

Exposição técnica: o relógio que só acumula CVEs

Todo software acumula vulnerabilidades ao longo do tempo. Em um produto com suporte, isso é gerenciável: o fornecedor emite patches e você aplica dentro de uma janela. No Magento 1, esse ciclo está quebrado pela metade — as CVEs continuam sendo descobertas, mas o lado do patch oficial desapareceu em 30/06/2020. Cada vulnerabilidade nova de core, cada falha em biblioteca antiga que o M1 carrega, fica permanentemente aberta. O atacante sabe exatamente o que vai encontrar.

PCI DSS Requisito 6: patching dentro de um mês

O PCI DSS (Payment Card Industry Data Security Standard) é o padrão obrigatório para quem armazena, processa ou transmite dados de cartão. O Requisito 6 trata diretamente de manter sistemas e software seguros, e exige a instalação de patches de segurança críticos em um prazo definido. Software sem suporte do fornecedor não tem caminho de patching — e, sem caminho de patching, a conformidade fica logicamente impossível.

De acordo com o PCI DSS Guide, o Requisito 6 do PCI DSS determina que patches de segurança críticos sejam instalados dentro de um mês após o lançamento. Software sem suporte do fornecedor — como o Magento 1 pós-EOL — acumula vulnerabilidades que não podem ser remediadas, tornando a conformidade PCI DSS inviável a longo prazo. O Requisito 12.3.4 trata especificamente do monitoramento de software em fim de vida.

Fonte: PCI DSS Guide

A consequência prática para o lojista brasileiro: rodar Magento 1 com checkout próprio processando cartão é declarar conformidade que você não consegue sustentar de verdade. Em um vazamento, a ausência de patching pelo fornecedor original é exatamente o tipo de falha que o adquirente e as bandeiras vão apontar. O resultado pode ser:

• Multas: aplicadas pelo adquirente e pelas bandeiras quando se constata ambiente não conforme.
• Perda do merchant account: o adquirente pode suspender sua capacidade de processar cartões.
• Responsabilidade ampliada: em vazamento, o lojista responde por não ter mantido o ambiente atualizado.
• Custo de perícia e limpeza: resposta a incidente, forense e notificação custam, na minha experiência, muito mais do que o projeto de migração que foi adiado.

Trabalho esse risco de forma muito mais profunda no guia de segurança e hardening do Magento 2 — mas lá o ponto de partida já é uma plataforma com patches. No M1, você está defendendo um castelo sem a possibilidade de consertar as muralhas.

A onda Magecart pós-EOL: Cardbleed e NaturalFreshMall em números

"Risco" soa abstrato até virar número. A Sansec, empresa holandesa especializada em forense de e-commerce, documentou de forma detalhada o que aconteceu com as lojas Magento 1 depois do fim de vida. Os dados são o melhor argumento que existe contra ficar em M1.

Cardbleed (setembro de 2020): 2.806 lojas em quatro dias

Menos de três meses após o EOL, a Sansec detectou a campanha apelidada de Cardbleed. Em apenas quatro dias, 2.806 lojas Magento 1 foram infectadas com skimmer de cartão — cerca de 3% da base instalada de aproximadamente 95.000 lojas M1 ainda ativas naquele momento. A progressão diária mostra a natureza automatizada do ataque:

Segundo a pesquisa da Sansec, a campanha Cardbleed infectou 2.806 lojas Magento 1 em quatro dias (cerca de 3% da base instalada de ~95.000 lojas M1 ativas), usando como vetor um 0day de execução remota de código vendido por US$ 5.000. O salto de 10 lojas na sexta para 1.058 no sábado evidencia a automação total do ataque sobre uma plataforma que já não recebia patches.

Fonte: Sansec

NaturalFreshMall (janeiro/fevereiro de 2022): o ataque não parou

Quem pensa que Cardbleed foi um evento isolado de 2020 está enganado. Em janeiro e fevereiro de 2022 — quase dois anos após o EOL — a Sansec documentou a campanha NaturalFreshMall: 374 lojas Magento 1 infectadas em um único dia (25 de janeiro de 2022), com mais de 500 lojas comprometidas no total. O vetor foi SQL Injection combinado com PHP Object Injection no plugin Quickview. O skimmer carregava de naturalfreshmall.com/image/pixel.js e os atacantes deixavam pelo menos 19 backdoors por loja vítima — para garantir que, mesmo limpa, a loja fosse reinfectada.

Conforme a Sansec, a campanha NaturalFreshMall comprometeu 374 lojas Magento 1 em 25 de janeiro de 2022 (mais de 500 no total), explorando SQL Injection combinado com PHP Object Injection no plugin Quickview, com o skimmer servido a partir de naturalfreshmall.com/image/pixel.js e ao menos 19 backdoors plantados por loja vítima.

Fonte: Sansec

O contexto Magecart: a escala do problema

Essas duas campanhas são apenas amostras de um fenômeno maior chamado Magecart — o conjunto de grupos que injetam skimmers de cartão no checkout de lojas e-commerce. A Sansec estima que mais de 70.000 lojas já contiveram um skimmer digital, número que sobe para mais de 100.000 afetadas quando se incluem vítimas de ataques a supply chain (CDNs, bibliotecas e widgets de terceiros comprometidos).

De acordo com a Sansec, mais de 70.000 lojas já hospedaram um skimmer digital em algum momento, e o total ultrapassa 100.000 quando se contam as vítimas de comprometimentos de supply chain.

Fonte: Sansec

A lição que tiro de campo: lojas Magento 1 não são alvejadas "se der azar". Elas são varridas em massa, automaticamente, por bots que conhecem exatamente quais falhas o core M1 nunca vai corrigir. É só questão de tempo.

PHP e a stack do Magento 1: nascido no PHP 5.x

Boa parte da fragilidade do Magento 1 não está só no código de aplicação — está na fundação. O M1 foi projetado para uma stack que hoje está inteiramente em fim de vida, começando pelo próprio interpretador.

Os requisitos originais: PHP 5.4 a 5.6

O Magento 1 original rodava em PHP 5.4.x a 5.6.x. Só a edição Enterprise Edition 1.14.4.0+ recebeu suporte experimental a PHP 7.2.x antes do EOL — e "experimental" aqui significa exatamente o que parece: nada que eu colocaria em produção sem reservas. Na prática, a esmagadora maioria das lojas M1 que vejo ainda hoje roda em PHP 5.6 ou 7.0.

Repare no detalhe brutal: o PHP 5.6 chegou ao fim de vida em dezembro de 2018, antes mesmo do próprio Magento 1. Ou seja, uma loja M1 típica roda hoje sobre um interpretador que está sem patches de segurança há mais de sete anos, dentro de uma aplicação que está sem patches há quase seis. São duas camadas de software morto, empilhadas.

Os problemas concretos de infra antiga

• SO sem suporte: PHP 5.6 normalmente só roda em distribuições antigas (CentOS 6/7, Ubuntu 14/16), que também já saíram de suporte — mais camadas sem patch.
• Sem OPcache moderno, sem JIT: performance presa em padrões de uma década atrás; impossível competir em Core Web Vitals.
• Bibliotecas TLS/OpenSSL antigas: dificuldade crescente para falar com gateways e APIs que já exigem TLS 1.2/1.3 e cipher suites modernas.
• Provedores recusando hospedar: cada vez mais hosts não oferecem mais PHP 5.6 por padrão, e alguns se recusam a hospedar pilhas EOL por risco.

É por aqui que entra a primeira tábua de salvação da comunidade: como vamos ver a seguir, o OpenMage LTS destrava versões modernas de PHP para o Magento 1, tirando a loja desse buraco específico de interpretador morto — sem ainda resolver o problema de fundo, que é não ser mais o Magento 1.

OpenMage LTS: o fork da comunidade que mantém o M1 vivo (com PHP 8)

Quando a Adobe abandonou o Magento 1, a comunidade fez o que comunidades open source fazem: criou um fork. O OpenMage LTS (pacote Composer openmage/magento-lts) é o fork comunitário não oficial do antigo Magento Community Edition, iniciado em 28 de junho de 2020 — literalmente dois dias antes do EOL. Ele mantém a compatibilidade com módulos e temas do Magento 1, mas continua aplicando correções de bugs, melhorias e, crucialmente, suporte a versões modernas de PHP.

O que o OpenMage destrava em PHP

Aqui está o maior ganho prático do OpenMage. Enquanto o Magento 1 original morreu preso em PHP 5.6, o OpenMage elevou o mínimo suportado de forma agressiva ao longo das versões:

A versão estável mais recente registrada é a v20.18.0, lançada em 4 de maio de 2026. Em termos de stack, isso significa que uma loja que era "Magento 1 em PHP 5.6" pode virar "OpenMage em PHP 8.3" — recuperando OPcache moderno, JIT, TLS atual e a possibilidade de rodar em SO ainda suportado.

Conforme a documentação e o changelog do OpenMage, a partir do v20.14.0 (junho de 2025) o PHP 8.1 passou a ser o requisito mínimo, e o branch v20.x declara suporte a php: ">=8.1 <8.6" — ou seja, PHP 8.1 a 8.5. A versão estável mais recente é a v20.18.0 (4 de maio de 2026).

Fonte: OpenMage LTS (Releases) e Packagist

Instalação via Composer

O OpenMage é instalável via Composer, o que já é uma melhoria de manutenção frente ao Magento 1 original. Para a linha v20:

composer require "openmage/magento-lts":"^20.0.0"

Para rodar sob PHP 8, o instalador do core depende de uma versão específica do core composer installer:

composer require "aydin-hassan/magento-core-composer-installer":"~2.1.0"

Recursos de segurança que o OpenMage adicionou

Além do PHP moderno, o OpenMage trouxe melhorias de segurança que o M1 oficial nunca teve:

• Content Security Policy (CSP): introduzida a partir do v20.14.0 (junho de 2025), ajudando a mitigar injeção de JS — exatamente o tipo de defesa relevante contra skimmers.
• URL de admin customizada: recurso de segurança adicionado no v20.16.0 (novembro de 2025), permitindo esconder o caminho do painel.
• Correções contínuas de bugs e vulnerabilidades: mantidas pela comunidade, sem o fornecedor original.

A ressalva que eu sempre faço

O próprio projeto descreve o OpenMage LTS como um projeto não oficial conduzido pela comunidade — ele não é suporte oficial da Adobe e não substitui uma migração para o Magento 2 / Adobe Commerce.

Fonte: OpenMage LTS (GitHub)

O OpenMage é excelente para o que se propõe: estender a vida útil de uma loja M1 com segurança, dar fôlego para planejar a migração com calma e tirar você do PHP morto. Mas ele não é o Magento 2, não tem GraphQL, não tem full page cache nativo competitivo, não tem o ecossistema de extensões e integrações modernas, e — fundamental — não te coloca de volta no caminho oficial de patches da Adobe nem resolve o problema de longo prazo de PCI. Trate-o como uma ponte, não como destino.

Mage-One: patches pagos como alternativa comercial

Nem todo lojista quer ou pode adotar um fork comunitário com a manutenção por conta própria. Para esse público existe o Mage-One (mage-one.com), um serviço pago de patches para Magento 1 após o EOL da Adobe. A proposta é comercial: você assina, eles entregam patches de segurança e compatibilidade, e você mantém a loja M1 atual de pé com responsabilidade terceirizada.

Preços por faturamento

O Mage-One cobra assinatura mensal escalonada pelo faturamento anual da loja:

O que está incluído

• Patches de segurança: correções para vulnerabilidades descobertas após o EOL da Adobe.
• Compatibilidade de stack: patches para rodar em versões mais novas de PHP, MySQL e Apache.
• QPS (Quick Protection System): extensão que bloqueia ataques conhecidos com atualização automática de assinaturas — funciona como uma camada de proteção em tempo real contra exploits já catalogados.

Segundo o site do Mage-One, o serviço oferece assinatura mensal baseada no faturamento anual (€29, €99 e €299/mês), incluindo patches de segurança, patches de compatibilidade com PHP/MySQL/Apache e o QPS (Quick Protection System), extensão que bloqueia ataques conhecidos com atualização automática de assinaturas.

Fonte: Mage-One

OpenMage vs. Mage-One: como eu decido

A regra que sigo: quem tem time técnico e quer custo zero de licença vai de OpenMage LTS. Quem prefere terceirizar a responsabilidade de patching e quer uma camada de bloqueio gerenciada (QPS) considera o Mage-One. Mas o ponto que repito até cansar: nenhum dos dois é suporte oficial da Adobe. Ambos são paliativos legítimos para ganhar tempo — não substituem a migração, e nenhum dos dois, sozinho, resolve definitivamente a questão de conformidade PCI no longo prazo. Pense neles como o aluguel de uma ponte enquanto você constrói a estrada nova.

Hardening interino: como segurar a loja M1 enquanto não migra

Se você ainda está em Magento 1 e a migração não acontece amanhã, não dá para cruzar os braços. Existe um conjunto de medidas de hardening interino que reduzem a superfície de ataque enquanto você planeja a saída. Deixo claro de novo: isso é contenção de danos, não cura. Nenhuma dessas medidas devolve patches de core para CVEs novas. Elas só tornam você um alvo mais difícil do que o vizinho desprotegido — e, num mundo de ataques automatizados em massa, ser mais difícil já filtra muita coisa.

Checklist de hardening que aplico em loja M1

• Aplique o SUPEE-11346: é o último patch oficial e o piso absoluto. Rodar sem ele é negligência pura — as CVEs que ele fecha têm exploit público.
• WAF na borda: coloque um Web Application Firewall na frente (Cloudflare, AWS WAF, ModSecurity com regras OWASP CRS). É a primeira linha contra SQLi, RCE e os padrões de ataque automatizado que varrem lojas M1.
• Renomeie o path do admin: mude o /admin padrão (via Mage_Core_Helper_Data::getAdminRouteName / config admin/url/custom). Não é segurança real sozinho, mas tira você dos scanners que batem direto em /admin e /downloader.
• Ative 2FA no painel: autenticação de dois fatores no admin elimina a maior parte dos ataques de força bruta e credenciais vazadas — o admin é o alvo número um.
• Remova /downloader e arquivos de instalação: delete o diretório /downloader (Magento Connect) e bloqueie acesso direto a connect.php; o Connect foi vetor histórico de RCE em M1. Apague também os arquivos de instalação remanescentes.
• File Integrity Monitoring contra skimmer: monitore a integridade dos arquivos PHP e, principalmente, do JS do checkout. Skimmers vivem injetando JavaScript malicioso na página de pagamento — uma mudança não autorizada em arquivo de checkout é o sinal de alerta mais importante.
• Monitore JS injetado no checkout: além do FIM em arquivos, vigie o que efetivamente carrega no checkout em produção (CSP, varredura de DOM). Cardbleed e NaturalFreshMall carregavam o skimmer de domínios externos — um CSP restritivo e monitoramento de recursos externos pegam isso.

Comandos e pontos de configuração

# Bloquear acesso ao Connect/downloader no nginx
location ~* ^/(downloader|connect\.php) {
    deny all;
    return 403;
}

# Restringir o admin por IP (camada extra, se IP fixo)
location ~* ^/SEU_ADMIN_RENOMEADO {
    allow 203.0.113.0/24;   # rede do escritorio
    deny all;
}

Se você migrou para o OpenMage LTS, várias dessas defesas ficam mais fáceis: a URL de admin customizada (v20.16.0) e o CSP (v20.14.0) já vêm no core do fork, em vez de gambiarra manual. É mais um motivo para, no mínimo, sair do Magento 1 oficial e ir para o OpenMage enquanto a migração definitiva não chega.

Conforme o histórico de releases do OpenMage, o suporte a URL de admin customizada foi adicionado no v20.16.0 (novembro de 2025) e o Content Security Policy (CSP) a partir do v20.14.0 (junho de 2025) — ambos recursos de hardening que o Magento 1 oficial nunca teve.

Fonte: OpenMage LTS (Releases)

Aplico essas medidas em todo cliente M1 que ainda não pôde migrar, mas sempre com uma conversa franca: hardening é o cinto de segurança de um carro que já deveria estar na oficina. Reduz a chance de tragédia, não elimina. As práticas completas de defesa em profundidade — para a plataforma certa — estão no meu guia de segurança e hardening do Magento 2.

Por que migrar e para onde: o destino é Magento 2 / Adobe Commerce

Tudo o que vimos até aqui — OpenMage, Mage-One, hardening — compra tempo. Nenhuma dessas opções coloca você de volta no caminho oficial da Adobe, com patches de segurança e funcionalidade contínuos. Para isso só existe um destino: o Magento 2 / Adobe Commerce.

Por que o M1 não tem futuro

• Sem patches oficiais para sempre: a Adobe não vai voltar atrás. Cada CVE nova de core fica aberta indefinidamente.
• PCI insustentável: sem caminho de patching do fornecedor original, a conformidade de longo prazo é inviável (Requisito 6).
• Ecossistema secando: gateways, antifraudes, ERPs e marketplaces vão deixando de publicar conectores M1. No Brasil, a integração com ERP e NF-e moderna assume M2.
• Performance teto baixo: sem full page cache nativo, sem indexadores assíncronos, sem GraphQL — impossível competir em Core Web Vitals.
• Talento migrando: a comunidade de devs Magento foca em M2/Adobe Commerce; encontrar quem mantenha M1 fica mais caro e raro a cada ano.

O destino: Adobe Commerce continua com suporte oficial

Ao contrário do M1, o Adobe Commerce (antigo Magento Commerce) e o Magento Open Source 2 seguem recebendo patches de segurança, atualizações de funcionalidade e — no caso do Commerce — suporte oficial. Há um ciclo de vida previsível, com janela de suporte definida por release, em vez de uma data de morte fixa. Isso é o que torna a plataforma sustentável do ponto de vista de segurança e de PCI.

Conforme a política de ciclo de vida da Adobe Commerce, as versões do Adobe Commerce e do Magento Open Source 2 recebem patches de qualidade e de segurança dentro de uma janela de suporte definida — diferentemente do Magento 1, que não recebe mais nenhum patch desde 30 de junho de 2020.

Fonte: Adobe Experience League

Open Source 2 ou Adobe Commerce?

Para a maioria das lojas B2C de pequeno e médio porte no Brasil, o Magento Open Source 2 resolve — é gratuito, recebe patches e tem todo o ecossistema moderno —, desde que você assuma a responsabilidade de manter segurança e atualizações em dia (o erro de não fazer isso foi, no fundo, o que levou ao desastre do M1). Operações maiores, B2B, ou que querem recursos de IA e BI de fábrica costumam justificar o Adobe Commerce. Como o core é o mesmo, dá para começar no Open Source e migrar para Commerce depois sem nova re-plataforma. Detalho essa decisão no guia Adobe Commerce vs Magento Open Source.

O caminho de saída: Data Migration Tool e preservação de SEO

Migrar de Magento 1 para Magento 2 não é um upgrade — é uma re-plataforma. Essa é a frase que mais economiza frustração em projeto. O banco de dados pode ser transferido com a ferramenta oficial, mas código, extensões e tema precisam ser reconstruídos do zero. Quem trata como "copiar e colar" descobre no meio do caminho que precisa de um projeto de desenvolvimento completo.

Data Migration Tool: a ferramenta oficial

A Data Migration Tool (pacote Composer magento/data-migration-tool) é a ferramenta oficial da Adobe para transferir os dados do banco do M1 para o M2 / Adobe Commerce — pedidos, clientes, produtos e configurações. Ela opera em três modos, nesta ordem: settings → data → delta.

# Casar versão: para Magento 2.x.y, use Data Migration Tool 2.x.y
composer require magento/data-migration-tool:<version>

# Ordem obrigatoria dos modos
bin/magento migrate:settings <path config.xml>
bin/magento migrate:data     <path config.xml>
bin/magento migrate:delta    <path config.xml>

Preservar o SEO é metade do projeto

Uma migração tecnicamente perfeita que quebra as URLs destrói anos de tráfego orgânico. Os pontos críticos: alinhar o url_suffix (.html ou vazio) entre M1 e M2, preservar as URL keys e mapear redirects 301 para tudo que mudar de caminho. Outro gotcha que tira o sono: a crypt_key — se você informar errado a chave de criptografia do M1, o login de toda a base de clientes quebra no go-live. Esses detalhes, com comandos e runbook de cutover, estão no guia dedicado de migração de Magento 1 para Magento 2.

Hardening é paliativo; migração é solução

Encerro como comecei, porque é a mensagem que importa: OpenMage, Mage-One e hardening são pontes — a migração é a estrada. Use as pontes para atravessar com segurança o período de transição, mas não confunda a ponte com o destino. Toda loja M1 que vejo prosperando em 2026 é uma loja que tratou o EOL de 2020 não como um prazo a ignorar, mas como o tiro de largada para a re-plataforma. Se a sua ainda está em Magento 1, o melhor momento para começar a migrar foi há cinco anos. O segundo melhor é agora.