CVE-2022-22965: Spring4Shell RCE in Spring

Spring4Shell (CVE-2022-22965) is a Spring MVC/WebFlux data-binding RCE. The reported path required JDK 9+, a Servlet container, WAR packaging, and affected Spring Framework versions.^{[1], [2]}

💡 Plain English Explainer (ELI5)

Imagine a clerk allowed to edit one field on a form. The form contains nested references, and the clerk can follow them into a restricted control panel instead of stopping at the approved field. Spring’s unsafe data binding similarly let request fields traverse Java object properties beyond the intended form.^{[1], [2]}

Core Concepts & Subsystem Terms

Java BeanWrapper: Spring MVC/WebFlux feature that binds request parameters to object properties.^[2]
Tomcat AccessLogValve: A Java runtime component whose exposure through property traversal was part of the reported scenario; no specific Tomcat file-writing chain is asserted here.^[6]
JDK 9+ Module System: The reported Spring scenario required JDK 9 or higher.^[1]

Framework mappings

CWE reference for the weakness described in this guide: CWE-94
CISA KEV — added 2022-04-04 — CVE-2022-22965

Root Cause Analysis

In affected versions, binding could traverse properties exposed through java.lang.Class on JDK 9+; the reported path also required Tomcat and WAR packaging. That configuration could let an unauthenticated remote attacker reach code execution with the application process privileges. Spring noted that other ways to exploit the broader issue might exist.^{[1], [2], [6]}

Step-by-Step Attack Flow

Step 1

Reachable data binding

A Spring MVC or WebFlux controller binds query or form parameters to an @ModelAttribute object.^[2]

Step 2

Unsafe property traversal

The reported path required JDK 9+, Spring MVC/WebFlux data binding, a traditional WAR deployment, and a vulnerable Servlet container; Spring identifies Tomcat and later notes Payara/GlassFish too.^{[1], [2], [6]}

Step 3

Impact boundary

That configuration could let an unauthenticated remote attacker reach code execution with the application process privileges. Spring noted that other ways to exploit the broader issue might exist.^{[1], [2]}

Step 4

Remediation

Upgrade Spring Framework to a fixed supported release. Treat container workarounds as temporary and verify the deployed dependency versions.^{[1], [3]}

Source Code: Flaw vs. Secure Implementation

UNPATCHED FLAW

// Representative affected dependency coordinate; not Spring Framework source.
implementation("org.springframework:spring-webmvc:5.3.17")
// Spring MVC/WebFlux request data binding in affected releases could traverse
// properties exposed through java.lang.Class on JDK 9+.

HARDENED SECURE PATCH

// Minimum historical fixed version for the 5.3 line, per Spring advisory.
implementation("org.springframework:spring-webmvc:5.3.18")
// Prefer a currently supported Spring release in production.
// The framework patch closes the root cause; binder/container workarounds
// are temporary mitigations for deployments that cannot upgrade immediately.

Engineering & System Hardening Checklist

✓Upgrade Spring Framework to a supported release; the minimum historical fixes were 5.3.18 and 5.2.20.RELEASE. Confirm the resolved dependency tree contains no earlier affected version.^{[1], [2]}
✓Inventory JDK, Spring MVC/WebFlux, servlet container, and WAR/JAR packaging for every deployed service.^[2]
✓For temporary mitigation when a framework upgrade is delayed, configure WebDataBinder to disallow class.*, Class.*, *.class.*, and *.Class.* globally.^[2]
✓For a temporary Tomcat-side workaround, verify Tomcat is at 10.0.20+, 9.0.62+, or 8.5.78+; still schedule a supported Spring upgrade.^{[3], [2]}
✓Add an integration test that exercises each controller-level @InitBinder and verifies that the global denylist still blocks those four property patterns; if it does not, implement Spring’s documented adapter-level workaround.^[2]