Patches de segurança do Magento 2: como manter a loja em dia

Lojas Magento são um alvo comum porque lidam com pagamentos e rodam numa base de código muito conhecida. Quando a Adobe publica um boletim de segurança, os atacantes também leem, e os scans automáticos por lojas vulneráveis costumam começar em poucos dias. Em algumas vulnerabilidades do passado, a exploração em massa começou muito logo depois de os detalhes virem a público. Aplicar correções de segurança não é tarefa para o próximo sprint. Precisa de uma rotina que funcione sem crise.

Este artigo explica os tipos de correção de segurança que a Adobe entrega para o Magento Open Source e o Adobe Commerce, como aplicar cada um e como montar um processo para que um novo boletim seja um trabalho planejado, e não uma emergência.

Como a Adobe entrega as correções de segurança

São três canais, e ajuda saber com qual deles você está lidando.

Security patch releases

Cada versão minor suportada recebe patch releases com o sufixo -p: 2.4.7-p1, 2.4.8-p2 e assim por diante. Elas contêm correções de segurança e algumas correções funcionais importantes, sem funcionalidades novas. A Adobe as publica num calendário regular e as anuncia com um boletim de segurança que lista os CVEs e a severidade.

Um patch release é instalado exatamente como qualquer upgrade via Composer. Ir do 2.4.8-p2 para o 2.4.8-p3 é uma mudança pequena perto de um upgrade de versão minor, mas ainda roda o setup:upgrade e pede uma rodada de testes no checkout.

Hotfixes isolados

Quando uma vulnerabilidade é séria e não pode esperar o próximo patch release, a Adobe publica um patch isolado para as versões afetadas. Eles vêm como arquivos de patch que você aplica sobre a sua versão atual. Problemas críticos como o CosmicSting (CVE-2024-34102) foram tratados assim, com correções isoladas disponíveis para versões que não podiam atualizar na hora.

Quality patches

A Quality Patches Tool distribui correções individuais, a maioria funcionais, algumas ligadas a segurança. Elas têm IDs como MDVA ou ACSD seguidos de um número. A ferramenta é um pacote Composer que funciona tanto no Magento Open Source quanto no Adobe Commerce.

composer require magento/quality-patches
vendor/bin/magento-patches status
vendor/bin/magento-patches apply MDVA-12345
vendor/bin/magento-patches revert MDVA-12345

O status lista os patches disponíveis para a sua versão exata e se já estão aplicados. Aplique só o que você precisa. Cada patch extra é uma coisa a mais para conferir no próximo upgrade.

Aplicando um patch release com Composer

O processo é o mesmo de qualquer upgrade, só que menor. Numa branch, com uma cópia da produção no seu ambiente local:

composer require-commerce magento/product-community-edition 2.4.8-p3 --no-update
composer update
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento cache:flush

Use magento/product-enterprise-edition para o Adobe Commerce. Se o seu projeto não usa o root update plugin, atualize a constraint de versão do metapackage no composer.json e rode composer update para ele. Veja o checklist de upgrade para o 2.4.8 para o processo completo quando o salto é maior.

Depois da atualização, teste os fluxos que importam: adicionar ao carrinho, checkout com cada forma de pagamento, login de cliente, login no admin e gestão de pedidos. Correções de segurança às vezes endurecem a validação, e uma extensão que antes mandava dados um pouco errados pode começar a falhar.

Aplicando um arquivo de patch isolado

Hotfixes isolados vêm como arquivos diff. Não aplique na mão no servidor. Coloque no seu build para que todo deploy os inclua. Com o cweagans/composer-patches, referencie o patch no composer.json contra o pacote que ele altera:

{
    "extra": {
        "patches": {
            "magento/module-catalog": {
                "Security hotfix from Adobe bulletin": "patches/composer/security-hotfix.patch"
            }
        }
    }
}

Os arquivos de hotfix da Adobe costumam ser escritos para caminhos dentro de vendor/magento e podem tocar vários pacotes, então confira os caminhos no diff e divida por pacote se precisar. Depois rode composer install e confirme que a mudança chegou aos arquivos do vendor. Mais sobre isso no guia de Composer patches.

Anote cada hotfix que você aplicar. Quando depois você atualizar para um patch release que inclui a correção, o patch vai falhar ao aplicar e você o remove. Sem anotações, alguém vai perder uma tarde descobrindo por quê.

O que um patch não corrige

Um patch de segurança fecha a brecha. Ele não desfaz o que aconteceu enquanto a brecha estava aberta. Se a sua loja ficou vulnerável a um problema crítico por semanas antes de você aplicar o patch, presuma que alguém pode ter usado e confira:

• Usuários do admin que você não reconhece, e novas integrações ou tokens de API
• Arquivos modificados recentemente em app, pub, vendor e generated
• Scripts injetados em blocks CMS, páginas CMS e campos de configuração, como as opções de HTML do head e do footer
• Para algumas vulnerabilidades, a Adobe também recomenda trocar a encryption key, porque o ataque poderia lê-la. Siga o boletim para o seu caso.

Se encontrar qualquer coisa, siga um processo de limpeza adequado. Escrevi um checklist de limpeza de malware para essa situação.

Código de terceiros faz parte da superfície de ataque

Muitas lojas comprometidas nem foram atacadas pelo core do Magento. A porta de entrada foi uma extensão com um controller sem autenticação, um recurso de upload que aceitava arquivos PHP ou uma versão antiga de uma biblioteca. Sua rotina de patches deve cobrir:

• composer audit, que confere os pacotes instalados contra advisories conhecidos
• composer outdated --direct, para ver quais extensões têm versões novas
• Changelogs e avisos de segurança dos fornecedores de cada extensão paga
• Código em app/code que foi copiado de algum lugar anos atrás e nunca atualizado

A Adobe também oferece uma Security Scan Tool gratuita para as duas edições. Você registra o domínio na sua conta Adobe e ela roda scans agendados que reportam patches faltando e assinaturas conhecidas de malware. Não substitui o patching, mas é uma segunda checagem útil.

Uma rotina que funciona

O objetivo é tornar as atualizações de segurança entediantes. O que eu recomendo:

1. Assine os boletins de segurança da Adobe e as release notes do Magento, para saber no dia em que um patch sai.
2. Classifique cada boletim. Uma vulnerabilidade crítica, sem autenticação, significa aplicar a correção em dias. Correções de severidade menor podem ir no próximo release agendado.
3. Mantenha uma cópia local funcionando da loja, próxima da produção, com o banco anonimizado. Sem ela, todo patch vira um risco. Veja como sanitizar um banco para o staging.
4. Mantenha o deploy repetível. Se fazer deploy exige que alguém lembre de vinte passos, os patches atrasam. Um script ou pipeline de CI tira essa desculpa.
5. Fique numa versão suportada. A Adobe só entrega correções para linhas de release suportadas. Uma loja numa versão em end of life não tem caminho limpo para aplicar o patch do próximo problema crítico.

O último ponto é o mais ignorado. Aplicar patches dentro de uma versão minor suportada é barato. Estar duas versões minor atrás quando aparece uma vulnerabilidade crítica é o que transforma um trabalho de um dia num projeto de upgrade apressado.

FAQ

Com que frequência a Adobe lança patches de segurança do Magento?

Os patch releases seguem um calendário regular anunciado pela Adobe, e problemas críticos podem receber hotfixes isolados entre eles. Consulte a página de boletins de segurança da Adobe para o calendário atual.

Lojas Magento Open Source recebem as mesmas correções de segurança?

Sim. As correções de segurança são publicadas para as duas edições enquanto a versão ainda é suportada. Módulos exclusivos do Adobe Commerce recebem as correções nos pacotes Commerce.

Posso aplicar um patch de segurança sem atualizar o Magento?

Para problemas críticos a Adobe normalmente publica patches isolados para as versões suportadas. Adicione-os ao seu build com composer patches. Para todo o resto, instale o próximo patch release.

Qual a diferença entre um patch release e um quality patch?

Um patch release como o 2.4.8-p3 é uma versão completa com todas as correções de segurança. Um quality patch é uma correção única aplicada sobre a sua versão com a Quality Patches Tool.

Atendo como freelancer em Magento e Adobe Commerce, incluindo patch releases e correções de segurança. Se precisa de ajuda com isso, fale comigo.