Patch isolado da Adobe empilha: julho tem que entrar antes de agosto

O que a Adobe diz, em duas frases

Direto das notas de patch de segurança: os arquivos de patch isolado são non-cumulative, standalone patch files, com correção de segurança e nada mais. E a condição de aplicação: para aplicar um patch isolado, o cliente precisa estar no último security-only patch release (a última versão -p) da sua linha, porque é exclusivamente contra essa versão que o patch foi testado.

Traduzindo para o dia a dia da loja:

• não existe o patch que resolve tudo de uma vez;
• cada mês é um arquivo, e eles se empilham;
• estar em 2.4.8-p4 quando o patch foi feito para 2.4.8-p5 significa que ele não aplica. Nem com força.

Dá para ver isso no nome dos arquivos que a comunidade empacota: 248p5-2026-07-001-CE.patch e 248p5-2026-08-001-CE.patch. O prefixo é a versão base exigida, e vem antes do identificador do mês.

A ordem que funciona

Primeiro descubra onde você está de verdade:

php bin/magento --version

Ele imprime a versão completa, com o -p. Agora compare com o último de cada linha ativa, segundo o calendário de versões da Adobe:

Se você não está no último, esse é o trabalho número um — e é upgrade de -p, não upgrade de linha, então costuma ser tranquilo. Só depois disso vem a sequência dos patches, em ordem cronológica: 2026-07-001 e depois 2026-08-001.

Um aviso de quem já apanhou: faça isso em homologação com o mesmo -p de produção. Testar num ambiente que está numa versão diferente não prova absolutamente nada, porque a versão base é justamente a variável que decide se aplica ou não.

O atalho, e o que ele cobra de volta

Aplicar patch a patch na mão, em várias lojas, cansa. Existe um metapacote da comunidade que junta os isolados e os emergenciais e aplica via vaimo/composer-patches:

composer require samjuk/m2-meta-security-patches:">=2026.02.01"

Duas coisas antes de sair usando. A primeira: o pacote cobre Community Edition. Quem roda Adobe Commerce ou B2B fica de fora e precisa dos arquivos da Adobe mesmo.

A segunda é de segurança. Por padrão o vaimo/composer-patches deixa qualquer dependência declarar patch no seu código, o que é uma porta aberta de cadeia de suprimento. Restrinja a origem no composer.json da raiz:

"extra": {
    "patcher": {
        "sources": {
            "packages": ["samjuk/m2-meta-security-patches"]
        }
    }
}

E guarde uma armadilha conhecida: reinstalar ou atualizar o magento/magento2-base reverte os arquivos corrigidos em silêncio. O composer patch:list continua dizendo que está aplicado. Depois de qualquer operação que mexa nesse pacote, rode composer patch:redo e confira o resultado com um grep no arquivo que o patch alterou.

Patch em dia é a base, não o teto. O resto do trabalho de fechar a loja está no guia de segurança e hardening do Magento 2.