XStream is vulnerable to a Remote Command Execution attack

Falha de desserialização insegura na biblioteca Java XStream (antes da versão 1.4.18): ao converter XML de volta em objetos Java, a lib usava por padrão uma blacklist de classes perigosas que pesquisadores conseguiram contornar, permitindo que um XML malicioso instancie classes Java arbitrárias e leve à execução de comandos no host. Importa porque XStream é embutida em diversos produtos (o caso documentado é o VMware NSX Manager) e a vulnerabilidade real só se manifesta na aplicação que expõe o parsing ao atacante — a biblioteca isolada não tem superfície de rede própria.

O núcleo do problema é CWE-502 (Deserialization of Untrusted Data) combinado com CWE-94 (Code Injection): XStream.fromXML() e métodos equivalentes de unmarshalling reconstroem grafos de objetos Java a partir de um documento XML fornecido externamente, resolvendo nomes de classe presentes no próprio XML. Antes da 1.4.18, o 'security framework' da biblioteca operava por blacklist — uma lista de classes conhecidas como perigosas (gadgets de RCE, SSRF, DoS) que era bloqueada por padrão, mas todo o restante do classpath ficava permitido.

Essa blacklist provou-se estruturalmente insuficiente: cada nova CVE do XStream nesse período (2020-2021) — e há uma dezena delas, incluindo CVE-2021-21341 até 21351, 2021-29505 e a série 2021-39139 a 39154 — corresponde a um novo gadget ou técnica que escapa da lista negra vigente. CVE-2021-39144 é um desses casos: input XML manipulado leva à instanciação de uma classe que, direta ou indiretamente, executa comandos do sistema operacional hospedeiro.

O atacante controla o conteúdo do documento XML processado pela chamada de unmarshalling — em outras palavras, qualquer campo, upload ou payload de API que a aplicação passe para XStream.fromXML(). O que ele não controla diretamente é o código executado: ele precisa referenciar uma classe já presente no classpath (Java runtime ou biblioteca de terceiros) que sirva de 'gadget' para a operação final.

O vetor é rede: o atacante envia ao serviço vulnerável um documento XML malicioso que a aplicação desserializa via XStream sem whitelist restritiva. Não é uma falha explorável isoladamente na biblioteca — depende inteiramente de onde e como a aplicação hospedeira expõe esse parsing. No caso documentado publicamente (VMware NSX Manager), o writeup da Packet Storm descreve exploração sem autenticação, apesar do vetor CVSS oficial do GitHub Advisory indicar PR:L (privilégio baixo necessário) — divergência que reforça que o requisito de autenticação real depende do produto que embute XStream, não da CVE em si.

A pré-condição decisiva, segundo o próprio advisory do fornecedor, é negativa: só está exposto quem NÃO configurou o security framework do XStream com uma whitelist (allowTypes) restrita aos tipos mínimos necessários para a aplicação. Quem seguiu essa recomendação — disponível desde versões anteriores — não é afetado, independentemente da versão instalada.

O resultado final documentado é execução de comandos no host (RCE), consistente com o alto EPSS e a presença confirmada no catálogo KEV da CISA, além de módulo Metasploit e template Nuclei públicos, o que indica exploração automatizada e em massa contra instâncias expostas — tipicamente appliances de gestão (como NSX Manager) que consomem XML via API sem endurecer a configuração do XStream.

A correção do fornecedor é atualizar para XStream 1.4.18 ou posterior, versão em que o modelo de segurança deixou de usar blacklist e passou a negar por padrão todo tipo não explicitamente permitido (whitelist). Isso é uma mudança de comportamento, não apenas patch: aplicações que dependem de desserializar tipos amplos podem quebrar após o upgrade e precisarão declarar explicitamente os tipos permitidos via a API de segurança do XStream.

Se a atualização não for viável de imediato, o paliativo real — e o único reconhecido pelo próprio fornecedor como suficiente mesmo em versões antigas — é configurar o security framework do XStream com uma whitelist limitada aos tipos mínimos necessários para a aplicação, em vez de confiar na blacklist padrão. O custo é engenharia: mapear e testar todos os tipos legitimamente desserializados pela aplicação, o que pode ser trabalhoso em sistemas legados com muitos objetos diferentes trafegando por XML.

Não funciona como mitigação apenas atualizar para uma versão intermediária pré-1.4.18 mais recente supondo que a blacklist ficou 'boa o suficiente' — o histórico de CVEs sucessivas do XStream nesse período mostra que cada blacklist foi superada por um novo gadget. Trocar de blacklist para blacklist não resolve a classe do problema; só a whitelist (nativa a partir da 1.4.18, ou configurada manualmente antes disso) resolve estruturalmente.

Não há assinatura única confiável, porque o payload varia por gadget/classe explorada e pela aplicação hospedeira. Em logs de aplicações que usam XStream, procure requisições com corpo XML contendo elementos referenciando nomes de classe Java fora do domínio de negócio esperado (pacotes como java.lang, javax.*, com.sun.*, ou bibliotecas de terceiros presentes no classpath) — a presença de nomes de classe totalmente qualificados dentro de um payload XML de entrada é, por si, um indicador de tentativa de abuso de desserialização do XStream, mesmo quando a tentativa falha.

No caso específico de produtos como VMware NSX Manager, monitorar chamadas às APIs de gestão que aceitam XML e correlacionar com processos filhos inesperados criados pelo processo Java do serviço (indicativo de execução de comando pós-desserialização) é um sinal mais forte que a inspeção isolada do payload.