Java and Spring4Shell: what CVE-2022-22965 really taught Spring teams

Spring4Shell was not a second Log4Shell

CVE-2022-22965 was quickly branded Spring4Shell. The comparison helped people pay attention, but it also blurred the technical reality. Spring was explicit in its official advisory: the public exploit conditions involved Spring MVC or Spring WebFlux on JDK 9+, deployed as a WAR on Tomcat. A standard Spring Boot executable jar was not vulnerable to that reference exploit path.

Why the flaw still matters

It remains one of the most important vulnerabilities in the Spring ecosystem because it reminded teams that even a mature framework can become critical when several seemingly ordinary deployment conditions combine.

Spring documented the affected versions and recommended upgrades to 5.3.18+ or 5.2.20+.

What this exposed

The real lesson was not just a coding mistake. It was the gap between what teams think they deploy and what they actually deploy. Many organizations said we are on Spring Boot so we are fine, without checking whether older applications were still packaged as WAR files behind Tomcat.

Spring4Shell therefore exposed a classic large-Java risk: heterogeneity. Inside one company, the label Spring can cover very different packaging and runtime models.

What Spring teams should verify in 2026

Our view

If Log4Shell is the symbolic Java dependency flaw, Spring4Shell is the symbolic flaw of architectural assumptions. It reminds teams that a modern stack is not just the framework name. It is a combination of versions, packaging, runtime, and deployment habits.

Saying we use Spring says very little about risk. Saying we use this branch, packaged this way, on this runtime, with this patch process says much more.