Case study: Spring4Shell (CVE-2022-22965)

On 31 March 2022 the Spring team announced 'an RCE vulnerability in the Spring Framework that was leaked out ahead of CVE publication.' It had been reported to VMware two days earlier by codeplutos and meizjm3i of AntGroup FG Security Lab; while the team worked on emergency releases, 'details were leaked in full detail online'. Spring Framework 5.3.18 and 5.2.20 shipped the same day as CVE-2022-22965, rated critical. The community called it Spring4Shell, echoing Log4Shell from December 2021; Spring's own posts do not use the name.

The flaw was in data binding, the feature that fills a Java object from request parameters. Spring's advisory: 'A Spring MVC or Spring WebFlux application running on JDK 9+ may be vulnerable to remote code execution (RCE) via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment.' A Spring Boot executable jar, the default, 'is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.'

That combination, a critical bug in one of the most used Java frameworks whose exploitability depended on deployment details, made it a hard triage problem. CISA added it to the Known Exploited Vulnerabilities catalog on 4 April 2022.

Spring's announcement explains the mechanism in one line: 'The issue relates to data binding used to populate an object from request parameters (either query parameters or form data).' Binding applies to controller parameters 'annotated with @ModelAttribute or optionally without it, and without any other Spring Web annotation.' A parameter named address.city sets getAddress().setCity(...): the name is a path through the object's properties. That is convenient, and it means the client chooses which properties to set.

Every Java object has a getClass() method, which the bean machinery sees as a property called class, so a path that starts with class. leaves the form object and walks into the Class object. Spring already blocked the dangerous step: before the fix, CachedIntrospectionResults ignored the classLoader and protectionDomain properties of Class by name. The fix commit, 'Refine PropertyDescriptor filtering', replaced that with two broader rules: on Class, allow only name and its variants; anywhere, ignore every property whose type is a ClassLoader or ProtectionDomain. The JDK 9 condition fits that change: JDK 9 gave Class new getters, including getModule(), and Module has its own getClassLoader(). Third-party exploit write-ups describe exactly that route, through class.module.classLoader; Spring's own posts say only that 'The vulnerability involves ClassLoader access and depends on the actual Servlet Container in use.'

This is the same weakness as mass assignment (CWE-915) in application code, one level down: the framework, not the developer, decided which properties were reachable. The application-level guide to mass assignment (/domains/appsec/authorization/function-property-authorization/) and the Spring mass-assignment fix card (/fix/mass-assignment/java-spring/) apply the same remedy, an explicit allowlist of bindable fields.

Spring listed the requirements for the reported scenario: JDK 9 or higher; packaged as a traditional WAR and deployed on a standalone Servlet container; spring-webmvc or spring-webflux; and an affected Spring Framework version. 'Typical Spring Boot deployments using an embedded Servlet container or reactive web server are not impacted.' Tomcat 10.0.19, 9.0.61, 8.5.77 and earlier were known to be vulnerable, as were Payara and GlassFish, and 'Other Servlet containers may also be vulnerable.'

That made triage harder, not easier. A team with hundreds of services had to know, for each one, the JDK, the packaging, the container and the binding style, and the answer 'Boot jar, so not vulnerable to this exploit' came with Spring's caveat that other exploitation paths might exist. With an SBOM and deployment metadata per service, that is a query; without them, it means reading build files and deployment scripts service by service. The dependency response guide (/domains/appsec/vulnerability-response/dependency-vulnerability-response/) covers the workflow, and the Log4Shell case study (/domains/appsec/vulnerability-response/case-study-log4shell/) the same race four months earlier.

For teams that could not upgrade at once, Spring offered three workarounds: upgrade Tomcat, downgrade to Java 8, or set disallowedFields on every WebDataBinder globally with the patterns class.*, Class.*, *.class.* and *.Class.*. Spring itself warned that the global setting 'may leave some loopholes, in particular if a controller sets disallowedFields locally through its own @InitBinder method, which overrides the global setting', and gave a more fail-safe variant that extends RequestMappingHandlerAdapter.

Two weeks later CVE-2022-22968 showed another gap: the patterns 'are case sensitive', so a field is protected only if both the upper- and lower-case first letter are listed, including in nested paths. A denylist has to anticipate every spelling of every dangerous path; an allowlist only has to list the fields the form needs. The Tomcat upgrade was likewise described as 'a tactical solution, and the main goal should be to upgrade to a currently supported Spring Framework version as soon as possible.'

The script reads a CycloneDX JSON SBOM and flags spring-beans, spring-webmvc and spring-webflux below the fixed versions, Tomcat below the releases that closed the vector, and any Spring Framework line that no longer gets open-source fixes. Pass --war for services packaged as WAR files, which matched the reported exploit's conditions. It ran with Python 3.14 on two sample SBOMs: one with Spring 5.3.17 and Tomcat 9.0.60, which it flags, and one with Spring 7.0.8, which it passes. Update OSS_SUPPORTED from Spring's versions page when you use it.

"""Check a CycloneDX JSON SBOM for CVE-2022-22965 (Spring4Shell) exposure.

Flags spring-beans, spring-webmvc and spring-webflux below 5.2.20 / 5.3.18,
Tomcat below 8.5.78 / 9.0.62 / 10.0.20, and Spring Framework lines that no
longer get open-source fixes. Usage: spring4shell_sbom.py sbom.json [--war]
"""
import json
import re
import sys

SPRING = {"spring-beans", "spring-webmvc", "spring-webflux"}
SPRING_FIXED = {(5, 2): (5, 2, 20), (5, 3): (5, 3, 18)}
TOMCAT_FIXED = {(8, 5): (8, 5, 78), (9, 0): (9, 0, 62), (10, 0): (10, 0, 20)}
OSS_SUPPORTED = {(7, 0)}  # check the Spring Framework versions wiki when you run this


def parse(version):
    return tuple(int(n) for n in re.findall(r"\d+", version)[:3])


def findings(sbom, war):
    for c in sbom.get("components", []):
        group, name, v = c.get("group", ""), c.get("name", ""), parse(c.get("version", "0"))
        if group == "org.springframework" and name in SPRING:
            fixed = SPRING_FIXED.get(v[:2])
            if v[:2] < (5, 2) or (fixed and v < fixed):
                yield f"{name} {c['version']}: vulnerable to CVE-2022-22965" + (
                    " (packaged as a WAR, as the reported exploit requires)" if war else "")
            if v[:2] not in OSS_SUPPORTED:
                yield f"{name} {c['version']}: line {v[0]}.{v[1]} gets no open-source fixes; upgrade"
        if group.startswith("org.apache.tomcat") and name in ("tomcat-embed-core", "tomcat-catalina"):
            fixed = TOMCAT_FIXED.get(v[:2])
            if fixed and v < fixed:
                yield f"{name} {c['version']}: below the Tomcat release that closes the vector"


if __name__ == "__main__":
    with open(sys.argv[1], encoding="utf-8") as f:
        found = list(findings(json.load(f), "--war" in sys.argv))
    print("\n".join(found) or "no Spring4Shell exposure found")
    sys.exit(1 if found else 0)

Upgrading is the fix. As defense in depth, give each form a binder allowlist, or bind to a dedicated request type that has only the fields the client may set. The advice below applies setAllowedFields to one named model attribute. A JUnit test bound email, admin and class.name to the form with this configuration: only email was set, and the binding result listed admin and class.name as suppressed fields. It compiled and passed against Spring Framework 7.0.8 on JDK 21. Name the model attribute in @InitBinder so the allowlist applies only to the form it was written for.

package example;

import org.springframework.web.bind.WebDataBinder;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.InitBinder;

// Defense in depth, not a substitute for a fixed Spring Framework:
// bind only the fields each form declares, so request parameters can never
// reach other properties, nested objects or framework internals.
@ControllerAdvice
public class BindingAllowlist {

    @InitBinder("signupForm")
    public void signupFields(WebDataBinder binder) {
        binder.setAllowedFields("email", "name");
    }
}

• Binding is mass assignment by design. Decide which fields a request may set, per form, and enforce it with an allowlist or a dedicated type.
• A denylist of dangerous paths is a race against spellings; CVE-2022-22968 lost it within two weeks.
• Exploitability that depends on deployment details makes triage slower unless you already know each service's JDK, packaging and container.
• Patch the framework, not just the container: the Tomcat fix closed one route, and Spring warned of others.
• Being on a supported line is the precondition for a quick fix. In October 2026 that means Spring Framework 7.0.x for open-source support.

Spring's posts do not describe the exploit path or payloads; the route through class.module.classLoader and the use of Tomcat's logging configuration come from third-party exploit write-ups, consistent with the fix commit but not confirmed by Spring. The public record does not establish how widely CVE-2022-22965 was exploited or by whom, beyond CISA's KEV listing of known exploitation. Whether deployments outside Tomcat, Payara and GlassFish, or Spring Boot executable jars, could be exploited in practice is not established either way; Spring's statement that 'there may be other ways to exploit it' is a caution, not a finding.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. Spring blog: Spring Framework RCE, early announcement. 31 March 2022, updated through 13 April 2022.
2. Spring security advisory: CVE-2022-22965, Spring Framework RCE via data binding on JDK 9+. 31 March 2022.
3. Spring blog: Spring Framework RCE, mitigation alternative. 1 April 2022.
4. Spring security advisory: CVE-2022-22968, Spring Framework data binding rules vulnerability. 13 April 2022.
5. spring-framework commit 002546b: Refine PropertyDescriptor filtering. 31 March 2022.
6. NVD: CVE-2022-22965
7. CISA Known Exploited Vulnerabilities catalog. Catalog version 2026.10.08.
8. Spring Framework wiki: Spring Framework versions and support

Reference information

Tags

Access controlDependency managementVulnerability managementJava

SDLC phase

DevelopmentMaintenance

Role

DevelopersAppSec engineersPlatform engineers and SREs

CAPEC attack patterns

• CAPEC-242 at MITRE

Download this guide as Markdown

Continue exploring