Spring4Shell broke in late March 2022, three months after Log4Shell, and the initial coverage assumed it would be similarly devastating. It was not, but it was also not the non-event some commentators later claimed. The real story is a useful case study in how to assess a CVE during the chaotic first 72 hours when the technical details are still emerging and the marketing pressure to declare it either critical or harmless is enormous.
CVE-2022-22965 affected Spring Framework versions before 5.2.20 and 5.3.18 when deployed under specific runtime conditions. The vulnerability allowed remote code execution by manipulating data binding to overwrite class loader properties. The narrow but real exposure footprint, combined with confusing early disclosures, made it an instructive incident even though it never reached Log4Shell-scale impact.
What did the vulnerability actually exploit?
The technical mechanism was a data binding flaw in the Spring MVC and Spring WebFlux frameworks when running on JDK 9 or later. Spring's parameter binding allowed attackers to traverse Java object properties via crafted HTTP request parameters, reaching the class loader of the running application server. By manipulating Tomcat's AccessLogValve properties through this traversal, an attacker could write a controlled JSP file to a directory served by Tomcat, then request that JSP to execute arbitrary commands as the server process. The exploit chain was unauthenticated and could be triggered by a single HTTP request with crafted query parameters. It worked against Tomcat-deployed Spring applications, but not against the increasingly common alternatives, Spring Boot fat JARs, Netty, or Jetty, which lacked the AccessLogValve attack surface that made the chain practical.
How much of the ecosystem was actually exposed?
This is where Spring4Shell diverged sharply from Log4Shell. Spring Framework was as widely used as Log4j, but the specific conditions for exploitation were narrow. The application had to use Spring's parameter binding to a non-basic Java type, run on JDK 9 or later, deploy as a WAR file under Tomcat, and expose at least one endpoint that bound user input to such a type. Surveys conducted in April and May 2022 estimated that between 8% and 15% of Spring deployments met all the criteria, against the 35% to 60% exposure rate for Log4Shell. Honeypot data tracked by Rapid7 and others recorded an order of magnitude fewer exploit attempts in the first month than Log4Shell saw in its first week. The CVE was real, but the deployment conditions made it a targeted rather than mass-exploitation vulnerability.
Why was the early reporting so confused?
The first technical writeup leaked from a Chinese researcher's social media account before coordinated disclosure was complete, and the leaked proof of concept did not clearly specify the runtime conditions required. Several security vendors initially published advisories saying any Spring application running on JDK 9 or later was vulnerable, which was inaccurate but spread quickly. The Spring team's own first patch fixed a related but distinct issue, CVE-2022-22963 in Spring Cloud Function, which added to the confusion because both were called Spring4Shell in some media coverage. By the time VMware published the definitive advisory and the patched 5.2.20 and 5.3.18 versions, the public conversation was already polluted. Many organizations spent the first 48 hours either panicking unnecessarily or, equally bad, assuming the whole thing was a false alarm and ignoring it.
What was the actual exploitation pattern?
Confirmed exploitation in the wild was substantially lower than Log4Shell but not zero. The Mirai botnet incorporated a Spring4Shell module within ten days of disclosure and added it to its scanning kit, generating most of the background exploitation traffic that followed. Several APT groups, including ones tracked as DEV-0270 by Microsoft, integrated the exploit into their ransomware pre-positioning toolchains in mid-2022. CISA added the CVE to its Known Exploited Vulnerabilities catalog within eleven days, and the federal agency patching deadline passed without major reported incidents. The total tracked exploitation incidents over the following year were in the high hundreds rather than the tens of thousands seen with Log4Shell. The narrow conditions for exploitability did real work in limiting the blast radius.
What lessons still matter four years on?
The most useful lesson is about how to triage during the first 72 hours of a major disclosure. Spring4Shell required parsing not just the vulnerability description but the specific runtime configuration that made it exploitable, and most organizations did not have the tooling to answer that question quickly. Asking whether a CVE affects you should yield a list of deployments that match the exploit conditions, not just a list of installations that include the affected library. The second lesson is about disclosure hygiene: leaked proof-of-concept code without complete writeups creates more chaos than coordinated disclosure delays, and the industry should be willing to slow down a few days to get the technical details right. The third is that exposure narrowing is real and worth designing for. Spring applications that ran on Netty or as Spring Boot fat JARs were structurally immune to this CVE because of deployment choices made years earlier.
How Safeguard Helps
Safeguard's approach to vulnerabilities like Spring4Shell is configuration-aware reachability. Our SBOM analysis captures not just which Spring versions are present in your services, but the deployment topology, JDK version, container packaging, and exposed endpoints, that determine whether the exploit conditions actually align. Griffin AI correlates CVE disclosures with this configuration context, so during a chaotic first 72 hours you get a small, accurate list of services that meet all the exploit prerequisites, not the full Spring inventory. Policy gates can block deployments that combine vulnerable framework versions with high-risk runtime configurations. TPRM data flags vendors whose Spring deployments are likely to meet exploit conditions, and our zero-CVE Java base images provide patched runtimes for teams that want to eliminate the framework risk at the platform layer.