CVE-2022-22965

Falha de code injection (CWE-915, modificação não controlada de atributos de objeto) no data binding do Spring Framework, que ficou conhecida como Spring4Shell. Permite RCE remota e não autenticada, mas apenas sob um conjunto específico de pré-condições — JDK 9+, deploy como WAR em Tomcat e dependência de spring-webmvc ou spring-webflux — o que faz o impacto real ser muito menor do que o CVSS 9.8 sugere para a maioria dos deploys Spring Boot padrão (jar executável embutido).

O Spring DataBinder permite vincular parâmetros de requisição HTTP a propriedades de objetos Java expostos por um controller (o clássico padrão de data binding do Spring MVC/WebFlux). O problema é que esse binding, se não restringido, alcança propriedades encadeadas via getters/setters de reflexão — incluindo a cadeia class.classLoader, que no JDK 9+ passou a expor métodos adicionais no ClassLoader que não existiam (ou eram protegidos) em versões anteriores do Java.

Em um deploy WAR sob Apache Tomcat, essa cadeia dá acesso ao ClassLoader do próprio Tomcat, e a partir dele é possível alcançar objetos internos do container, como o AccessLogValve. Manipulando propriedades desse Valve (padrão de log, diretório, prefixo, sufixo, formato de data) via parâmetros de request, um atacante consegue fazer o Tomcat escrever um arquivo controlado por ele em um local dentro do diretório da aplicação web — efetivamente um write primitivo arbitrário disfarçado de configuração de logging.

É essencialmente uma reincidência de uma vulnerabilidade antiga do Spring (CVE-2010-1622), que havia sido mitigada mas voltou a ser explorável por causa da mudança de superfície do ClassLoader no JDK 9+ combinada com o comportamento padrão de exposição de propriedades encadeadas do DataBinder.

O atacante controla os valores dos parâmetros de request que o binder mapeia para as propriedades do objeto de destino; não precisa de nenhum input privilegiado, upload de arquivo ou endpoint administrativo — qualquer controller com data binding ativo em um objeto exposto é superfície potencial.

O vetor é uma requisição HTTP simples (GET ou POST) para qualquer endpoint da aplicação que faça data binding de parâmetros para um objeto — não precisa ser um endpoint sensível, qualquer form-backed object ou @ModelAttribute serve como porta de entrada. Não há autenticação envolvida na maioria dos casos documentados, o que torna a exploração pré-autenticação quando as pré-condições de ambiente são atendidas.

As pré-condições reais, e a informação mais importante da página, são: JDK 9 ou superior, Apache Tomcat como servlet container, aplicação empacotada como WAR (não como jar executável do Spring Boot, que é o padrão), e dependência direta de spring-webmvc ou spring-webflux. A VMware afirma explicitamente que a distribuição padrão do Spring Boot (jar executável) não é vulnerável a esse exploit específico, embora reconheça que a falha é mais geral e outros vetores de exploração podem existir fora desse cenário.

Uma vez satisfeitas as condições, o resultado documentado publicamente é escrita de um arquivo (tipicamente uma JSP webshell) dentro do diretório da aplicação via manipulação das propriedades do AccessLogValve do Tomcat, seguida de uma segunda requisição para acessar esse arquivo e obter execução de comando com os privilégios do processo do Tomcat. A CVE está no catálogo KEV da CISA — houve exploração ativa confirmada em campo, curto tempo entre disclosure e exploração massiva, e existe módulo Metasploit, template Nuclei e PoC pública, o que tornou a varredura em massa trivial nos dias seguintes ao anúncio.

A correção do fornecedor é atualizar o Spring Framework para 5.3.18 ou 5.2.20 (ou versões posteriores dessas ramificações). Segundo a VMware, nenhuma etapa adicional é necessária após o upgrade — a correção trata a causa raiz no data binder.

Quando o upgrade imediato não é viável, o próprio blog de anúncio antecipado da Spring (referenciado pela VMware) lista mitigações alternativas para quem não pode atualizar de imediato; essa página não reproduz os detalhes técnicos exatos dessas mitigações porque não estavam nas fontes lidas — consulte o post oficial 'Spring Framework RCE Early Announcement' para os passos específicos (customização de WebDataBinder, restrição de campos permitidos no binding, etc.).

O que não resolve por si só: apenas trocar de JDK 9+ para uma versão anterior não é uma mitigação suportada oficialmente, e depender exclusivamente do fato de 'estar em Spring Boot com jar executável' como mitigação é arriscado — a VMware é explícita que a falha é mais ampla que o exploit demonstrado contra WAR/Tomcat, e outros vetores podem existir. Ambientes com WAF podem tentar bloquear padrões de parâmetros como 'class.module.classLoader' ou 'class.classLoader' nas requisições como controle compensatório temporário, mas isso é paliativo e contornável, não substitui o patch.

Em logs de acesso do Tomcat ou do WAF, procurar requisições HTTP (GET/POST) contendo parâmetros com os prefixos 'class.module.classLoader' ou 'class.classLoader' seguidos de propriedades como 'resources.context.parent.pipeline' — esse é o padrão característico usado nos PoCs públicos para alcançar o AccessLogValve do Tomcat. A presença de arquivos JSP inesperados recém-criados em diretórios da aplicação web, especialmente com nomes ou conteúdo incomuns, é outro indicador forte de exploração bem-sucedida (webshell plantado via write primitivo).

Como o vetor pode variar (a própria VMware reconhece que existem outras formas potenciais de exploração), a ausência desses padrões específicos nos logs não garante que não houve tentativa — trate a superfície do data binding como ponto amplo, não como assinatura única confiável.