Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Submit
ToolsExploitsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

··Feeds·Contact·Privacy·© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
spring4shell-local-verification-lab — Spring Framework CVE-2022-22965 本地影响条件验证、版本升级修复与复测项目 | Kitploit
Tools/GitHubGitHub/meng-security/spring4shell-local-verification-lab
Vulnerability AnalysisCode AnalysisExploitationWeb SecurityLearning & EducationLabs & Practice
GitHubmeng-security/spring4shell-local-verification-lab

spring4shell-local-verification-lab

Spring Framework CVE-2022-22965 本地影响条件验证、版本升级修复与复测项目

View Repository
82 months agoNot yet reviewed

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
Share

Spring4Shell Local Impact Condition Verification, Remediation, and Re-testing Project

Project Introduction

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:

  • JDK, Maven, and Apache Tomcat environment preparation
  • Spring MVC WAR project setup
  • Normal functionality baseline verification
  • Vulnerability impact condition confirmation
  • Read-only diagnosis of internal property paths
  • Vulnerability cause analysis
  • Spring Framework version upgrade
  • Post-remediation security re-testing
  • Post-remediation normal functionality re-testing
  • Test report and screenshot evidence organization

Security Statement

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:

  • No WebShell was written
  • No system commands were executed
  • No Tomcat configuration was modified
  • No reverse shell was established
  • No persistence control was implemented
  • No impact was made on any external systems

It is prohibited to use the test methods in this project on any unauthorized targets.

Vulnerability Background

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

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. Confirm impact conditions such as Spring Framework, JDK, Tomcat, WAR deployment, and data binding entry points.
  5. Observe access behavior of internal property paths in a read-only manner.
  6. Analyze the main causes of the vulnerability.
  7. Upgrade Spring Framework to a fixed version.
  8. Perform post-remediation re-testing using the same method.
  9. Confirm that the version upgrade did not affect normal business functionality.
  10. Organize project source code, test reports, and screenshot evidence.

Experimental Environment

This project was completed in a personal local VMware isolated experimental 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
  • Pre-fix Spring Framework version: 5.3.17
  • Post-fix Spring Framework version: 5.3.18
  • Web framework: Spring MVC
  • Project deployment method: Traditional WAR package deployment
  • Test address: 127.0.0.1

Normal functionality test data:

  • Name: Alice
  • Email: [email protected]

Security diagnostic property path:

class.module.name

Project Structure

spring4shell-local-verification-lab/

  • README.md: Project introduction, test methodology, verification results, and remediation explanation
  • docs/: Spring4Shell local impact condition verification, remediation, and re-testing report
  • images/: Screenshots of the project environment, testing process, and re-testing
  • vulnerable-demo/: Pre-remediation project using Spring Framework 5.3.17
  • fixed-demo/: Post-remediation project using Spring Framework 5.3.18
  • notes/: Study notes and process records

Main source code structure:

  • config/: Spring MVC configuration classes and application initializer classes
  • controller/: Form processing and property path diagnostic controller
  • model/: UserProfile class for receiving name and email parameters
  • WEB-INF/views/: JSP pages for homepage, submission result, and diagnostic result

Test Project Description

This project sets up two Spring MVC applications: one pre-remediation and one post-remediation.

Pre-remediation Project

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

Post-remediation Project

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

Normal Functionality Description

The test project provides a simple user profile form, including:

  • Name input field
  • Email input field
  • Submit profile button

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.

Test Methodology

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."

Download Tool