CVE-2022-22965 (Spring4Shell): Spring Framework RCE on Tomcat WAR deployments, actively exploited
The short version: Spring4Shell (CVE-2022-22965) is a data-binding flaw in the Spring Framework that lets an unauthenticated attacker execute code against a Spring MVC or WebFlux application running on JDK 9+ when it's deployed as a WAR on Apache Tomcat. It's in CISA's KEV catalog and was exploited broadly. If you run an affected Spring app that way, patch the framework now. Steady hands — but move.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | Critical — unauthenticated RCE, mass-exploited, on a ubiquitous framework |
| CVSS v3.1 (NVD) | 9.8 — Critical · AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| EPSS | ~99.68% · 99.95th percentile (2026-07-17) |
| In CISA KEV? | Yes — remediation was due 2022-04-25 |
| Known exploited? | Yes — mass exploitation shortly after disclosure |
| Vulnerability type | CWE-94 code injection (via unsafe data binding) → unauthenticated remote code execution |
| Requires authenticated session? | No — pre-authentication |
| Affected | Spring Framework < 5.2.20 and < 5.3.18, on JDK 9+, deployed as a WAR on Tomcat (older unsupported branches also affected) |
| Fixed in | Spring Framework 5.3.18 · 5.2.20 (and Spring Boot 2.6.6 / 2.5.12) |
What you need to know
Spring4Shell is a remote-code-execution flaw in the Spring Framework's data binding. On JDK 9+, an attacker can manipulate the binding to reach class-loader properties and write a file — for example, a web shell — yielding code execution. The classic, widely exploited path requires the application to run on Apache Tomcat as a WAR deployment.
Two important qualifiers that shape exposure:
- Deployment matters. A Spring Boot application packaged as the default executable JAR is not vulnerable to the known exploit. The WAR-on-Tomcat pattern is the one that gets hit.
- The class of bug is broader. The specific exploit is narrow, but the underlying data-binding weakness is general — which is why the vendor treats patching the framework, not just blocking one payload, as the real fix.
Beyond that: it's unauthenticated, network-reachable, and Spring is everywhere, so it saw mass exploitation within days of disclosure and landed in KEV immediately.
How serious we see it
Critical — the 9.8 is earned.
Unauthenticated remote code execution against one of the most widely deployed application frameworks, mass-exploited in the wild, is top-of-queue by any measure. The bounded, reassuring part is real, though: the known exploit needs a specific setup (Spring MVC/WebFlux on JDK 9+, WAR on Tomcat), default Spring Boot JARs aren't vulnerable to it, and the framework fixes are published. Patch the framework rather than relying on payload filters, and you close the general weakness, not just today's exploit.
Recommendations
Straight from Spring's advisory and CISA:
- Patch the framework now. Upgrade to Spring Framework 5.3.18 / 5.2.20 or later (or Spring Boot 2.6.6 / 2.5.12+).
- Inventory WAR-on-Tomcat deployments. Identify Spring MVC/WebFlux apps running on JDK 9+ as WARs on Tomcat — the exploitable pattern.
- Hunt for prior use. Look for unexpected files (e.g., web shells) and anomalous requests manipulating
class.*binding parameters. - If you find indicators, respond. Remove planted files, rotate credentials, and investigate for lateral movement.
- Confirm your exposure first. Verify Spring Framework versions and how each app is deployed.
How BreachRisk sees it
BreachRisk discovers your internet-facing web applications from little more than your domain, fingerprints Spring/Tomcat exposure where it can, and flags assets tied to KEV-listed vulnerabilities like Spring4Shell — surfaced at the top of your results because it's in KEV.
That continuous, outside-in view is the point: when a framework-level RCE breaks, you don't want to start by inventorying every app — the exposed, affected surface is already mapped so you can go straight to patch-and-verify.