Esta é uma explicação rápida sobre uma vulnerabilidade que está sendo ativamente explorada (listada no KEV da CISA). Ela descreve o que acontece, quem é afetado e como responder, do ponto de vista de quem defende, sem passos de reprodução.
- CVE
- CVE-2026-71362
- Severidade
- Crítica (CVSS 9.1 / v3.1)
- Tipo
- Autorização incorreta (CWE-863)
- Impacto
- Escalonamento de privilégios — nas palavras da Adobe, "acesso elevado a recursos sensíveis"
- Pré-condições
- Sem autenticação, sem privilégios de administrador, sem interação do usuário
- Afetados
- Adobe Commerce (2.4.4–2.4.9), Adobe Commerce B2B e Magento Open Source (2.4.6–2.4.9), cada linha em "2026-jul" e anteriores
- Correção
- A versão "2026-aug" da mesma linha (publicada em 11 de agosto de 2026, boletim APSB26-92)
- Exploração
- No CISA KEV (incluída em 24 de setembro de 2026, prazo de correção até 27 de setembro), marcada como exigindo triagem forense
Quão perigoso é esperar?
Não exigir autenticação nem interação do usuário significa que toda loja exposta à internet é alcançável. A estimativa do EPSS, de cerca de 90%, a coloca entre os 0,3% superiores de todas as CVEs. Sites de comércio eletrônico guardam dados de clientes e processam pagamentos, o que há muito os torna alvos prioritários de ataques automatizados. "Somos uma loja pequena" não faz diferença para algo que varre a internet indiscriminadamente.
Que tipo de falha é?
A autorização decide se quem faz a chamada pode executar esta ação ou ver estes dados. É uma questão separada de saber se a pessoa conseguiu fazer login (autenticação), e uma falha na decisão de autorização deixa funções e dados ao alcance de quem não deveria ter acesso. A diferença está explicada em autenticação vs. autorização.
A CVE-2026-71362 é uma falha desse tipo (CWE-863), que a Adobe classifica como escalonamento de privilégios. Seu vetor CVSS inclui PR:N — classificada como explorável por alguém que não está logado — com alto impacto na confidencialidade e na integridade. Este site não descreve como ela é explorada.
11 de agosto — correção lançada (APSB26-92)
Prioridade 2 / "sem conhecimento de exploits" → muitas lojas poderiam razoavelmente adiar para a próxima atualização programada
18 de agosto — boletim atualizado pela última vez
A nota sobre exploração não mudou desde então
24 de setembro — CISA inclui no KEV (prazo em 27 de setembro)
Exploração confirmada. Lojas sem correção podem ter sido alvo antes desta data
Quem é afetado
| Produto | Afetado | Corrigido |
|---|---|---|
| Adobe Commerce | 2.4.9 / 2.4.8 / 2.4.7 / 2.4.6 / 2.4.5 / 2.4.4, cada um em 2026-jul e anteriores | 2026-aug da mesma linha |
| Adobe Commerce B2B | 1.5.3 / 1.5.2 / 1.4.2 / 1.3.4 / 1.3.3, cada um em 2026-jul e anteriores | 2026-aug da mesma linha |
| Magento Open Source | 2.4.9 / 2.4.8 / 2.4.7 / 2.4.6, cada um em 2026-jul e anteriores | 2026-aug da mesma linha |
| Linhas antigas | A NVD lista as versões anteriores à 2.4.4 como afetadas | Sem correção — migre para uma linha suportada |
O mesmo boletim corrige outras seis vulnerabilidades
O APSB26-92 corrige sete problemas no total, incluindo XSS armazenado e outras falhas de autorização. Apenas a CVE-2026-71362 está no KEV, mas a atualização fecha os sete de uma vez. Atualizar é mais rápido do que buscar soluções paliativas para cada problema.
O que fazer
Atualize para a versão 2026-aug da sua linha (primeira prioridade)
Confirme a linha e o nível de patch da sua loja, depois atualize para a versão 2026-aug dessa linha e confirme que a versão em execução mudou. Se você mantém vários ambientes — produção, homologação, uma antiga vitrine reserva — tudo o que é acessível pela internet está no escopo. A loja antiga esquecida é a que tem menor chance de ser corrigida (checklist de inventário de segurança).
Em uma linha sem suporte, coloque a migração na agenda de hoje
Linhas anteriores à 2.4.4 não recebem correção. A migração leva tempo, então, enquanto isso, restrinja quem pode acessar os pontos de entrada do admin e da API e ative proteções de WAF para reduzir quem consegue alcançar sua loja. Isso reduz o risco no período, mas não corrige a falha; só a migração faz isso.
Verifique se a loja foi invadida enquanto estava sem correção
Se a loja ficou sem correção em qualquer momento após 11 de agosto, trate esse intervalo como suspeito; a CISA também indica que esta CVE exige triagem forense. No mínimo: (1) Contas de administrador — quaisquer contas que você não reconheça ou com permissões alteradas. (2) Integrações e tokens de API — quaisquer itens que você não tenha criado ou tokens emitidos recentemente. (3) Arquivos e configurações — especialmente scripts carregados no checkout e HTML e configurações editáveis pelo painel admin (em comprometimentos de e-commerce, o objetivo típico é plantar um script que roube dados de pagamento). (4) Logs — acesso a funções de admin ou API a partir de origens incomuns, em horários incomuns ou em volume incomum.
Se algo parecer errado, troque as credenciais em conjunto
Se você não consegue descartar uma invasão, redefina as senhas de administrador, os tokens de integração e as chaves de pagamento e de APIs externas, e invalide todas as sessões. A correção fecha a falha; ela não revoga credenciais ou chaves que já tenham sido roubadas. Corrigir a falha e remover um invasor são tarefas separadas. O processo completo está em o playbook de remediação de vulnerabilidades.
Pare de esperar pela 'próxima atualização'
Como neste caso, uma atualização considerada não urgente na publicação pode se tornar urgente depois. Receba notificações quando algo for incluído no KEV (os alertas de vulnerabilidade deste site são uma forma de fazer isso), ou aplique atualizações de segurança fora do ciclo regular de atualizações.
Visão deste site: a 'prioridade 2' não estava errada. Apenas nunca foi atualizada
Culpar a classificação da Adobe na publicação ignora o ponto principal. Se nenhuma exploração tivesse sido observada quando ela foi lançada, uma prioridade mais baixa era uma decisão razoável. O problema é que a classificação continua inalterada no boletim enquanto os leitores a tratam como atual.
Essa estrutura não é exclusiva da Adobe. A severidade do fornecedor (CVSS, prioridade) descreve a falha em si; o KEV e o EPSS descrevem se ela está sendo alvo agora. A primeira é definida uma vez, na publicação, e não muda; a segunda muda diariamente. Por isso este site recomenda que a ordem de aplicação de correções não seja decidida uma única vez na publicação, mas reavaliada conforme o KEV e o EPSS mudam. Quarenta e quatro dias é o tempo que uma loja ficou exposta sem essa reavaliação.
Fontes
- Adobe — Security update available for Adobe Commerce | APSB26-92 (publicado em 11 de agosto de 2026, última atualização em 18 de agosto; versões afetadas e corrigidas, prioridade, CVSS e a nota "sem conhecimento de exploits")
- NVD — CVE-2026-71362 (CWE-863, CVSS v3.1 9.1; as configurações afetadas incluem versões anteriores à 2.4.4)
- CISA KEV — Known Exploited Vulnerabilities Catalog (incluída em 24 de setembro de 2026, prazo em 27 de setembro, triagem forense exigida)
- FIRST — EPSS (0,896 em 25 de setembro de 2026, 99,78º percentil)
Leia a seguir
- Para decidir: Priorizando com CVSS, EPSS e KEV / O playbook de remediação de vulnerabilidades
- Como funciona: Autenticação vs. autorização / O que é IDOR?
- O caso contrastante: CVE-2026-87902 (WordPress core: no KEV três dias após a correção)
- Outro alerta sobre Magento: CVE-2026-45247 (RCE sem autenticação em uma extensão do Magento)
- Termos: O que é CVSS? / O que é PCI DSS?