CVE-2019-9875

Falha de desserialização insegura (CWE-502) no módulo Sitecore.Security.AntiCSRF do Sitecore CMS e Experience Platform (XP), presente em todas as versões até a 9.1. Um atacante já autenticado envia um objeto .NET serializado dentro do parâmetro POST __CSRFTOKEN, e o servidor o desserializa sem validação, resultando em execução arbitrária de código no contexto do processo do Sitecore. A CISA incluiu a falha no catálogo KEV em março de 2025, confirmando exploração ativa mesmo anos após a publicação original.

O ponto de falha é o processamento do token anti-CSRF: o valor recebido no campo __CSRFTOKEN de uma requisição HTTP POST é desserializado pelo módulo Sitecore.Security.AntiCSRF antes de qualquer verificação de integridade ou tipo. Isso é uma instância clássica de CWE-502 (Deserialization of Untrusted Data) em .NET — o atacante controla o conteúdo serializado, e se a plataforma usar um formatter capaz de instanciar tipos arbitrários a partir da stream, é possível montar uma gadget chain que executa código no momento da desserialização, antes mesmo de qualquer lógica de negócio ser alcançada.

As fontes disponíveis não detalham qual formatter específico (BinaryFormatter, ObjectStateFormatter, etc.) nem qual gadget chain foi usada pela equipe da Synacktiv na publicação original — o PDF do advisory técnico não pôde ser lido integralmente aqui, então essa parte do mecanismo não deve ser assumida sem confirmação adicional.

O requisito de autenticação (PR:L no vetor CVSS) é central: a rota que processa o token exige uma sessão válida no Sitecore antes de aceitar o POST malicioso. Isso reduz a superfície de ataque a usuários com algum nível de acesso — não é uma falha pré-autenticação, apesar da gravidade do impacto (C:H/I:H/A:H).

O vetor é uma requisição HTTP POST autenticada para um endpoint do Sitecore que valida o token anti-CSRF, substituindo o valor legítimo de __CSRFTOKEN por um payload de objeto .NET serializado malicioso. A complexidade de ataque é considerada baixa (AC:L) e não exige interação da vítima (UI:N) — o próprio atacante dispara a requisição contra a aplicação vulnerável, sem depender de engenharia social ou de terceiros.

Pré-requisito real: o atacante precisa de credenciais válidas no Sitecore (qualquer nível de privilégio autenticado, conforme PR:L), acesso de rede ao endpoint vulnerável e domínio sobre a construção do payload serializado — o que normalmente exige conhecimento das dependências carregadas pelo processo (.NET assemblies disponíveis) para montar uma gadget chain funcional. Não há exploração pré-autenticação documentada nas fontes consultadas.

A presença no catálogo KEV da CISA, com data de inclusão em 26/03/2025, confirma exploração em ambiente real, embora a CISA marque como "desconhecido" o uso da falha em campanhas de ransomware. O intervalo entre a publicação original (2019) e a inclusão no KEV (2025) sugere que instâncias antigas e não corrigidas do Sitecore continuam expostas e sendo alvo de varredura/exploração ativa anos depois.

O fornecedor publicou orientação de correção no artigo de base de conhecimento KB0038556 (support.sitecore.com), referenciado pela CISA como a fonte de mitigação oficial. As fontes consultadas aqui não continham o conteúdo desse KB nem um número de versão de correção confirmado — portanto não é possível afirmar com segurança qual versão específica do Sitecore CMS/XP resolve a falha; o caminho correto é consultar diretamente o KB0038556 e o portal de downloads do Sitecore (dev.sitecore.net) para a versão vigente do produto em uso.

Como a exploração exige autenticação, um controle compensatório real é restringir e monitorar contas com acesso ao painel/admin do Sitecore, reduzir o número de usuários com permissão de POST nos endpoints afetados, e aplicar segmentação de rede para limitar quem alcança a instância. Isso não substitui o patch — apenas reduz a probabilidade de uma conta comprometida ser usada como trampolim para RCE.

Não funciona como mitigação: apenas trocar ou invalidar tokens CSRF existentes, pois o problema não está na validade do token, e sim no processo de desserialização do valor recebido. WAFs genéricos podem ajudar a bloquear payloads binários típicos de objetos .NET serializados no campo __CSRFTOKEN, mas isso é detecção heurística, não correção da causa raiz.

Procure em logs de acesso web por requisições POST para endpoints do Sitecore contendo o parâmetro __CSRFTOKEN com conteúdo anormalmente longo ou com estrutura binária/serializada — um token anti-CSRF legítimo costuma ser um valor curto (hash ou GUID), não um blob de dados estruturado. Presença de caracteres não imprimíveis, padrões de assembly .NET ou strings de namespace dentro do valor do campo é um indício forte de tentativa de exploração.

As fontes disponíveis não trazem uma assinatura de IDS/IPS oficial nem indicadores de comprometimento publicados pelo fornecedor ou pela CISA para esta CVE especificamente — na ausência de assinatura confirmada, a análise de payloads anômalos no campo __CSRFTOKEN em requisições autenticadas é o sinal mais confiável disponível.