CVE-2022-22965 Explained: Spring4Shell, the Spring Framework RCE Vulnerability

Spring Framework's data binding feature maps HTTP request parameters to Java object properties using reflection. This includes not just simple properties but also nested properties accessible through getter chains. An attacker can supply HTTP parameters using Spring's dot-notation to traverse object property paths — including paths that reach sensitive Java runtime objects.

The specific exploitation path in CVE-2022-22965 chains through the Java ClassLoader. By supplying parameters like class.module.classLoader.resources.context.parent.pipeline.first.*, an attacker can access and modify properties of the Tomcat log handler, including the log file path, prefix, suffix, and the log pattern. By manipulating these properties, the attacker redirects Tomcat's access log to write to a JSP file in the web application's publicly accessible root directory.

Once the log file is redirected, the attacker sends a request containing JSP code in a header or parameter — which gets written into the log file (now a .jsp file). The JSP file is then requested directly, executing the embedded code as a web shell with the privileges of the Tomcat process.

This exploitation chain requires JDK 9 or later because the module system introduced in Java 9 changed ClassLoader accessibility. Spring's disallowed field list was also updated from earlier versions. Applications running on JDK 8 are not vulnerable via this specific chain.

When Spring4Shell dropped, the security industry feared a repeat of Log4Shell — a critical RCE in a foundational Java library with a trivial exploit and universal exposure. The actual impact was more contained, for structural reasons.

Log4Shell's exploit was a single malicious string that could be passed in virtually any user-controlled input field, with no contextual requirements beyond Log4j being present. Spring4Shell's exploitation chain has meaningful prerequisites: JDK 9 or later, deployment on Apache Tomcat as a WAR file, and Spring MVC with the standard data binding configuration.

Applications packaged as JAR files with the embedded Tomcat in Spring Boot's default configuration are not vulnerable via the main exploitation chain, because they do not use the separate Tomcat log file mechanism that the ClassLoader traversal targets. This excluded a large portion of modern Spring Boot applications from the most severe attack scenario.

Nonetheless, exploitation in the wild was confirmed rapidly. Threat actors including ransomware groups were observed scanning for and exploiting CVE-2022-22965 within days of public disclosure. Variants of the exploit targeting different ClassLoader paths and different deployment configurations were identified in subsequent weeks.

VMware and the Spring team released patches on March 31, 2022. The following steps address CVE-2022-22965 completely and provide defense-in-depth for environments where immediate patching is constrained.

Spring4Shell demonstrated that the security community learned important lessons from Log4Shell about rapid response to critical framework vulnerabilities — but also that exploitation sophistication and speed continue to accelerate. Proof-of-concept code was available within hours of disclosure, and active exploitation began within days.

The prerequisite conditions that limited Spring4Shell's blast radius compared to Log4Shell are real but not permanent. Researchers identified multiple alternative exploitation chains targeting different ClassLoader paths and different deployment configurations in the weeks following initial disclosure.

The only durable response is patching. Organizations running Spring Framework on JDK 9+ should treat any unpatched deployment as actively exploitable, audit their Java application portfolios for affected versions, and establish processes to discover Spring Framework versions embedded in application dependencies — including those bundled inside WAR files and Docker images.