CVE-2019-10068

Falha crítica no serviço de staging do Kentico CMS/Xperience (versões 9.x, 10.0.x antes de 10.0.52, 11.0.x antes de 11.0.48 e 12.0.x antes de 12.0.15) permite a um atacante não autenticado enviar uma requisição forjada que contorna a validação dos cabeçalhos de segurança do serviço de sincronização de staging e, em seguida, força a deserialização de um objeto .NET controlado pelo atacante. O resultado é execução remota de código sem autenticação no servidor onde o Kentico está hospedado — por isso o CVSS 9.8 e a presença no catálogo KEV da CISA, com exploração confirmada, PoC pública, módulo Metasploit e template Nuclei disponíveis.

O componente vulnerável é o serviço de staging do Kentico, usado para sincronizar conteúdo entre instâncias (staging/produção) via requisições HTTP que carregam objetos serializados .NET. O serviço deveria autenticar cada requisição validando cabeçalhos de segurança específicos antes de processar o payload. A falha (CWE-502, Deserialization of Untrusted Data) está em como esses cabeçalhos são checados: uma requisição especialmente construída consegue passar pela verificação de autenticação sem credenciais válidas.

Uma vez que o atacante contorna esse gate de autenticação, o endpoint de staging segue para deserializar o corpo da requisição usando um formatter .NET (padrão do problema clássico de deserialização insegura no .NET Framework, como BinaryFormatter/NetDataContractSerializer ou LosFormatter, comuns nesse tipo de vulnerabilidade em CMS ASP.NET). O atacante controla integralmente o payload serializado, podendo montar uma cadeia de gadgets (ex.: via ysoserial.net) que, ao ser desserializada, instância objetos com efeitos colaterais arbitrários — nesse caso, execução de comando no contexto do processo do IIS/worker que hospeda o Kentico.

O ponto crítico é que a validação de cabeçalho que deveria impedir acesso anônimo ao endpoint de staging é o único controle de acesso; não há camada de autenticação adicional no fluxo de deserialização. Quebrado esse controle, não existe segunda barreira entre a requisição de rede e a execução de código nativo do .NET.

O vetor é uma requisição HTTP direta ao endpoint do serviço de staging exposto pela aplicação Kentico, sem necessidade de conta, sessão ou qualquer interação do usuário — condição que casa com AV:N/PR:N/UI:N do vetor CVSS. O único pré-requisito real é que o serviço de staging esteja habilitado e acessível na instância (staging sync é um recurso opcional do produto, mas em muitas instalações fica ativo e exposto por padrão ou por configuração legada).

Na prática, o atacante forja os cabeçalhos que o serviço espera para autenticação, contornando a checagem, e envia no corpo da requisição um objeto .NET serializado malicioso construído com uma gadget chain de deserialização conhecida. A exploração é considerada de baixa complexidade (AC:L) porque toolkits públicos (PoC no Packet Storm, módulo Metasploit, template Nuclei) automatizam tanto a descoberta do endpoint vulnerável quanto a geração do payload.

A CISA confirma exploração ativa em campo (presença no catálogo KEV desde 2022-03-25, prazo de correção 2022-04-15), e o EPSS alto (~0,96) reflete probabilidade elevada de tentativas de exploração observadas na internet. O resultado final é RCE completo no contexto do processo do servidor web, geralmente equivalente a comprometimento total do host que hospeda o Kentico.

A correção do fornecedor é atualizar para a versão com hotfix que corrige a validação dos cabeçalhos de segurança do serviço de staging: 12.0.15 ou superior (ramo 12.0.x), 11.0.48 ou superior (ramo 11.0.x), 10.0.52 ou superior (ramo 10.0.x). Para instâncias em versões 9.x, o advisory original não especifica um hotfix numerado equivalente — o fornecedor recomenda migração para uma versão suportada; instalações 9.x devem ser tratadas como fim de linha para efeito de patch e priorizadas para upgrade completo.

Um indicador direto é a busca por regras de detecção conhecidas: o template Nuclei público para CVE-2019-10068 e o módulo Metasploit correspondente definem a assinatura exata da requisição de exploração (path do serviço de staging combinado com cabeçalhos de autenticação forjados e corpo com objeto .NET serializado) — rodar esse template contra logs de WAF/proxy ou usá-lo defensivamente para validar exposição é o caminho mais confiável. Não há um único indicador de payload universal porque a exploração usa gadget chains variáveis, mas requisições POST ao endpoint de staging vindas de IPs externos sem sessão de staging previamente configurada, ou corpos de requisição contendo strings típicas de serialização .NET (namespaces de assembly, marcadores binários do BinaryFormatter), são sinais fortes de tentativa de exploração.