Spring4Shell, CVE-2022-22965, was a Spring Framework remote code execution flaw announced on 31 March 2022 after details leaked early. It applied only under specific conditions, including JDK 9 or higher and a WAR deployment on a servlet container. The main lesson is to know whether you meet the conditions before you panic.
What is the timeline?
These dates come from the Spring team's early announcement post. The post marks some dates as inferred, and so do we.
- Tuesday 29 March 2022 (inferred): Researchers from AntGroup FG reported the issue to VMware late in the evening, GMT.
- Wednesday 30 March 2022 (inferred): Details leaked online, so the advisory was published early.
- Thursday 31 March 2022: Spring Framework 5.3.18 and 5.2.20, Spring Boot 2.6.6 and 2.5.12, and the CVE were released.
- 1 April 2022: Apache Tomcat released 10.0.20, 9.0.62 and 8.5.78, which close the attack vector on the Tomcat side.
- 8 April 2022: Snyk reported another attack vector affecting Glassfish and Payara, per the Spring post.
- 13 April 2022: A follow up covered a separate issue, CVE-2022-22968, related to
disallowedFields.
Who was actually affected?
The Spring team listed several conditions for the reported exploit. The application had to run on JDK 9 or higher, be packaged as a traditional WAR and deployed on a standalone servlet container such as Tomcat, and use spring-webmvc or spring-webflux. Affected versions were Spring Framework 5.3.0 to 5.3.17, 5.2.0 to 5.2.19 and older.
Spring Boot executable JARs with an embedded container were not affected by the reported exploit. The flaw involves data binding of request parameters, and the post notes that JSON @RequestBody parameters are not directly affected, although other data bound parameters may be.
Many teams saw alarming headlines and could not tell if they were exposed. That is the real story.
What were the fixes and workarounds?
Upgrade is the advisory's first recommendation: Spring Framework 5.3.18 or 5.2.20, Spring Boot 2.6.6 or 2.5.12, or a fixed Tomcat version. For older applications on unsupported Spring versions, upgrading Tomcat is a tactical fix. Other options listed included running on Java 8, and setting disallowed fields globally so that class related binding paths are blocked, with a more fail safe approach using a custom handler adapter. The post warns that local binder methods can override the global setting.
What should defenders learn?
1. Conditions beat headlines. A flaw that needs four conditions hits a fraction of fleets. Be able to check each condition quickly.
2. You need to know your runtime. Which Java version, which container, which packaging? If those facts are not in an inventory, someone has to log in and look at each server.
3. Fixes can be in more than one place. Here the framework, Spring Boot and Tomcat all shipped updates. Track the transitive pieces.
4. Leaks compress timelines. Details leaked before the planned release. Have a plan for acting on a Wednesday night.
5. Follow ups matter. A second CVE arrived two weeks later. Do not close the incident after the first patch.
6. Workarounds need an owner. A global setting can be overridden locally. Verify, do not assume.
A triage routine for the next one
- Read the vendor advisory and write the conditions as a checklist.
- Query your inventory for the affected versions.
- For each hit, check the other conditions: runtime version, packaging, container.
- Patch exposed, internet facing systems first.
- Apply a workaround where patching is slow, and verify it.
- Re-check after follow up advisories, and record what you decided.
Reachability tools help here by telling you whether your code reaches the vulnerable path. Safeguard classes findings as reachable, conditionally reachable, unreachable or unknown, which is the same idea as checking conditions, applied at the code level. Configuration based conditions, like packaging and container, still need a look at the deployment.
Quick check
Was every Spring application vulnerable?
No. The Spring team described specific conditions, including JDK 9 or higher and a WAR on a standalone servlet container. Boot executable JARs with embedded containers were not affected by the reported exploit.
What was the first fix?
Spring Framework 5.3.18 and 5.2.20, released on 31 March 2022, along with Spring Boot 2.6.6 and 2.5.12.
Sources
Last reviewed: 18 October 2026.
