O APSB26-92 Magento precisa ser tratado como uma atualização planejada, não como uma simples execução de comandos em produção. Antes de alterar a loja, a equipe deve identificar a edição e a versão instaladas, conferir a correção correspondente, revisar extensões e reproduzir os principais fluxos comerciais em um ambiente de homologação.
A Adobe publicou o boletim APSB26-92 em 11 de agosto de 2026 e orienta a instalação da atualização de segurança mais recente. A documentação também informa que patches isolados devem ser aplicados sobre a versão security-only mais recente da respectiva linha, conforme o comunicado oficial do APSB26-92.
Como saber se a loja está afetada pelo APSB26-92 Magento?
Não determine a exposição apenas pelo número exibido no rodapé do painel. É necessário confirmar a edição, a versão efetivamente instalada pelo Composer, os patches anteriores e eventuais alterações no código. Em ambientes com múltiplos nós, confira também se todos executam o mesmo pacote.
No diretório raiz da aplicação, use o usuário responsável pela manutenção para consultar a versão:
php bin/magento --version
composer show magento/product-community-edition
composer show magento/product-enterprise-editionO primeiro comando mostra a versão reconhecida pela aplicação. Os dois comandos seguintes ajudam a identificar o metapacote do Magento Open Source ou do Adobe Commerce; é normal que apenas um deles retorne um pacote instalado.
Depois, compare o resultado com o boletim e com a página de atualizações de segurança do Magento e Adobe Commerce. Não escolha uma versão corrigida por semelhança de numeração nem reutilize um patch destinado a outra linha. A referência aplicável depende da edição e da linha atualmente mantida pela loja.
Registre o estado antes de atualizar
Monte um inventário curto, mas verificável, contendo:
- edição e versão do Magento;
- conteúdo relevante do arquivo
composer.lock; - patches já aplicados e método usado para gerenciá-los;
- módulos de checkout, pagamento, antifraude, frete e cálculo fiscal;
- integrações com ERP, PIM, marketplaces e hubs;
- customizações em autenticação, carrinho, pedidos e APIs;
- versões de PHP, banco de dados, mecanismo de busca e serviços de cache.
Esse registro evita que a correção seja analisada isoladamente. Uma loja pode estar na linha esperada e ainda apresentar incompatibilidade por causa de uma extensão, dependência bloqueada ou sobrescrita de classe.
Patch isolado ou atualização da linha?
A escolha deve seguir exatamente o caminho documentado para a edição e a versão instaladas. O comunicado do APSB26-92 orienta instalar a atualização de segurança mais recente e estabelece que um patch isolado seja aplicado sobre a versão security-only mais recente da linha correspondente, como detalhado pela Adobe na orientação do APSB26-92.
Isso significa que baixar um arquivo de correção não elimina a necessidade de conferir a base. Se a loja estiver atrasada dentro de sua linha, pode ser necessário atualizar essa base antes de aplicar o patch indicado. A equipe também deve verificar se patches anteriores continuam necessários e se existe conflito entre alterações no mesmo arquivo.
Evite aplicar a correção diretamente no servidor ativo. A documentação oficial recomenda validar pré-requisitos, dependências, extensões e ambiente antes da atualização, conforme o procedimento de upgrade do Adobe Commerce.
Checklist de homologação antes do deploy
1. Reproduza a produção em staging
Use uma cópia sanitizada e suficientemente representativa da loja. O ambiente deve manter versões equivalentes dos serviços essenciais, além das mesmas extensões e configurações relevantes. Desative o envio real de e-mails, webhooks e cobranças para impedir ações contra clientes ou sistemas externos.
2. Instale a correção pelo método previsto
Crie uma branch exclusiva, preserve o arquivo de dependências e registre todos os comandos executados. Após a instalação, revise o diff, procure falhas de aplicação e confirme se nenhum arquivo customizado foi sobrescrito sem análise.
Quando houver atualização por Composer, trate alterações inesperadas de dependências como um sinal para interromper e revisar o processo. Não force versões ou remova pacotes apenas para concluir a instalação.
3. Execute verificações técnicas
Com a aplicação em homologação, valide o estado básico:
php bin/magento maintenance:status
php bin/magento module:status
php bin/magento setup:db:status
php bin/magento indexer:status
php bin/magento cache:statusAnalise também os logs da aplicação, PHP, servidor web, filas e serviços externos. Um comando concluído sem erro não prova que o checkout está funcional. Caso algum índice permaneça em estado inesperado depois do processo, siga um diagnóstico controlado de indexadores Magento travados antes de resetar ou reindexar tudo.
O que testar no checkout brasileiro após o APSB26-92
A validação deve cobrir mais do que abrir a página inicial. Priorize jornadas que geram pedidos e movimentam dados entre a loja e serviços externos.
- Login e conta: autenticação, recuperação de senha, cadastro e endereços.
- Catálogo: busca, categorias, produtos simples e configuráveis, preços e estoque.
- Carrinho: inclusão, alteração de quantidade, cupom, frete e persistência da sessão.
- Checkout: cliente autenticado e visitante, diferentes CEPs, métodos de entrega e totais.
- PIX: criação da cobrança, apresentação do QR Code, expiração e retorno de confirmação.
- Cartão: autorização aprovada e recusada, parcelamento, antifraude e autenticação adicional quando utilizada.
- Webhooks: recebimento, autenticação, idempotência e atualização do pedido sem duplicidade.
- Pós-venda: emissão de fatura, cancelamento, envio de e-mail e sincronização com ERP.
- APIs: autenticação, consulta e atualização de produtos, estoque, clientes e pedidos.
Integrações REST e GraphQL merecem testes próprios, especialmente quando payloads, escopos e respostas são consumidos por ERP ou frontend separado. O roteiro sobre testes de REST e GraphQL no Magento ajuda a estruturar comparações antes e depois da alteração.
Como executar o deploy com possibilidade de reversão
Defina uma janela compatível com o volume da operação e comunique as áreas responsáveis por atendimento, pagamentos e integrações. Antes de começar, confirme backup consistente, responsável pela decisão de retorno e critérios objetivos para interromper o deploy.
Um plano operacional deve incluir:
- registro da versão e do commit atualmente publicados;
- backup validado dos componentes necessários à restauração;
- ativação controlada do modo de manutenção, quando aplicável;
- instalação da atualização pelo processo homologado;
- execução das etapas necessárias de banco, conteúdo estático e cache;
- testes rápidos de página de produto, carrinho, checkout e pedido;
- monitoramento de erros HTTP, logs, filas, pagamentos e webhooks;
- reversão se os critérios de falha forem atingidos.
Não use limpeza indiscriminada de diretórios, edição direta no banco ou desativação aleatória de módulos para fazer a loja voltar. Essas ações podem apagar evidências, criar divergências entre nós e dificultar a reversão.
O APSB26-92 sucede outros ciclos de correção, mas cada boletim precisa de avaliação própria. Se a loja passou por uma atualização anterior, consulte também o checklist de deploy seguro do APSB26-73 para reaproveitar inventário, evidências e testes, sem presumir que os patches sejam equivalentes.
Perguntas frequentes sobre o APSB26-92
Como saber se minha loja Magento está afetada pelo APSB26-92?
Confirme a edição e a versão instaladas pelo Magento e pelo Composer, levante os patches existentes e compare os resultados com o boletim oficial. Não use apenas a aparência do painel ou a versão esperada no projeto.
Qual é a versão corrigida do APSB26-92 para Magento Open Source?
A versão aplicável depende da linha instalada. Consulte a tabela e as instruções oficiais do APSB26-92 antes de alterar o Composer ou baixar um patch, pois uma correção destinada a outra linha não deve ser reutilizada.
O APSB26-92 exige upgrade completo ou possui patch isolado?
A Adobe orienta instalar a atualização de segurança mais recente e informa que patches isolados devem ser aplicados sobre a versão security-only mais recente da linha correspondente. A decisão depende da base atual da loja e da opção documentada para ela.
Como testar PIX e cartão depois do patch?
Use credenciais de homologação e valide criação da transação, aprovação, recusa, retorno assíncrono, idempotência, atualização do pedido e comunicação com antifraude ou ERP. Não faça cobranças reais como teste técnico.
Conclusão
O APSB26-92 Magento deve entrar em um processo que una segurança e continuidade comercial: identificar a versão real, escolher a correção oficial, homologar extensões e testar checkout, PIX, cartão, webhooks e APIs. Se sua equipe precisa revisar a compatibilidade ou executar o deploy com monitoramento e plano de retorno, fale com os especialistas em suporte Magento.
Fontes consultadas
As informações atuais mencionadas neste artigo foram verificadas nas fontes abaixo.
