APSB26-146 Adobe Commerce exige mais do que aplicar uma atualização e encerrar o chamado. A Adobe publicou um alerta de ação urgente e informou que o CVE-2026-75650 estava sendo explorado na natureza contra comerciantes do Adobe Commerce, conforme o comunicado oficial do APSB26-146.
Para lojas brasileiras, a resposta precisa considerar não apenas a disponibilidade do site, mas também Admin, clientes, pedidos, PIX, cartão, antifraude, frete, emissão fiscal, ERP e demais integrações. O roteiro defensivo abaixo ajuda a corrigir o ambiente, preservar evidências e verificar se existe algum sinal que exija investigação adicional.
APSB26-146 Adobe Commerce: por que o alerta muda a prioridade?
Quando existe exploração ativa informada pelo fabricante, não é prudente tratar a correção como uma atualização comum do calendário. A equipe deve identificar rapidamente os ambientes expostos, conferir a orientação oficial correspondente à sua instalação e preparar uma janela controlada de aplicação.
Isso não significa atualizar produção sem inventário, backup ou plano de retorno. Também não significa que toda falha encontrada depois do alerta tenha relação com a vulnerabilidade. O objetivo é reduzir a exposição sem apagar registros que possam esclarecer o que ocorreu.
1. Identifique versão, edição e ambientes expostos
Comece registrando produção, homologação, réplicas, painéis administrativos, APIs e ambientes temporários acessíveis pela internet. Não suponha que todos estejam na mesma versão apenas porque compartilham o mesmo repositório.
Em cada instalação, consulte a versão sem alterar o estado da aplicação:
php bin/magento --version
composer show magento/product-enterprise-edition
composer show magento/product-community-editionNem todos os comandos retornarão um pacote, pois isso depende da edição instalada. Registre também o commit em produção, a data do último deploy, o conteúdo relevante do composer.lock e eventuais patches aplicados fora do fluxo normal.
2. Consulte a orientação oficial antes de escolher a correção
Não determine a correção somente pelo número exibido no rodapé do Admin. Compare edição, linha da versão, patches já presentes e método de instalação com a tabela e as instruções do comunicado oficial. A Adobe também recomenda instalar ou atualizar para o patch de segurança mais recente disponível em cada linha do produto, conforme a página de versões lançadas do Adobe Commerce.
Evite copiar um pacote de outro ambiente ou presumir que um hotfix destinado a uma linha servirá em outra. Caso a infraestrutura também esteja com componentes defasados, separe a correção emergencial de uma migração ampla. O inventário usado no artigo sobre atualização de dependências do Adobe Commerce pode ajudar nessa divisão.
3. Preserve logs e evidências antes do deploy
Antes de limpar cache, reiniciar todos os serviços ou remover arquivos suspeitos, copie os registros para um local protegido e com acesso restrito. Preserve, quando disponíveis:
- logs do servidor web, proxy, CDN, WAF e balanceador;
var/log, relatórios de erro e logs de deploy;- registros de autenticação, SSH, PHP-FPM e banco de dados;
- histórico de alterações no repositório e no pipeline;
- eventos do Admin e de provedores de identidade;
- horários dos servidores e fuso utilizado em cada fonte.
Gere hashes dos arquivos exportados e anote quem realizou a coleta. Uma cópia atual do sistema serve para análise; ela não deve ser confundida com um backup limpo para recuperação.
4. Prepare backup e retorno sem sobrescrever pistas
Faça backup consistente do banco, arquivos de mídia, configuração, código e segredos necessários à restauração. Teste se a equipe consegue localizar e ler os artefatos. O rollback deve considerar que retornar a uma versão vulnerável pode restabelecer a exposição; portanto, ele precisa ser planejado como contingência técnica, não como solução definitiva.
Em ambientes com múltiplos nós, confirme como a correção chegará a todos eles. Um nó antigo atrás do balanceador pode manter a loja parcialmente exposta e produzir falhas intermitentes difíceis de reproduzir.
5. Aplique a correção pelo procedimento indicado
Use o procedimento oficial correspondente à edição e à linha identificadas. Execute primeiro em homologação representativa, valide o resultado e promova o mesmo artefato para produção. Não edite diretamente arquivos de vendor nem use composer update sem restrições apenas para tentar alcançar uma versão diferente.
Durante o deploy, registre comandos, saída do Composer, alterações no arquivo de lock e duração de cada etapa. Se a manutenção gerar um erro 503 inesperado ou a loja não retornar, preserve a resposta e siga um diagnóstico por camada, como no guia de erro 503 no Magento 2.
6. Confirme que a correção chegou a todos os nós
Depois do deploy, repita a consulta de versão e confira os pacotes instalados. Compare o código efetivo de cada nó, não apenas o resultado do pipeline. Verifique ainda se containers, imagens, autoscaling ou servidores desligados podem voltar com uma compilação anterior.
Faça uma nova implantação controlada se houver divergência. Limpar cache não corrige um nó executando código antigo, e uma resposta bem-sucedida da página inicial não comprova que Admin e APIs receberam o mesmo artefato.
7. Revise acessos administrativos e identidades
Liste usuários administrativos, funções, integrações, tokens e chaves. Procure contas desconhecidas, alterações de privilégios, redefinições inesperadas e acessos em horários ou origens incompatíveis com a operação.
Se houver indício de comprometimento, a rotação de credenciais deve ocorrer a partir de dispositivos e canais confiáveis. Considere senhas administrativas, chaves SSH, tokens de integração, segredos de API, credenciais de banco e serviços externos. Revogar tudo sem mapear dependências pode interromper pagamentos, ERP e logística; faça a rotação com controle e validação.
8. Verifique arquivos, tarefas e persistência
Compare a instalação com o repositório e os artefatos esperados. Dê atenção a arquivos modificados fora da janela de deploy, extensões desconhecidas, executáveis em diretórios graváveis, tarefas agendadas e alterações na inicialização dos serviços.
git status --short
git diff --name-status
find app pub var -type f -mtime -7 -printO último comando apenas cria uma lista inicial por data e pode produzir muitos resultados legítimos. Não remova arquivos automaticamente. Mudanças em mídia, cache, arquivos gerados e uploads precisam ser interpretadas conforme a arquitetura da loja.
9. Teste checkout e integrações brasileiras
A validação deve incluir navegação anônima, login, busca, produto, carrinho, cupom, cálculo de frete e fechamento do pedido. Use transações controladas para testar PIX, cartão, antifraude, captura, cancelamento e estorno conforme os métodos realmente utilizados.
Confirme também webhooks, filas, ERP, emissão fiscal e atualização de estoque. Se a loja depende de chamadas externas, registre identificadores e respostas sem expor dados sensíveis. O checklist de testes de webhooks no Adobe Commerce ajuda a validar endpoints e registros depois da intervenção.
10. Monitore e defina critérios de escalonamento
Nas horas e dias seguintes, acompanhe autenticações, mudanças administrativas, criação de integrações, erros de aplicação, alterações de arquivos e comportamento do checkout. Compare os eventos com uma linha de base conhecida, evitando interpretar cada acesso automatizado como invasão.
Escalone para resposta especializada se houver contas desconhecidas, código não explicado, tokens criados sem autorização, alterações persistentes após o deploy ou divergências entre pedidos e pagamentos. Aplicar o patch reduz a exposição conhecida, mas não elimina automaticamente modificações que possam ter ocorrido antes da correção.
Conclusão
O APSB26-146 Adobe Commerce pede uma resposta coordenada: identificar a instalação, preservar registros, seguir a correção oficial, conferir todos os nós e revisar acessos, arquivos, checkout e integrações. Atualizar sem validar pode deixar componentes antigos ativos; investigar sem preservar evidências pode impedir a compreensão do incidente.
Se sua equipe não consegue confirmar a versão efetiva, o estado dos patches ou a integridade do ambiente, busque suporte técnico especializado antes de realizar mudanças irreversíveis em produção.
Perguntas frequentes sobre o APSB26-146
Quais versões do Adobe Commerce são afetadas pelo APSB26-146?
A relação deve ser conferida diretamente no comunicado oficial, considerando edição, linha instalada e patches já aplicados. Não escolha a correção apenas pelo número principal da versão.
Como confirmar se o patch foi aplicado corretamente?
Confira a versão e os pacotes instalados, valide o artefato implantado em todos os nós e execute testes de Admin, APIs, catálogo e checkout. O resultado do pipeline, isoladamente, não comprova a atualização de toda a infraestrutura.
Aplicar a correção elimina uma possível invasão?
Não necessariamente. A correção reduz a exposição à vulnerabilidade conhecida, mas não remove automaticamente contas, arquivos, tokens ou outras alterações anteriores. Sinais suspeitos exigem investigação defensiva.
O que deve ser preservado antes da atualização?
Preserve logs de aplicação e infraestrutura, histórico de deploy, registros de autenticação, cópias dos arquivos relevantes, configuração e horários dos eventos. Mantenha esses dados protegidos e separados dos backups operacionais.
Fontes consultadas
As informações atuais mencionadas neste artigo foram verificadas nas fontes abaixo.
