Spring4Shell Explained: CVE-2022-22965 Vulnerability Breakdown

In late March 2022, the cybersecurity community was alerted to a critical vulnerability in the widely used Spring Framework, quickly nicknamed Spring4Shell. This remote code execution flaw (CVE-2022-22965) presented a severe threat to applications running on modern Java versions.

Understanding this now-patched vulnerability is crucial for defensive security education, highlighting how subtle changes in underlying platforms can open new attack vectors. This analysis and lab walkthrough are intended for educational purposes within a controlled, authorized environment.

Vulnerability at a Glance

CVE ID	CVE-2022-22965
Vulnerability Type	Remote Code Execution (RCE)
Affected Versions	Spring Framework applications on Java 9+ with specific parameter binding, typically deployed on Apache Tomcat.
Discovered By	Publicly attributed to researcher p1n93r; analysis by lunasec.io and others.
Patched Version	Spring Framework 5.3.18 / 5.2.20 and later (Spring Boot 2.6.6 / 2.5.12+).

How the Vulnerability Works

The root cause lies in an interaction between the Spring Framework’s data binding feature and changes introduced in Java 9. Spring had existing protections to block malicious property binding through paths like class.classLoader.

However, starting with Java 9, the Class object exposed a new getModule() method. This created an unforeseen access path: class.module.classLoader.

Attackers could exploit Spring’s parameter binding to traverse this path and reach the underlying Tomcat server’s AccessLogValve object.

By overwriting its properties (pattern, suffix, directory, prefix), they could force Tomcat to write its access log file as a .jsp file within the web root directory.

This JSP file, containing attacker-controlled code, would then function as a web shell, granting full remote code execution on the server.

Lab Walkthrough

The following walkthrough simulates an attack in a controlled, isolated lab environment designed for educational purposes. Never evaluation this on systems you do not own or have explicit permission to assess.

Reconnaissance

Our engagement starts from a Kali Linux attacker machine. Initial reconnaissance confirms the target is alive and identifies open ports.

ping -c 1 target.lab
nmap -sV -p 80,443 target.lab

Port 80 is open, running a web service. Directory enumeration with a tool like dirb reveals common endpoints.

dirb http://target.lab

This might find paths like /login and /error. A key step is triggering an error, such as by requesting a double-encoded slash (/%2f), which often causes the server to return a 400 error page leaking the Tomcat version in its banner.

Vulnerability Confirmation and Exploitation

Using a public detection script (e.g., detect.py), we confirm the target is vulnerable to CVE-2022-22965. Following confirmation, an exploit script (exploit.py) is used to abuse the AccessLogValve trick.

The script sends a crafted HTTP POST request that sets the log properties, causing the server to write a JSP web shell (e.g., shell.jsp) to the web root.

python3 exploit.py --url http://target.lapp

Proof of Impact

Once the shell is uploaded, we can access it directly and execute operating system commands via a parameter, demonstrating code execution.

curl http://target.lab/shell.jsp?cmd=id

The response might show the command output, for example, uid=0(root) gid=0(root) groups=0(root), indicating the web server is running with high privileges in this lab setup. Further commands can explore the system.

# Example illustrative commands and outputs
shell.jsp?cmd=pwd
/usr/local/tomcat/webapps/ROOT

shell.jsp?cmd=ps aux
# Shows running processes

shell.jsp?cmd=find / -iname flag* 2>/dev/null
/root/flag.txt

shell.jsp?cmd=cat /root/flag.txt
FLAG{example_educational_flag_placeholder}

Locating and reading a flag file is a common lab exercise to prove full system compromise. This entire process underscores the critical need for robust patch management and server hardening, skills you can develop in your own secure home lab.

Mitigation and Patching

The definitive mitigation is to apply the official patches. Affected systems must be upgraded to Spring Framework 5.3.18 / 5.2.20 or later (and the corresponding Spring Boot versions 2.6.6 / 2.5.12+).

Administrators should also upgrade their Tomcat instances and consider configuring the Spring framework to disallow binding of sensitive fields like class, classLoader, and protectionDomain explicitly.

A critical defensive practice is to avoid running application servers as the root user, which would limit the impact of a successful exploit.

While Web Application Firewall (WAF) rules can provide temporary blocking, they are not a substitute for applying the vendor patches.

Ensuring your infrastructure, whether it’s a dedicated server or a protected home lab setup, is consistently updated is a cornerstone of defensive security.

Frequently Asked Questions

Was Java 8 affected by Spring4Shell?

No, the specific exploit path using class.module.classLoader required Java 9 or newer. Spring had already implemented protections for the known Java 8 era gadget chains, but the new module API introduced a bypass.

What is the main lesson for developers from this vulnerability?

It highlights the importance of understanding how updates in underlying platform dependencies (like a new Java version) can inadvertently break existing security controls. Regular updates and defense-in-depth, such as limiting data binding, are essential.

Can this vulnerability be exploited on servers not using Tomcat?

The publicly documented exploit chain specifically targeted Apache Tomcat by manipulating its AccessLogValve. While the core Spring vulnerability exists in other deployment scenarios, the immediate RCE exploit required a compatible gadget chain present in Tomcat.

Is studying old vulnerabilities like Spring4Shell still useful?

Absolutely. Analyzing patched vulnerabilities provides invaluable insight into attacker methodology, secure coding pitfalls, and patch analysis. This knowledge is directly applicable to modern cybersecurity roles focused on threat hunting and defensive architecture.

About the author