CVE-2022-22965: VMware Spring Framework RCE Vulnerability

CVE-2022-22965 Overview

CVE-2022-22965, commonly known as "Spring4Shell," is a critical remote code execution vulnerability affecting VMware Spring Framework applications running on JDK 9 and later. This vulnerability allows unauthenticated attackers to execute arbitrary code on vulnerable systems through the data binding mechanism in Spring MVC or Spring WebFlux applications. The specific exploit requires the application to be deployed as a WAR file on Apache Tomcat, though the underlying vulnerability may be exploitable through other vectors.

Critical Impact
This vulnerability enables unauthenticated remote code execution on affected Spring Framework applications deployed on Tomcat with JDK 9+. Active exploitation has been observed in the wild, and this CVE is listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.

Affected Products

VMware Spring Framework (versions prior to 5.3.18 and 5.2.20)
Oracle JDK 9 and later versions
Cisco CX Cloud Agent
Oracle Communications Cloud Native Core (multiple components)
Oracle WebLogic Server (12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0)
Oracle Financial Services products (multiple)
Oracle Retail products (multiple)
Siemens Operation Scheduler, SIPASS Integrated, Siveillance Identity, SINEC NMS
Veritas NetBackup Appliance and related products

Discovery Timeline

April 1, 2022 - CVE-2022-22965 published to NVD
October 30, 2025 - Last updated in NVD database

Technical Details for CVE-2022-22965

Vulnerability Analysis

Spring4Shell exploits a flaw in the Spring Framework's data binding functionality when running on Java Development Kit (JDK) version 9 or higher. The vulnerability stems from changes introduced in JDK 9 that exposed the class.module.classLoader property through Spring's data binding mechanism. When an attacker sends specially crafted HTTP requests to a vulnerable application, they can manipulate the class loader to modify Tomcat's logging properties, ultimately achieving arbitrary file write capabilities that lead to remote code execution.

The attack specifically targets the AccessLogValve class in Apache Tomcat, allowing attackers to write a malicious JSP webshell to the web root directory. Once the webshell is deployed, attackers can execute arbitrary commands with the privileges of the Tomcat service account.

Root Cause

The root cause lies in how Spring Framework's data binding feature processes HTTP request parameters. In JDK 9+, the module system introduced new ways to access class properties that were not adequately restricted by Spring's existing security controls. The class.module.classLoader chain provides an attack path that allows modification of Tomcat's internal configuration through parameter binding, bypassing the blacklist that was implemented after the original CVE-2010-1622 vulnerability.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker sends a series of HTTP requests with specially crafted parameters that:

Access the class loader through the class.module.classLoader property chain
Modify Tomcat's AccessLogValve properties to change the log pattern, directory, prefix, and suffix
Write a JSP webshell to an accessible location within the web application
Execute arbitrary commands through the deployed webshell

## Dockerhub
docker pull bobtheshoplifter/spring4shell-poc:latest
docker run bobtheshoplifter/spring4shell-poc:latest --url https://example.io/
## Github docker repository
docker pull ghcr.io/bobtheshoplifter/spring4shell-poc:main
docker run ghcr.io/bobtheshoplifter/spring4shell-poc:main --url https://example.io/

Source: Spring4Shell-POC Repository

Detection Methods for CVE-2022-22965

Indicators of Compromise

Unexpected JSP files appearing in Tomcat web application directories (commonly named tomcatwar.jsp, shell.jsp, or similar)
Suspicious HTTP POST requests containing parameters like class.module.classLoader.resources.context.parent.pipeline.first.pattern
Modified Tomcat access log configurations pointing to JSP file extensions
Unusual process execution spawning from the Tomcat Java process
Web access logs showing requests to newly created JSP files with command parameters

Detection Strategies

Monitor HTTP request parameters for exploitation patterns including class.module.classLoader property chains
Implement WAF rules to block requests containing Spring4Shell exploitation strings
Deploy file integrity monitoring on Tomcat web application directories to detect unauthorized JSP file creation
Enable verbose Tomcat logging and monitor for configuration changes to AccessLogValve
Use YARA rules or IDS signatures specifically designed for Spring4Shell exploitation attempts

Monitoring Recommendations

Configure SIEM alerts for HTTP requests with abnormally long parameter names or values containing class loader manipulation patterns
Monitor Java process behavior for unexpected child process creation or network connections
Implement endpoint detection to identify post-exploitation activities such as webshell deployment
Review Tomcat server.xml and logging configurations for unauthorized modifications
Establish baseline metrics for normal application behavior to identify anomalous patterns

How to Mitigate CVE-2022-22965

Immediate Actions Required

Upgrade Spring Framework to version 5.3.18+ or 5.2.20+ immediately
Upgrade Apache Tomcat to versions 10.0.20+, 9.0.62+, or 8.5.78+ which include mitigations
If immediate patching is not possible, downgrade to JDK 8 as a temporary workaround
Audit all Spring-based applications to identify WAR deployments on Tomcat with JDK 9+
Implement WAF rules to block exploitation attempts while patches are being applied

Patch Information

VMware has released patched versions of Spring Framework addressing this vulnerability. Organizations should upgrade to Spring Framework 5.3.18 or later for the 5.3.x branch, or 5.2.20 or later for the 5.2.x branch. Additionally, Apache Tomcat has released updates that include supplementary mitigations. Refer to the VMware Security Advisory and Oracle Security Alerts for vendor-specific guidance on affected products.

Workarounds

Implement a ControllerAdvice component that sets disallowed fields for the class.* property pattern in the data binder
Deploy Spring Framework applications as executable JAR files instead of WAR deployments where possible
Apply network segmentation to restrict access to vulnerable applications from untrusted networks
Use reverse proxy configurations to filter malicious request parameters before they reach the application
Disable remote class loading by setting appropriate JVM security manager policies

bash

# Configuration example - Add to Spring application to block exploitation
# Create a ControllerAdvice class with the following configuration:
# @InitBinder
# public void setDisallowedFields(WebDataBinder dataBinder) {
#     String[] denylist = new String[]{"class.*", "Class.*", "*.class.*", "*.Class.*"};
#     dataBinder.setDisallowedFields(denylist);
# }

# Alternatively, set JVM property to use older module access:
java -jar application.jar --spring.mvc.bind-methods=none