CVE-2022-22965

What is Spring Framework?

Spring Framework is the most widely used Java application framework in the world, underpinning millions of enterprise web applications globally. Spring MVC and Spring WebFlux are its web layer components, used to build REST APIs and web applications. "Spring4Shell" — the nickname for CVE-2022-22965 — is named in homage to Log4Shell (CVE-2021-44228), reflecting the similarly sweeping impact of a critical vulnerability in ubiquitous infrastructure.

Overview

CVE-2022-22965 (Spring4Shell) is a remote code execution vulnerability in Spring MVC and Spring WebFlux applications running on JDK 9 or later when deployed as a WAR file on Apache Tomcat. An unauthenticated attacker can exploit Spring's data binding feature to access the Java ClassLoader via parameter manipulation, write a JSP webshell to the Tomcat working directory, and achieve arbitrary code execution. CVSS 9.8 (Critical). A PoC was leaked on Chinese social media before VMware/Spring could coordinate a patch release, triggering mass exploitation. CISA added it to KEV on April 4, 2022 — three days after the formal advisory.

Affected Versions

Required conditions for exploitation:

• JDK 9 or later (not JDK 8)
• Deployed as WAR on Apache Tomcat (not as a standalone Spring Boot JAR)
• Uses Spring MVC or WebFlux with standard data binding

Technical Details

Spring MVC's data binding feature maps HTTP request parameters directly to Java object properties. The vulnerability exploits how Java's module system (introduced in JDK 9 via JPMS) changed the accessibility of class members.

The attack chain:

1. Spring's data binding allows property access via dot notation: ?user.name=foo maps to setName("foo")
2. In JDK 9+, the ClassLoader is accessible through Java's module system via class.module.classLoader
3. Tomcat's StandardClassLoader contains a reference to the Tomcat servlet context
4. An attacker crafts HTTP parameters to traverse: class.module.classLoader.resources.context.parent.pipeline.first
5. This reaches Tomcat's AccessLogValve which can be configured to write arbitrary content to arbitrary files
6. The attacker configures the log valve to write a JSP webshell to the Tomcat webapps root directory
7. A subsequent request to the written JSP executes arbitrary OS commands

Full exploit requires two HTTP requests: one to configure the Tomcat log valve, one to write the webshell, and a third to execute commands.

Discovery

The vulnerability was independently discovered by multiple researchers. A PoC was first leaked on GitHub (attributed to a Chinese security researcher's private repository) on March 29, 2022, before VMware had coordinated the patch — triggering an emergency response. VMware published a pre-patch advisory and rushed out patches within 2 days.

Exploitation Context

Spring4Shell triggered a widespread incident response event comparable to Log4Shell. Given Spring MVC's ubiquity, nearly every Java enterprise environment had to triage exposure. However, the exploitation conditions — JDK 9+, WAR deployment on Tomcat — significantly narrowed actual exposure compared to the initial panic:

• Standalone Spring Boot JARs: not vulnerable (different class loader hierarchy)
• JDK 8: not vulnerable (module system not present)
• Other servlet containers: not directly vulnerable via the Tomcat log valve mechanism, though other gadgets may exist

Actual exploitation in the wild focused on:

• Cryptomining via webshell deployment
• Scanning and fingerprinting of vulnerable instances
• Initial access for ransomware and espionage campaigns in environments running WAR-deployed Spring apps on modern JDKs

Remediation

1. Upgrade Spring Framework: Update to 5.3.18 or 5.2.20. Spring Boot users: update to Spring Boot 2.6.6 or 2.5.12 which pull in the fixed Spring Framework version.
2. Upgrade JDK to a version where the data binding path is blocked: The Spring patch adds class to the list of disallowed field patterns in DataBinder.
3. WAR vs JAR deployment: Standalone Spring Boot JARs (the default deployment model) are not vulnerable via this mechanism — consider migrating from WAR to JAR deployment.
4. WAF rules: Block requests containing class.module.classLoader, class.classLoader, and similar patterns in request parameters.
5. Tomcat hardening: Disable the AccessLogValve if not required for logging, or configure its log directory to a non-web-accessible location.
6. Verify exposure: Use spring-framework-rce-poc or similar tools to check if your specific deployment configuration is vulnerable before assuming all Spring apps are affected.