Spring4Shell (CVE-2022-22965) Deep Dive: RCE via Data Bin...

In late March 2022, the Java ecosystem faced its second "Shell"-branded crisis in four months. Spring4Shell (CVE-2022-22965) is a critical remote code execution vulnerability in the Spring Framework — the dependency-injection and MVC backbone used by an enormous share of enterprise Java applications. An unauthenticated attacker who can reach a vulnerable endpoint can achieve full RCE through Spring's data binding feature, without needing valid credentials, a malicious file upload, or any user interaction. Given Spring's ubiquity in banking, government, and enterprise software, the disclosure triggered the kind of internet-wide scramble security teams had just experienced with Log4Shell.

What Is Spring4Shell, Technically?

Spring4Shell abuses Spring MVC's and Spring WebFlux's data binding mechanism — the code that automatically maps incoming HTTP request parameters onto Java objects. Spring's DataBinder resolves nested properties on request objects, and under specific conditions an attacker can submit parameter names that reach into an object's class.module.classLoader property chain. Because Java exposes a getClass() accessor on every object, and Spring's binder will happily traverse property paths, a carefully crafted parameter name lets an attacker manipulate ClassLoader internals rather than ordinary bean properties.

This is conceptually similar to an older Spring issue, CVE-2010-1622, which used the same class.classLoader gadget over a decade earlier. Spring4Shell is effectively a bypass of the mitigations put in place after that original bug, made newly exploitable by changes introduced in JDK 9+ module system internals (specifically, access to class.module.classLoader.resources.context.parent.pipeline.first, a Tomcat-specific gadget chain that lets an attacker write a malicious JSP file to disk and then request it to execute arbitrary code).

Affected Versions and Components

According to Spring's official advisory, the vulnerability requires a specific combination of conditions to be exploitable in the well-known Tomcat gadget chain:

• JDK 9 or higher
• Apache Tomcat as the Servlet container
• Application packaged as a traditional WAR and deployed to a standalone Tomcat instance (Spring Boot applications using the default embedded, executable-jar packaging are not exploitable via the documented gadget chain, though Spring's advisory cautioned the underlying data-binding issue is more general and other exploitation paths were plausible)
• A dependency on spring-webmvc or spring-webflux

Vulnerable Spring Framework versions span the 5.3.x line prior to 5.3.18 and the 5.2.x line prior to 5.2.20, as well as older, out-of-support 5.x and 4.x branches. Spring Boot applications built on the affected Spring Framework versions were indirectly at risk depending on packaging and container configuration. Because Spring Framework sits underneath countless internal frameworks, SDKs, and platform libraries, many organizations discovered the dependency several layers removed from their own application code — a pattern that made Spring4Shell, like Log4Shell before it, a transitive dependency problem as much as a direct one.

It's also worth distinguishing Spring4Shell from CVE-2022-22963, a separate SpEL injection RCE in Spring Cloud Function that was disclosed in the same week and was frequently conflated with Spring4Shell in early reporting. The two are distinct vulnerabilities in different Spring projects with different root causes, and remediation for one does not address the other.

Severity: CVSS, EPSS, and KEV Status

The National Vulnerability Database scored CVE-2022-22965 at 9.8 (Critical) under CVSS v3.1 — reflecting network-based attack vector, low attack complexity, no privileges required, and no user interaction, with high impact to confidentiality, integrity, and availability. That scoring is consistent with what the vulnerability delivers in practice: unauthenticated, remote, full RCE.

Exploitation began before the official patch was even available — a proof-of-concept was leaked publicly ahead of coordinated disclosure, and mass scanning and exploitation attempts followed within days, including botnet activity (Mirai variants) attempting to weaponize vulnerable instances. Given that trajectory, EPSS scoring has consistently placed CVE-2022-22965 in the highest percentile of exploitation likelihood among tracked CVEs, reflecting sustained real-world scanning and attack activity rather than theoretical risk.

CVE-2022-22965 was also added to CISA's Known Exploited Vulnerabilities (KEV) catalog in the days following disclosure, based on confirmed in-the-wild exploitation. For any organization operating under FCEB directives or using KEV status as a patching SLA trigger, Spring4Shell required emergency remediation rather than standard patch-cycle treatment.

Timeline

• March 29, 2022: Screenshots and a proof-of-concept exploit for an unpatched Spring Framework RCE circulated after a researcher's writeup and GitHub PoC were briefly published (and then pulled) ahead of coordinated disclosure — an accidental early leak that put defenders and attackers on the same footing simultaneously.
• March 30, 2022: Security researchers and vendors, including Wallarm, corroborated the vulnerability and dubbed it "Spring4Shell," drawing the (partly misleading) comparison to Log4Shell given the naming and the shared sense of urgency, even though the underlying mechanisms differ significantly.
• March 31, 2022: VMware (then steward of the Spring Framework) published an official advisory and shipped patched releases — Spring Framework 5.3.18 and 5.2.20 — along with patched Spring Boot 2.6.6 and 2.5.12 releases that pulled in updated dependencies.
• Following days: Apache Tomcat also released updates that independently hardened the ClassLoader-related gadget chain, providing a defense-in-depth mitigation even for applications that couldn't immediately upgrade Spring itself. Mass internet scanning for vulnerable endpoints was observed almost immediately, and multiple honeypot networks reported exploitation attempts within 48 hours of disclosure.

Remediation Steps

1. Upgrade Spring Framework to 5.3.18+ or 5.2.20+ (or the current supported patched line for your major version). This is the authoritative fix — it changes the data-binding allowlist behavior so class.* property paths cannot be manipulated through binding.
2. Upgrade Spring Boot to 2.6.6+ or 2.5.12+ if you consume Spring via Boot's dependency management, since these releases pin the patched Spring Framework version.
3. Patch Apache Tomcat independently (to the versions Apache published shortly after disclosure) as defense-in-depth, since Tomcat's own fix closes the specific gadget chain regardless of Spring's patch status — useful when a full framework upgrade can't happen immediately.
4. Audit for transitive exposure. Spring Framework is frequently pulled in indirectly through internal platforms, shared libraries, or vendor products. Confirm the resolved version in your dependency tree (mvn dependency:tree / gradle dependencies), not just your direct pom.xml/build.gradle declarations.
5. Apply interim mitigations if you cannot patch immediately: restrict binding of sensitive properties using WebDataBinder#setDisallowedFields (Spring's advisory published a @ControllerAdvice snippet for this), or downgrade to JDK 8 where the specific Tomcat gadget chain is not exploitable — understanding these are stopgaps, not substitutes for patching.
6. Check for indicators of compromise if you were running a vulnerable, internet-reachable Tomcat/Spring MVC WAR deployment between disclosure and patching — look for unexpected JSP files written to web-accessible directories (a hallmark of this exploitation chain), unfamiliar webshells, and anomalous outbound connections from application servers.

How Safeguard Helps

Spring4Shell was a hard lesson in how fast "which of our systems actually use this component, and how" needs to be answerable — and how often that answer lives three or four dependency layers deep, in code nobody on the security team wrote or reviewed recently. Safeguard is built for exactly that gap between disclosure and confident remediation.

• Continuous SBOM and dependency inventory so that when a CVE like this drops, you can query "where is spring-webmvc/spring-webflux in our estate, and at what version" in minutes rather than days of manually grepping build files across every repo and vendor artifact.
• Reachability and exploitability context, not just version matching. Because Spring4Shell's exploitability hinges on packaging (WAR vs. executable JAR), JDK version, and servlet container — not merely "is Spring Framework present" — Safeguard helps teams cut through blanket CVSS 9.8 alarm fatigue and prioritize the deployments that actually meet the exploit conditions first.
• Transitive dependency visibility across your software supply chain, surfacing Spring Framework even when it arrives bundled inside a third-party library, internal platform SDK, or vendor product rather than a direct dependency declaration.
• KEV and EPSS-aware prioritization, so vulnerabilities like CVE-2022-22965 that are actively exploited and CISA KEV-listed are automatically ranked above theoretical-risk findings in your remediation queue.
• Patch verification, confirming that the fix actually landed — the right Spring Framework and Spring Boot versions resolved, and no forked or overridden dependency silently reintroducing the vulnerable version later.

Spring4Shell won't be the last critical vulnerability discovered in a framework this deeply embedded in enterprise Java. What separates a contained incident from a multi-week fire drill is whether your organization can answer "are we affected, and where" with evidence in the first hour. That's the capability Safeguard exists to give security and platform teams, before the next Shell-named CVE makes headlines.