meng-security/spring4shell-local-verification-labSpring Framework CVE-2022-22965 本地影响条件验证、版本升级修复与复测项目
This project is used for learning and verifying the impact conditions, risk manifestations, remediation methods, and post-remediation re-testing procedures for Spring Framework CVE-2022-22965, also known as the Spring4Shell vulnerability.
The project was completed in a locally built authorized environment. The focus of the project is not on attacking real targets, but on building pre- and post-remediation Spring MVC test environments, verifying the vulnerability-related impact conditions item by item, and observing the differences in internal property path access in the Spring data binding before and after version upgrades in a safe, controlled read-only manner.
This project completed the following process:
This project is only intended for personal local self-built 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 real user data or real business data.
The following operations were NOT performed during testing:
It is prohibited to use the test methods in this project on any unauthorized targets.
CVE-2022-22965, commonly known as Spring4Shell, is a remote code execution vulnerability related to the request parameter data binding mechanism in Spring Framework.
Spring MVC supports automatically binding HTTP request parameters to Java object properties. For example, this project receives name and email parameters through the following method:
@ModelAttribute("profile") UserProfile profile
Under normal circumstances, the request parameters name and email are bound to the UserProfile object according to property names.
In the affected versions, access restrictions on some internal property paths are not strict enough. When using JDK 9 or higher, and when specific Servlet container, deployment method, and data binding conditions are met, external request parameters may access internal objects related to Java Class, modules, class loaders, or the container along the ordinary business object.
In a specific exploitable environment, an attacker may further modify server configurations or write server files, thereby creating a remote code execution risk.
This project does not perform full remote code exploitation; instead, it uses the following property path for safe, read-only differential diagnosis:
class.module.name
This project was completed in a personal local VMware isolated experimental environment.
127.0.0.1Normal functionality test data:
Alice[email protected]Security diagnostic property path:
class.module.name
spring4shell-local-verification-lab/
README.md: Project introduction, test methodology, verification results, and remediation explanationdocs/: Spring4Shell local impact condition verification, remediation, and re-testing reportimages/: Screenshots of the project environment, testing process, and re-testingvulnerable-demo/: Pre-remediation project using Spring Framework 5.3.17fixed-demo/: Post-remediation project using Spring Framework 5.3.18notes/: Study notes and process recordsMain source code structure:
config/: Spring MVC configuration classes and application initializer classescontroller/: Form processing and property path diagnostic controllermodel/: UserProfile class for receiving name and email parametersWEB-INF/views/: JSP pages for homepage, submission result, and diagnostic resultThis project sets up two Spring MVC applications: one pre-remediation and one post-remediation.
Project directory:
vulnerable-demo
Version used:
Spring Framework 5.3.17
Generated WAR file:
spring4shell-vulnerable-demo.war
Access address:
http://127.0.0.1:8080/spring4shell-vulnerable-demo/
Diagnostic page:
http://127.0.0.1:8080/spring4shell-vulnerable-demo/binding-probe
Project directory:
fixed-demo
Version used:
Spring Framework 5.3.18
Generated WAR file:
spring4shell-fixed-demo.war
Access address:
http://127.0.0.1:8080/spring4shell-fixed-demo/
Diagnostic page:
http://127.0.0.1:8080/spring4shell-fixed-demo/binding-probe
The test project provides a simple user profile form, including:
The controller receives request parameters through the following method:
@ModelAttribute("profile") UserProfile profile
After the user submits the name and email, Spring MVC automatically binds the name and email parameters to the UserProfile object.
The result page reads the bound object and displays the user's submitted name and email.
This functionality is used to confirm that the project runs normally, and to prove that a valid Spring MVC request parameter data binding entry exists in the application.
This project follows the approach: "first confirm normal functionality, then confirm impact conditions, then perform read-only risk diagnosis, and finally fix and re-test."
@ModelAttribute to bind request parameters to the UserProfile object.class.module.name using Spring BeanWrapper.This project confirmed the following impact conditions one by one:
spring-webmvc component@ModelAttributeThe actual Spring dependencies deployed in the pre-remediation project include:
spring-beans-5.3.17.jarspring-core-5.3.17.jarspring-web-5.3.17.jarspring-webmvc-5.3.17.jarThis project does not directly judge vulnerability existence solely based on the Spring Framework version, but conducts a comprehensive analysis combining JDK, Spring MVC, Tomcat, WAR deployment, and data binding entry.
To avoid executing destructive exploitation, this project uses the BeanWrapper provided by Spring Framework to perform a read-only check on the following property path:
class.module.name
This path means:
class: Accesses the Java Class object corresponding to the current business objectmodule: Accesses the Java module to which this class belongsname: Reads the module nameThe diagnosis process only calls property readability checks and property value reading methods:
Therefore, this diagnosis can only be used to observe the difference in access to internal property paths before and after remediation, and cannot alone prove that remote code execution has been achieved.
Pre-remediation environment uses:
Spring Framework 5.3.17
Property path checked:
class.module.name
Diagnosis result:
truenulltrue indicates that the current environment can continue to resolve module.name along the class property of an ordinary business object.
The read result is null because the current WAR application runs in the Java unnamed module, where the module name is empty; this does not mean the property path read failed.
Post-remediation environment uses:
Spring Framework 5.3.18
Re-diagnose with the same property path:
class.module.name
Diagnosis result:
falseNot readableThe results before and after remediation form a clear comparison:
This result indicates that after the version upgrade, access to the original diagnostic property path has been restricted, and the risk manifestation observed before remediation no longer appears.
This project adopts the method of upgrading the Spring Framework version for remediation.
Pre-remediation configuration:
<spring.version>5.3.17</spring.version>
Post-remediation configuration:
<spring.version>5.3.18</spring.version>
The following operations were performed during the remediation process:
fixed-demo.The actual Spring dependencies deployed in the post-remediation project include:
spring-beans-5.3.18.jarspring-core-5.3.18.jarspring-web-5.3.18.jarspring-webmvc-5.3.18.jarThis result proves that the fixed version was rebuilt and actually deployed, not just a change of the version number in pom.xml.
After upgrading to Spring Framework 5.3.18, re-access the fixed project homepage and submit the following test data:
Alice[email protected]After submission, the page still displays normally:
Alice[email protected]This result indicates that the version upgrade did not affect the project's original normal request parameter binding and page display functionality.
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 ordinary properties in UserProfile.
However, Spring's property access mechanism also supports nested property paths with dots. In affected versions, the restrictions on some internal property paths are not strict enough, allowing external parameters to proceed from ordinary business objects to Java Class, modules, class loaders, or Servlet container-related objects under specific environments.
When there are writable properties in internal objects that can affect server configuration or the file system, and the application simultaneously meets conditions such as JDK, Tomcat, WAR deployment, and data binding, it may further lead to a remote code execution risk.
This vulnerability is not because the name or email properties themselves are problematic, nor is every project using Spring MVC necessarily exploitable. The existence of the vulnerability typically requires multiple conditions to be satisfied together.
For real business systems, the following measures are recommended:
This project completed the impact condition confirmation, risk manifestation diagnosis, version upgrade remediation, and post-remediation re-testing for Spring Framework CVE-2022-22965 in a local isolated environment.
The pre-remediation project used Spring Framework 5.3.17. In the environment of JDK 11, Spring MVC, Apache Tomcat 9.0.60, and traditional WAR deployment, the class.module.name property path was determined to be readable.
The post-remediation project upgraded Spring Framework to 5.3.18. The same property path became unreadable, while the normal data binding functionality for name and email remained usable.
This project did not perform full remote code exploitation; instead, it completed differential verification before and after remediation through a safe, controlled read-only method.
The project highlights the following capabilities: