Safeguard
Vulnerability Analysis

Spring4Shell (CVE-2022-22965): Class Loader Manipulation in Spring Framework

A factual look at Spring4Shell, the March 2022 remote code execution vulnerability in Spring Framework, including why its real-world impact was narrower than the initial Log4Shell comparisons suggested.

Safeguard Research Team
2 min read

Spring4Shell (CVE-2022-22965): Class Loader Manipulation in Spring Framework

Summary

Spring4Shell, CVE-2022-22965, was a remote code execution vulnerability in Spring Framework disclosed at the end of March 2022. It drew immediate and intense attention because it arrived a few months after Log4Shell and affected another extremely widely used Java component, though its actual exploitation requirements turned out to be considerably narrower.

Technical Root Cause

The vulnerability involved Spring's data binding mechanism, which maps HTTP request parameters onto Java object properties. On JDK 9 and later, an attacker could traverse from a bound object to its class loader through a crafted parameter path, and manipulate class loader properties to write a malicious file (such as a JSP web shell) to disk, achieving remote code execution. This maps to CWE-94 (Improper Control of Generation of Code).

Why the Impact Was Narrower Than Feared

Exploitation in the commonly demonstrated form required a specific combination: Spring Framework below the patched versions, JDK 9+, deployment as a WAR (not the more common embedded-Jar Spring Boot default), and Apache Tomcat as the servlet container. That combination was far from universal, so despite the initial alarm and the "Log4Shell 2" framing in early coverage, widespread mass exploitation did not materialize at comparable scale.

OWASP / CWE Mapping

  • CWE-94: Improper Control of Generation of Code ("Code Injection")
  • OWASP A03:2021: Injection
  • OWASP A06:2021: Vulnerable and Outdated Components

Lasting Impact

Spring4Shell is a useful counterexample in vulnerability triage: severity scores and surface-level similarity to a prior catastrophic bug are not the same as exploitability in a given environment. Teams that could quickly answer "are we on JDK 9+, deployed as a WAR, on Tomcat, with an affected Spring version" resolved their exposure in hours; teams without that inventory spent days.

How Safeguard Helps

This is precisely the case for reachability and configuration-aware analysis rather than raw CVE matching: Safeguard's risk scoring aims to distinguish "this CVE appears in your dependency tree" from "this CVE is actually exploitable in how you deploy," which is the difference between an emergency and a scheduled patch.

References

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.