Spring4Shell is the nickname for CVE-2022-22965, a critical remote code execution flaw in Spring MVC and Spring WebFlux data binding on JDK 9 or later. The known exploit needed Tomcat and a WAR deployment. Spring fixed it in Framework 5.3.18 and 5.2.20, announced on 31 March 2022.
What exactly was the flaw?
Spring's advisory describes a Spring MVC or Spring WebFlux application running on JDK 9 or higher that "may be vulnerable to remote code execution (RCE) via data binding". Data binding is the feature that copies request parameters onto Java objects. The flaw let a request reach properties it was never meant to touch.
The advisory is careful about scope. The specific exploit it describes required all of these:
- JDK 9 or higher
- Apache Tomcat as the servlet container
- Packaging as a WAR file
- a spring-webmvc or spring-webflux dependency
It adds that a Spring Boot executable jar, which is the default packaging, "is not vulnerable to the exploit", while noting the nature of the flaw is more general and other ways to exploit it might exist. That sentence explains why the response in many teams was "check how we deploy" rather than "patch everything".
Which versions were affected and fixed?
The advisory lists Spring Framework 5.3.0 to 5.3.17, and 5.2.19 and earlier. Fixed versions are 5.3.18 and 5.2.20. Spring rated it critical, and the CVSS vector it links shows network attack, low complexity, no privileges and no user interaction.
What were the workarounds?
For teams that could not upgrade at once, Spring's early announcement offered three options. Upgrade Tomcat to 10.0.20, 9.0.62 or 8.5.78, described as protection but a tactical step. Downgrade to Java 8. Or set disallowed fields on the data binder to block the class related property paths. Spring said these are not mutually exclusive, and that the main goal should be upgrading to a supported Framework version.
The announcement also cleared up two misconceptions. A commit deprecating SerializationUtils was unrelated. A separate CVE for Spring Cloud Function, published just before, was also unrelated. Two similar sounding Spring issues in one week caused real confusion, which is a reminder to read the advisory instead of a headline.
What does it teach about dependency risk?
First, the Framework version in your application is only part of the answer. Exposure depended on the Java version, the container and the packaging. A tool that reports only that a vulnerable library is present will overstate or understate risk. Reachability and runtime context decide whether you must act today.
Second, Spring is often a transitive dependency. A service may pull it in through a starter, a vendor library or a shared parent project. Teams that had a software bill of materials could answer "where do we use it" quickly. Teams without one grepped repositories.
A constructed example
An organization runs forty Java services. A query against its inventory finds Spring Framework 5.3.10 in twelve. Seven are Spring Boot executable jars. Five are WARs deployed to Tomcat, and three of those run JDK 11. Those three become the first patch targets, the other nine follow in the normal cycle. The inventory turned a week of panic into an afternoon of triage.
How to check or apply this
- List every service using spring-webmvc or spring-webflux, including transitive use.
- Record the Framework version, JDK version, container and packaging for each.
- Upgrade to 5.3.18, 5.2.20 or any later supported release.
- Where you cannot, apply the advisory's workarounds and track the exception with an expiry date.
- Rebuild and redeploy, since a fixed pom does nothing until the artifact ships.
- Keep the inventory current for the next advisory.
Safeguard's dependency scanning and reachability analysis are built for this question: where does the library appear, and is the vulnerable path reachable in this build.
Quick check
Was every Spring Boot application vulnerable to Spring4Shell?
No. Spring said the known exploit required Tomcat with a WAR deployment, and that a default Spring Boot executable jar was not vulnerable to that exploit.
Which Framework versions contain the fix?
5.3.18 and 5.2.20, and any later supported release.
Sources
Last reviewed: 18 October 2026.
