CISA põe falhas de WSO2 e Adobe Commerce na lista de exploradas

A agência americana de cibersegurança CISA incluiu na quinta-feira (24) duas falhas críticas no seu catálogo de vulnerabilidades exploradas ativamente, o KEV: a CVE-2026-5430, que afeta produtos de gestão de APIs da WSO2, e a CVE-2026-71362, no Adobe Commerce e no Magento Open Source. A inclusão se baseia em evidência de exploração em ataques reais, segundo o aviso da agência, e dá às agências civis federais dos EUA até 27 de setembro para aplicar as correções.

Nenhuma organização foi identificada publicamente como vítima dos ataques até o fechamento desta matéria.

WSO2: a porta de entrada das APIs

A CVE-2026-5430 atinge o WSO2 API Manager nas versões 4.1.0 a 4.6.0, o API Control Plane e o Traffic Manager nas versões 4.5.0 e 4.6.0 e o Universal Gateway nas mesmas versões. O catálogo da CISA registra a falha como path traversal. Análises técnicas de pesquisadores descrevem um mecanismo diferente: um desvio de autenticação em que o sistema, ao receber um token JWT assinado com algoritmo não suportado, deixa de verificar a assinatura e aceita as credenciais como legítimas. Nas duas leituras, o resultado é o mesmo, com possibilidade de tomada de contas administrativas.

A empresa de segurança watchTowr relatou tentativas de exploração contra seus honeypots desde pelo menos 13 de setembro, segundo o The Hacker News. Ou seja, a janela entre o primeiro ataque observado e a inclusão no catálogo foi de 11 dias.

O peso da falha vem da função do produto. Um gateway de APIs fica na borda da arquitetura, autenticando chamadas entre sistemas internos, parceiros e aplicativos. A WSO2, empresa de origem cingalesa com operações nos EUA e na Europa, vende essa camada para bancos, operadoras e governos, que a usam justamente para expor serviços a terceiros. Uma credencial administrativa forjada nesse ponto dá acesso ao inventário de APIs e às políticas que controlam quem pode chamar o quê.

Adobe Commerce: sessão trocada, conta tomada

A CVE-2026-71362 tem nota CVSS 9.1 e é classificada como autorização incorreta. Segundo a Sansec, empresa especializada em segurança de comércio eletrônico, o problema está no tratamento da identidade do cliente dentro de uma sessão ativa: um atacante sem autenticação consegue trocar a sessão para a de outro cliente e assumir a conta, com acesso a dados pessoais e histórico de pedidos.

A Adobe publicou a correção no boletim APSB26-92, em 11 de agosto, com versões corrigidas para o Adobe Commerce 2.4.4 a 2.4.9, o Magento Open Source 2.4.6 a 2.4.9 e o Commerce B2B 1.3.3 a 1.5.3. O boletim corrigiu sete vulnerabilidades, cinco delas críticas.

A Sansec informou ter detectado e bloqueado as primeiras tentativas de exploração logo após a publicação do boletim, ainda em agosto. A inclusão no KEV, seis semanas depois, formaliza a leitura: para a CISA, há exploração real.

Seis semanas é tempo suficiente para que lojas com processo maduro já tenham aplicado a correção, e insuficiente para as demais. Em ambientes com personalizações pesadas, comuns no varejo, cada patch passa por testes de regressão antes de subir, e o calendário de manutenção raramente acompanha o calendário dos atacantes, que começaram a testar a falha em questão de dias.

Onde o risco se espalha

O prazo de 27 de setembro vale apenas para o governo federal americano, mas o catálogo KEV funciona como referência de priorização para equipes de segurança privadas em vários países. A falha da WSO2 já recebeu alertas na imprensa especializada da Austrália, e a do Adobe Commerce foi tratada em avisos de universidades e de consultorias de e-commerce nos EUA e na Europa.

No varejo, o Magento mantém base relevante de lojas de médio porte na Europa e na América Latina, incluindo o Brasil, muitas delas operadas por agências e integradores terceirizados. Nesse modelo, o patch depende de um contrato de suporte que nem sempre prevê resposta emergencial. A pergunta para o CISO de varejo é quem, na cadeia de fornecedores, aplicou o APSB26-92, e quando.

Para bancos e fintechs que expõem APIs via WSO2, a verificação é mais direta: a versão em produção, a data do último patch e os registros de autenticação desde 13 de setembro. Um token aceito sem assinatura válida não deixa o mesmo rastro de um login com senha errada, e a auditoria precisa procurar por isso especificamente.