Adobe Commerce | Improper Input Validation (CWE-20)

Falha de validação de entrada (CWE-20) na API REST do Adobe Commerce e Magento Open Source que permite a um atacante não autenticado assumir o controle de contas de clientes — segundo a Adobe, sem execução de código confirmada. Pesquisadores batizaram a falha de 'SessionReaper' e apontam que, em ambientes com sessão baseada em arquivo, o mesmo vetor pode escalar para execução remota de código, algo que a Adobe não confirma oficialmente. Está no catálogo KEV da CISA com exploração ativa confirmada, apesar de a Adobe ter afirmado inicialmente não ter evidência de exploração — a linha do tempo (KEV adicionado em 24/10/2025, mais de um mês após o advisory de 09/09/2025) sugere que a exploração começou depois da divulgação, provavelmente via engenharia reversa do patch.

A causa raiz, segundo análise técnica de terceiros (não confirmada literalmente pela Adobe em nível de código), está no método getConstructorData() da classe Magento\Framework\Webapi\ServiceInputProcessor, responsável por converter payloads de API em parâmetros de construtor de objetos. O método valida corretamente tipos escalares (string, int, float, bool) e interfaces de dados da API (*\Api\Data\*Interface), mas não aplica validação estrita a objetos aninhados complexos enviados no corpo da requisição, permitindo que a rotina de desserialização processe estruturas arbitrárias em vez de rejeitá-las.

O atacante controla o payload JSON enviado a endpoints REST (a Adobe cita explicitamente a API de clientes, ex.: /rest/V1/customers/*). Ao embutir um objeto aninhado malicioso onde o serviço espera uma estrutura simples, é possível manipular dados de sessão. Pesquisadores associam esse comportamento a padrões de object injection já vistos em falhas anteriores do Magento, como CosmicSting (2024).

O CVSS oficial (C:H/I:H/A:N) reflete o que a Adobe reconhece: comprometimento de confidencialidade e integridade via sequestro de sessão/conta, sem impacto direto em disponibilidade. A afirmação de terceiros de que a falha permite RCE completa depende de uma pré-condição específica — armazenamento de sessão baseado em arquivo (var/session/sess_*) explorável via unserialize() do PHP e gadget chains disponíveis no ambiente — e não é endossada pelo advisory da Adobe, que fala apenas em 'session takeover'.

A falha também atinge o módulo separado Custom Attributes Serializable (magento/out-of-process-custom-attributes), usado em arquiteturas de atributos customizados fora de processo, o que indica que o problema de validação se propaga por mais de um componente do ecossistema Commerce.

O vetor é a API REST (a Adobe também cita GraphQL e SOAP em análises de terceiros) exposta publicamente por qualquer loja Adobe Commerce/Magento em produção. O vetor CVSS (AV:N/AC:L/PR:N/UI:N) indica que não é necessária autenticação prévia nem interação do usuário — o atacante envia requisições HTTP diretamente ao endpoint vulnerável pela rede, o que explica a criticidade alta mesmo sem escalonamento a RCE.

Na prática relatada por pesquisadores, a exploração envolve criar um objeto PHP serializado malicioso e embuti-lo em um campo aninhado de um payload de API (por exemplo, na atualização de dados de cliente), forçando o ServiceInputProcessor a desserializar essa estrutura em vez de rejeitá-la. O resultado mínimo documentado pela Adobe é sequestro de sessão/conta de cliente; a escalada a execução de código, quando descrita por terceiros, depende do backend de sessão ser baseado em arquivo e de existir uma cadeia de gadgets utilizável no código carregado — condição que não está presente em todo ambiente (sessões em Redis ou banco de dados reduzem, mas segundo a mesma análise não eliminam, o risco de sequestro de conta).

A Adobe afirmou em 09/2025 não ter evidência de exploração ativa. A CISA, ao incluir a CVE no catálogo KEV em 24/10/2025 com prazo de correção em 14/11/2025, confirma exploração em ambiente real — a divergência de datas sugere que a exploração se tornou viável e foi observada depois da publicação do advisory/patch, cenário comum quando atacantes fazem engenharia reversa do diff de correção.

Aplicar o hotfix isolado VULN-32437-2-4-X-patch (disponível em repo.magento.com), listado no boletim APSB25-88, para todas as versões afetadas de Adobe Commerce, Adobe Commerce B2B e Magento Open Source. Esse patch não é um bump de versão completo — é aplicado via ferramenta de patches da Adobe (Quality Patches Tool) sobre a instalação existente.

Se o ambiente usa o módulo Custom Attributes Serializable (magento/out-of-process-custom-attributes) nas versões 0.1.0 a 0.3.0, atualizar para 0.4.0 ou superior via composer (composer require magento/out-of-process-custom-attributes=0.4.0 --with-dependencies) — a Adobe trata isso como correção separada e necessária além do hotfix principal. Quem já está na versão 0.4.0 do módulo não precisa de ação adicional nesse componente.

Para clientes em Adobe Commerce on Cloud, a Adobe informa ter implantado regras de WAF para mitigar exploração, mas deixa claro que isso não substitui a aplicação do patch — a orientação oficial é aplicar todas as correções recomendadas, sob risco de o ambiente permanecer exposto mesmo com o WAF ativo. Não há mitigação sem custo real: reduzir exposição da API REST/GraphQL/SOAP a redes confiáveis diminui a superfície de ataque, mas quebra funcionalidades legítimas que dependem dessas APIs (integrações, apps mobile, checkout headless), então é paliativo temporário, não substituto do patch.

A própria Adobe reconhece na KB que não é simples determinar se o patch foi aplicado, e recomenda usar a Quality Patches Tool (vendor/bin/magento-patches -n status) para verificar se o patch isolado consta como 'Applied' no ambiente — o exemplo de comando fornecido pela Adobe na KB usa o identificador de outro patch (VULN-27015) apenas como ilustração de sintaxe, então o identificador real do patch desta CVE deve ser conferido na saída da ferramenta, não assumido.

As fontes consultadas não trazem assinaturas de rede ou padrões de log confirmados para detecção de tentativas de exploração desta CVE especificamente. Como ponto de partida razoável (não uma assinatura validada), vale monitorar requisições anômalas aos endpoints REST/GraphQL/SOAP de clientes (ex.: /rest/V1/customers/*) com corpos JSON contendo estruturas aninhadas incomuns ou não previstas pelo schema da API, e correlacionar com sequestro de sessão inexplicado (login em conta de cliente sem autenticação prévia correspondente nos logs de aplicação).