## https://sploitus.com/exploit?id=FAAA6ED0-3A9C-518B-9F02-12E108B2ECFB
# Spring4Shell Local Exploitation Conditions Verification, Remediation, and Retesting Project
## Project Overview
This project is designed to study and verify the exploitation conditions, risk manifestations, remediation methods, and post-remediation retesting process for CVE-2022-22965 in the Spring Framework, also known as the Spring4Shell vulnerability.
The project was completed in a locally set up, authorized environment. The focus was not on attacking real targets, but rather on setting up pre- and post-patch Spring MVC test environments to systematically verify the vulnerability’s exploitation conditions and observe, in a secure and controlled read-only manner, the differences in Spring data binding’s internal property paths before and after the version update.
This project completed the following steps:
- Preparation of the JDK, Maven, and Apache Tomcat environments
- Setup of the Spring MVC WAR project
- Verification of normal functionality baseline
- Confirmation of vulnerability conditions
- Read-only diagnosis of internal property paths
- Analysis of the root cause of the vulnerability
- Spring Framework version upgrade
- Post-fix security retesting
- Post-fix functional retesting
- Compilation of test reports and screenshot evidence
## Security Statement
This project is intended solely for use in personal, self-hosted local environments or explicitly authorized security testing environments.
The project does not scan, probe, or exploit any public websites, servers, or third-party business systems, and does not contain any real user data or real business data.
The following actions were not performed during testing:
- No WebShells were injected
- No system commands were executed
- No Tomcat configurations were modified
- No reverse shells were established
- No persistence controls were implemented
- No impact was made on any external systems
It is strictly prohibited to use the testing methods in this project on any unauthorized targets.
## Vulnerability Background
CVE-2022-22965, commonly known as Spring4Shell, is a remote code execution vulnerability in the Spring Framework related to the request parameter data binding mechanism.
Spring MVC supports automatically binding HTTP request parameters to Java object properties. For example, this project receives the `name` and `email` parameters as follows:
`@ModelAttribute("profile") UserProfile profile`
Under normal circumstances, the request parameters `name` and `email` are bound to the `UserProfile` object based on their property names.
In the affected versions, access restrictions on certain internal property paths are not strict enough. When using JDK 9 or later, and under specific conditions regarding the Servlet container, deployment method, and data binding, external request parameters may bypass ordinary business objects to access internal objects related to Java `Class`, modules, classloaders, or the container.
In specific exploitable environments, an attacker could further modify server configurations or write to server files, thereby creating a risk of remote code execution.
This project does not perform a full remote code exploitation; instead, it uses the following property path for secure, read-only differential diagnosis:
`class.module.name`
## Project Objectives
1. Understand the basic process of Spring MVC request parameter data binding.
2. Set up a local Spring MVC WAR test project.
3. Complete baseline verification of normal business functionality.
4. Identify influencing factors such as the Spring Framework, JDK, Tomcat, WAR deployment, and data binding entry points.
5. Observe the access behavior of internal property paths in read-only mode.
6. Analyze the primary causes of the vulnerability.
7. Upgrade the Spring Framework to a patched version.
8. Perform post-patch retesting using the same method.
9. Verify that the version upgrade has not affected normal business functionality.
10. Compile the project source code, test reports, and screenshot evidence.
## Test Environment
This project was completed in a personal, isolated local VMware test environment.
- **Host Machine:** Windows 11
- **Target Machine:** Windows 10 virtual machine
- **Virtualization Software:** VMware Workstation
- **Java Environment:** Eclipse Temurin JDK 11.0.31
- **Project Build Tool:** Apache Maven 3.9.16
- **Servlet Container:** Apache Tomcat 9.0.60
- **Spring Framework version before the fix:** 5.3.17
- **Spring Framework version after the fix:** 5.3.18
- **Web framework:** Spring MVC
- **Project deployment method:** Traditional WAR file deployment
- **Test URL:** `127.0.0.1`
Normal Functionality Test Data:
- Name: `Alice`
- Email: `alice@example.com`
Security Diagnostic Property Path:
`class.module.name`
## Project Structure
spring4shell-local-verification-lab/
- `README.md`: Project introduction, testing approach, verification results, and remediation instructions
- `docs/`: Spring4Shell local exploit condition verification, remediation, and retesting report
- `images/`: Screenshots of the project environment, testing process, and retesting
- `vulnerable-demo/`: Pre-fix project using Spring Framework 5.3.17
- `fixed-demo/`: Post-fix project using Spring Framework 5.3.18
- `notes/`: Study notes and process logs
Main Source Code Structure:
- `config/`: Spring MVC configuration classes and application initialization classes
- `controller/`: Controllers for form processing and property path diagnostics
- `model/`: The `UserProfile` class used to receive name and email parameters
- `WEB-INF/views/`: JSP pages for the home page, submission results, and diagnostic results
## Project Testing Description
This project includes two Spring MVC applications: one before the fix and one after the fix.
### Project Before the Fix
Project directory:
`vulnerable-demo`
Version used:
`Spring Framework 5.3.17`
Generated WAR file:
`spring4shell-vulnerable-demo.war`
Access URL:
`http://127.0.0.1:8080/spring4shell-vulnerable-demo/`
Diagnostic page:
`http://127.0.0.1:8080/spring4shell-vulnerable-demo/binding-probe`
### Project After Fix
Project directory:
`fixed-demo`
Version used:
`Spring Framework 5.3.18`
Generated WAR file:
`spring4shell-fixed-demo.war`
URL:
`http://127.0.0.1:8080/spring4shell-fixed-demo/`
Diagnostic page:
`http://127.0.0.1:8080/spring4shell-fixed-demo/binding-probe`
## Description of Normal Functionality
The test project provides a simple user profile form, including:
- A name input field
- An email input field
- A "Submit Profile" button
The controller receives request parameters as follows:
`@ModelAttribute("profile") UserProfile profile`
When the user submits their name and email address, Spring MVC automatically binds the `name` and `email` parameters to the `UserProfile` object.
The results page reads the bound object and displays the name and email address submitted by the user.
This feature is used to verify that the project is functioning properly and to demonstrate that the application has a valid entry point for Spring MVC request parameter data binding.
## Testing Approach
This project follows the approach of “first verifying normal functionality, then identifying impact conditions, followed by read-only risk assessment, and finally fixing the issue and retesting.”
1. Install and configure JDK 11, Maven, and Apache Tomcat.
2. Set up a Spring MVC project using Spring Framework 5.3.17.
3. Create forms for name and email.
4. Use `@ModelAttribute` to bind request parameters to the `UserProfile` object.
5. Use Maven to package the project into a WAR file.
6. Deploy the WAR file to a standalone Apache Tomcat instance.
7. Submit simulated user profiles locally to complete baseline verification of normal functionality.
8. Verify the actual versions of JDK, Tomcat, and Spring Framework in use, as well as the deployment method.
9. Use Spring’s `BeanWrapper` to perform read-only diagnostics on `class.module.name`.
10. Record the results of property path access in the Spring Framework 5.3.17 environment.
11. Upgrade the Spring Framework to 5.3.18.
12. Rebuild and deploy the fixed project.
13. Retest the fixed project using the same property path.
14. Resubmit the name and email address to confirm that normal functionality remains unaffected.
## Confirmation of Impact Conditions
This project verified the following conditions one by one:
- Using JDK 11.0.31, which meets the requirement of JDK 9 or higher
- Using Spring Framework 5.3.17
- The project includes the `spring-webmvc` component
- Using Apache Tomcat 9.0.60
- The project is deployed as a traditional WAR file
- The project is loaded by a standalone Tomcat instance
- Controllers contain data binding entry points based on `@ModelAttribute`
The Spring dependencies actually deployed in the project prior to the fix included:
- `spring-beans-5.3.17.jar`
- `spring-core-5.3.17.jar`
- `spring-web-5.3.17.jar`
- `spring-webmvc-5.3.17.jar`
This project does not determine whether a vulnerability exists based solely on the Spring Framework version; instead, it performs a comprehensive analysis that takes into account the JDK, Spring MVC, Tomcat, WAR deployment, and data binding entry points.
## Risk Diagnosis Method
To prevent the execution of destructive exploits, this project uses the `BeanWrapper` provided by the Spring Framework to perform read-only checks on the following property paths:
`class.module.name`
This path represents:
- `class`: Accesses the Java `Class` object corresponding to the current business object
- `class`: Accesses the Java `Class` object corresponding to the current business object
- `module`: Accesses the Java module to which the class belongs
- `name`: Reads the module name
The diagnostic process only calls methods to check property readability and read property values:
- Does not set object properties
- Does not modify server configuration
- Does not write to server files
- Does not execute operating system commands
Therefore, this diagnostic can only be used to observe differences in access to internal property paths before and after the fix; it cannot, on its own, prove that remote code execution has been achieved.
## Verification Results
### Results Before the Fix
The environment used before the fix was:
`Spring Framework 5.3.17`
Property path checked:
`class.module.name`
Diagnostic results:
- Can be read: `true`
- Read result: `null`
`true` indicates that the current environment can continue resolving `module.name` along the `class` property of a regular business object.
The result is `null` because the current WAR application is running in an unnamed Java module; the module name is empty, which does not indicate a failure to read the property path.
### Results After Fix
Environment used after the fix:
`Spring Framework 5.3.18`
Re-diagnosis using the same property path:
`class.module.name`
Diagnosis results:
- Readability: `false`
- Result: `Not readable`
The results before and after the fix provide a clear contrast:
- Spring Framework 5.3.17: The property path is readable
- Spring Framework 5.3.18: The property path is not readable
These results indicate that, following the version upgrade, access to the originally diagnosed property path has been restricted, and the risk observed prior to the fix no longer occurs.
## Remediation Measures
This project was remediated by upgrading the Spring Framework version.
Configuration before the fix:
`5.3.17`
Configuration after the fix:
`5.3.18`
The following steps were completed during the fix:
1. Copied the pre-fix project to `fixed-demo`.
2. Kept the business logic of the Controller, data model, and JSP pages unchanged.
3. Upgraded the Spring Framework from 5.3.17 to 5.3.18.
4. Used Maven to re-download the dependencies for the fixed version.
5. Recompiled and generated the fixed WAR file.
6. Deployed the fixed WAR file to Apache Tomcat.
7. Check the Spring JAR versions actually deployed in the patched project.
8. Perform security retesting using the original property paths.
9. Retest the name and email submission functionality.
The Spring dependencies actually deployed in the patched project include:
- `spring-beans-5.3.18.jar`
- `spring-core-5.3.18.jar`
- `spring-web-5.3.18.jar`
- `spring-webmvc-5.3.18.jar`
This result confirms that the fixed version has been rebuilt and actually deployed, rather than simply having the version numbers in `pom.xml` modified.
## Retesting Normal Functionality After the Fix
After upgrading to Spring Framework 5.3.18, revisit the fixed project’s homepage and submit the following test data:
- Name: `Alice`
- Email: `alice@example.com`
After submission, the page continues to display correctly:
- User profile submitted successfully
- Name is `Alice`
- Email is `alice@example.com`
These results indicate that the version upgrade did not affect the project’s original request parameter binding or page display functionality.
## Cause of the Vulnerability
Spring MVC’s automatic data binding mechanism can access Java object properties based on HTTP request parameter names.
Normal business parameters `name` and `email` only need to access the corresponding plain properties in `UserProfile`.
However, Spring’s property access mechanism also supports nested property paths denoted by periods. In the affected versions, restrictions on certain internal property paths were not strict enough, allowing external parameters to potentially bypass ordinary business objects and access Java `Class`, module, class loader, or Servlet container-related objects under specific conditions.
If internal objects contain writable properties capable of affecting server configuration or the file system, and the application simultaneously meets certain conditions—such as JDK, Tomcat, WAR deployment, and data binding—this may further lead to a remote code execution risk.
This vulnerability is not caused by issues with the `name` or `email` properties themselves, nor does it mean that all projects using Spring MVC are necessarily exploitable. Multiple conditions must typically be present simultaneously for the vulnerability to be exploitable.
## Mitigation Recommendations
In production systems, it is recommended to take the following measures:
- Identify the actual versions of Spring Framework and Spring Boot in use
- Prioritize upgrading to a secure version that is still officially supported
- Rebuild and redeploy the application after upgrading
- Verify the actual Spring JAR versions in the final deployment package
- Restrict the scope of data binding in Controllers
- Allow binding only for fields required for normal business operations
- Use a dedicated request data object to receive external parameters
- Avoid directly exposing database entities or complex internal objects to external parameters
- Do not rely on front-end validation to enforce security restrictions
- Implement temporary mitigation measures for systems that cannot be upgraded immediately
- Temporary mitigation measures are not a substitute for upgrading to the official version
- Run Tomcat and Java services under low-privilege accounts
- Set the minimum necessary permissions for application and configuration directories
- Monitor changes to suspicious request parameters and server files
- Conduct both security retesting and normal business functionality retesting after fixes are implemented
## Key Screenshot Evidence
### Environment and Deployment
![JDK 11 Version Verification]()
![Maven Version Verification]()
![Apache Tomcat 9.0.60 Started Successfully]()
![Maven Packaging Successful]()
![WAR Project Deployment Successful]()
### Normal Functionality Baseline
![Normal Access to Test Project Home Page]()
![Normal Functionality Baseline Verification Successful]()
### Pre-Fix Verification
![Spring Framework 5.3.17 Dependency Verified]()
![Internal Property Paths Readable Before Fix]()
### Fixes and Retesting
![Fixed version packaging successful]()
![Internal property paths are no longer readable after fix]()
![Normal functionality retest successful after fix]()
![Spring Framework 5.3.18 dependency confirmed after fix]()
## Current Progress
- [x] Created project directory
- [x] Wrote README
- [x] Created test report
- [x] Prepared JDK, Maven, and Tomcat environments
- [x] Set up Spring MVC test project
- [x] Completed WAR project packaging and deployment
- [x] Completed baseline verification of normal functionality
- [x] Completed confirmation of vulnerability exploitation conditions
- [x] Completed local read-only risk assessment
- [x] Completed analysis of vulnerability root causes
- [x] Complete Spring Framework version upgrade
- [x] Complete post-patch security retesting
- [x] Complete post-patch normal functionality retesting
- [x] Confirm actual dependency versions after patching
- [x] Compiled test reports and screenshot evidence
## Project Summary
This project completed the confirmation of exploit conditions, risk manifestation diagnosis, version upgrade remediation, and post-remediation retesting for Spring Framework CVE-2022-22965 in a local isolated environment.
Prior to the fix, the project used Spring Framework 5.3.17. In an environment running JDK 11, Spring MVC, Apache Tomcat 9.0.60, and a traditional WAR deployment, the `class.module.name` property path was determined to be readable.
After the fix, the project was upgraded to Spring Framework 5.3.18. The same property path became unreadable, while the normal data binding functionality for names and email addresses remained available.
This project did not perform a full remote code execution exploit; instead, it verified the differences before and after the fix using a secure, controlled, read-only method.
This project highlights the following capabilities:
- Setting up a Java and Spring MVC development environment
- Building a Maven project
- Deploying a Tomcat WAR application
- Understanding Spring data binding mechanisms
- Analyzing vulnerability exploitation conditions
- Designing security testing processes
- Upgrading component versions
- Retesting after remediation
- Regression testing of normal functionality
- Writing security test reports
- Organizing screenshot evidence and the GitHub project