APSB26-73 Magento: quais lojas precisam atualizar e como reduzir riscos no deploy

APSB26-73 Magento é o boletim de segurança que exige uma avaliação objetiva da versão instalada, das extensões e dos fluxos críticos da loja. A correção não deve ser aplicada diretamente em produção sem inventário e testes, mas também não convém ser adiada apenas pelo receio de incompatibilidades.

A Adobe publicou o APSB26-73 em 14 de julho de 2026 para Adobe Commerce e Magento Open Source. O boletim reúne correções para vulnerabilidades críticas, importantes e moderadas, associadas a possíveis impactos como execução arbitrária de código, elevação de privilégios e contorno de recursos de segurança, conforme o boletim oficial APSB26-73.

Quais versões são afetadas pelo APSB26-73 Magento?

Entre as versões relacionadas como afetadas estão Magento Open Source 2.4.6-p15 e anteriores, 2.4.7-p10 e anteriores, 2.4.8-p5 e anteriores e 2.4.9. As linhas corrigidas indicadas incluem 2.4.6-2026-jul, 2.4.7-2026-jul, 2.4.8-2026-jul e 2.4.9-2026-jul. A lista completa, incluindo as edições e combinações contempladas, deve ser conferida no quadro de versões do boletim da Adobe.

Isso significa que olhar apenas para o número principal, como “2.4.7” ou “2.4.8”, não basta. O nível de patch e o pacote efetivamente instalado determinam se a correção já faz parte do ambiente. Também é necessário diferenciar a versão declarada no projeto daquela que está em execução nos servidores.

Como confirmar a versão instalada

Execute os comandos no diretório da aplicação usando o mesmo usuário empregado nos processos de manutenção. Em ambientes com múltiplos nós, confirme se todos receberam o mesmo artefato:

php bin/magento --version
composer show magento/product-community-edition
composer show magento/product-enterprise-edition
composer show magento/magento-cloud-metapackage

Nem todos esses pacotes estarão presentes: o resultado depende da edição e da arquitetura. Compare a saída com o composer.json, o composer.lock do release implantado e o histórico da esteira. Se os servidores retornarem versões diferentes, interrompa o deploy até eliminar a divergência.

A Adobe recomenda atualizar para a versão mais recente indicada no boletim. No momento da publicação, a empresa também declarou não ter conhecimento de exploração ativa das vulnerabilidades tratadas. Essa observação representa a situação informada naquela data, não uma garantia para períodos posteriores, como registra o próprio APSB26-73.

Antes da atualização: preserve evidências e prepare a reversão

Uma atualização de segurança pode alterar componentes que interagem com módulos de terceiros e customizações. Antes de modificar arquivos, registre o estado do ambiente e prepare uma reversão baseada em artefatos conhecidos. Um backup isolado do banco não substitui esse planejamento.

• registre a versão do Magento, do PHP, do Composer e dos serviços associados;
• preserve composer.json, composer.lock e a lista de módulos habilitados;
• identifique patches locais, alterações em vendor e overrides de classes ou templates;
• faça backup consistente do banco e dos arquivos que não podem ser reconstruídos;
• guarde logs anteriores ao deploy para facilitar comparações;
• defina critérios objetivos para avançar ou reverter a implantação.

Se a loja ainda estiver em uma linha antiga, a decisão deve considerar também o ciclo de suporte e a compatibilidade da infraestrutura. Para ambientes 2.4.6, consulte o plano de upgrade do Magento 2.4.6 antes de transformar uma manutenção emergencial em uma migração improvisada.

Patch isolado ou versão corrigida?

A escolha não deve se basear apenas no menor tempo de aplicação. Uma versão corrigida incorpora o nível de segurança publicado para aquela linha e facilita a identificação posterior do estado do ambiente. Um patch isolado, quando disponibilizado para a combinação utilizada, pode reduzir o escopo imediato da mudança, mas exige controle rigoroso sobre origem, compatibilidade, aplicação e remoção futura.

Antes de escolher, responda:

• o artefato é oficialmente destinado à edição e à versão instaladas?
• já existem patches locais que alteram os mesmos arquivos?
• a loja consegue atualizar para a linha corrigida sem ampliar demais a janela?
• como a correção será rastreada no repositório e na documentação operacional?
• o próximo upgrade poderá reaplicar ou entrar em conflito com esse patch?

Não copie uma correção obtida de outro projeto nem edite diretamente o diretório vendor. Mudanças manuais podem desaparecer no próximo composer install, produzir diferenças entre nós e dificultar a comprovação do que realmente está protegido.

Teste o APSB26-73 em staging sem limitar a validação à página inicial

O staging deve reproduzir versões, configurações relevantes e integrações da produção, mas utilizar credenciais de sandbox e dados protegidos. A página inicial abrir corretamente não comprova que carrinho, autenticação, APIs e processamento assíncrono continuam funcionando.

Checkout, PIX, cartão e pedidos

• adicione produtos simples e configuráveis ao carrinho;
• teste compra como visitante e como cliente autenticado;
• calcule frete para diferentes CEPs e regras comerciais;
• valide cartão com e sem etapa adicional de autenticação, quando aplicável;
• gere uma cobrança PIX no ambiente de testes e confira expiração e retorno;
• confirme a criação de pedido, transação, fatura e atualização de status;
• teste webhooks repetidos, atrasados e recebidos fora da ordem esperada;
• verifique cancelamento, estorno e liberação ou compensação de estoque.

PIX, adquirentes, antifraude e transportadoras normalmente dependem de módulos e APIs externas. Por isso, uma resposta aprovada no painel do provedor não comprova que o Magento registrou o pedido. Se houver divergência, siga as verificações para casos de pagamento aprovado sem pedido no Magento antes de repetir cobranças.

Temas, extensões e APIs

Revise customizações que interceptem carrinho, sessão, cliente, cotação, pedido, APIs REST ou GraphQL. Procure preferências, plugins e observers ligados a classes alteradas pela atualização. Erros silenciosos podem aparecer apenas em uma store view, grupo de clientes ou método de pagamento.

• navegue por busca, categoria e página de produto;
• teste login, recuperação de senha e criação de conta;
• valide endpoints consumidos por ERP, aplicativo e frontend desacoplado;
• execute consumidores de filas e tarefas agendadas;
• acompanhe var/log, logs do servidor web, PHP e integrações;
• confirme indexadores, caches e compilação no modo de produção.

Se o checkout apresentar erro após a mudança, evite remover a atualização como primeira reação. Registre horário, carrinho, método, resposta de rede e exceção. Depois, use um roteiro de diagnóstico do checkout Magento para separar incompatibilidade de módulo, falha externa e problema de configuração.

Como implantar e monitorar a produção

Agende uma janela compatível com o volume da loja e suspenda alterações administrativas que possam gerar divergências. Prefira criar um artefato imutável na esteira, validá-lo e distribuir exatamente o mesmo pacote para todos os nós. Não execute uma resolução aberta de dependências diretamente em produção.

Após o deploy, valide imediatamente:

1. versão e presença da correção em cada nó;
2. acesso à vitrine e ao painel administrativo;
3. login, carrinho, cálculo de frete e checkout;
4. um fluxo controlado de cada método de pagamento relevante;
5. cron, filas, indexadores, webhooks e integrações;
6. taxa de erros HTTP, exceções PHP e falhas de JavaScript;
7. criação de pedidos e mudanças de status.

Mantenha monitoramento reforçado depois da janela. Uma falha em webhook ou cron pode surgir minutos depois, enquanto filas acumuladas e callbacks de pagamento podem demorar mais para revelar a incompatibilidade.

Conclusão

O APSB26-73 Magento deve ser tratado como uma atualização defensiva com controle de versão, testes comerciais e plano de reversão. Confirme a edição instalada, escolha apenas uma correção compatível, valide checkout e integrações em staging e monitore a produção após o deploy.

Se sua equipe não consegue determinar o nível de patch, mapear customizações ou testar os meios de pagamento com segurança, solicite uma avaliação técnica antes de modificar a loja. O objetivo é corrigir a exposição sem transformar a atualização em indisponibilidade operacional.

Perguntas frequentes sobre o APSB26-73

Minha versão do Magento está afetada pelo APSB26-73?

O boletim relaciona, entre outras, Magento Open Source 2.4.6-p15 e anteriores, 2.4.7-p10 e anteriores, 2.4.8-p5 e anteriores e 2.4.9. Confirme a edição, o nível de patch e o pacote executado em todos os nós, comparando-os com a tabela oficial.

Qual é a diferença entre aplicar um patch isolado e atualizar para uma versão corrigida?

A versão corrigida estabelece um nível publicado para a linha. Um patch isolado pode ter escopo menor, quando oficialmente disponível e compatível, mas precisa ser rastreado e revisto nos upgrades seguintes. A escolha depende da edição, da versão e dos conflitos com customizações.

Como testar PIX, cartão e webhooks depois da correção?

Use credenciais de sandbox para criar pedidos completos, confirmar transações e acompanhar retornos. Teste webhooks repetidos, atrasados e fora de ordem, além de cancelamento, estorno, faturamento e atualização de estoque.

Posso aplicar a atualização diretamente em produção?

Não é o procedimento recomendado. Reproduza a alteração em staging, preserve arquivos e banco, valide extensões e integrações, prepare reversão e implante um artefato controlado durante uma janela monitorada.

Fontes consultadas

As informações atuais mencionadas neste artigo foram verificadas nas fontes abaixo.

• Adobe Security Bulletin — APSB26-73