CVE-2022-22965, widely known as Spring4Shell o SpringShell, is a critical remote code execution vulnerability in the Spring Framework that became public in March 2022. Its impact was serious enough to earn a CVSS v3.1 base score of 9.8, and the vulnerability remains listed in the U.S. Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities catalog. CISA’s current vulnerability data continues to identify exploitation as active, making Spring4Shell relevant wherever legacy Java applications remain exposed. (National Vulnerability Database)
The important qualification is that CVE-2022-22965 does not make every Spring application remotely exploitable. The original publicly demonstrated attack depended on a fairly specific combination of Spring data binding, JDK 9 or later, a vulnerable application configuration, and a Servlet-container deployment that exposed a useful ClassLoader path. The classic exploit was particularly associated with traditional WAR applications running on Apache Tomcat. Spring’s own advisory explicitly states that the default Spring Boot executable-JAR deployment does not satisfy the original exploit scenario. (Inicio)
Understanding that distinction is essential. Looking only for a vulnerable spring-webmvc JAR can identify software that needs upgrading, but it does not tell you whether the running application is immediately exploitable through the famous Spring4Shell attack chain. Conversely, assuming an application is safe simply because an old proof of concept fails can also be dangerous: Spring emphasized from the beginning that the underlying weakness was broader than one Tomcat-specific technique. (Inicio)
CVE-2022-22965 at a Glance
| Artículo | CVE-2022-22965 Spring4Shell |
|---|---|
| Vulnerabilidad | Spring Framework remote code execution through data binding |
| Gravedad | Crítica |
| NVD CVSS v3.1 | 9.8 |
| Primary affected components | Spring MVC and Spring WebFlux applications |
| Runtime requirement for original exploit | JDK 9 or later |
| Classic deployment scenario | Traditional WAR on a vulnerable Servlet container, especially Tomcat |
| Historically affected Spring versions | 5.3.0–5.3.17, 5.2.x through 5.2.19, plus older unsupported releases |
| Initial fixed versions | Spring Framework 5.3.18 and 5.2.20 |
| Exploited in the wild | Yes; included in CISA KEV |
| Authentication required | The CVSS vector describes network exploitation without privileges or user interaction |
These details are based on the Spring security advisory and current NVD record. (spring.io)
What Is Spring4Shell?
Spring Framework contains a powerful data-binding mechanism designed to turn incoming HTTP parameters into Java object properties. In a typical MVC controller, an application may receive request parameters such as:
firstName=Alice
lastName=Smith
address.city=Seattle
Spring can map those values onto a model object automatically. That convenience is fundamental to many Spring MVC applications, but it also means that the framework must decide which property paths an external HTTP request is allowed to traverse. Spring confirms that CVE-2022-22965 concerns this data-binding mechanism and applies particularly to controller parameters populated from query parameters or form data. (Inicio)
Spring4Shell appeared because attackers could reach property paths that application developers never intended remote users to control. In the vulnerable environment, the object graph reachable through data binding could eventually expose powerful class-loading infrastructure. Once an attacker could manipulate suitable properties behind that boundary, the vulnerability could potentially be transformed from an unintended object-property modification into arbitrary code execution. (Inicio)
The Spring Framework project addressed the underlying problem by restricting access to property paths through Clase references. The related Spring Framework issue is explicitly titled “Restrict access to property paths on Class references” and was assigned to the Spring Framework 5.3.18 milestone. (GitHub)
Why JDK 9 Was Critical to Spring4Shell
One of the most frequently misunderstood Spring4Shell exploit conditions is the requirement for JDK 9 or later in the original vulnerability scenario.
Before Spring4Shell, Spring already contained protections intended to prevent dangerous traversal through properties related to Java’s Clase object and its class loader. Java 9 changed the available object relationships by introducing the Java Platform Module System. That altered the reachable property graph and opened another route through which an attacker could potentially move from an ordinary bound object toward class-loading internals. Spring consequently lists JDK 9+ as a prerequisite for the reported exploit. (Inicio)
This explains why Java version checking became an important part of Spring4Shell triage.
A defender can start with:
java -version
For a running JVM on Linux, useful inventory commands may include:
ps -ef | grep java
and, where process permissions allow:
readlink -f /proc/<PID>/exe
The purpose of this check is not to declare every Java 9+ application vulnerable. It merely establishes one of the conditions needed by the original Spring4Shell exploitation path. Spring itself recommended Java 8 as a temporary workaround for organizations that could not immediately upgrade Spring Framework or Tomcat, although that was explicitly a tactical measure rather than the preferred long-term solution. (Inicio)
The Spring Data Binding Problem
The heart of CVE-2022-22965 is easier to understand if data binding is treated as an authorization boundary.
Imagine a controller like this:
@PostMapping("/profile")
public String updateProfile(UserProfile profile) {
// process profile
return "success";
}
A request might legitimately supply:
name=Alice&department=Security
Spring populates the Perfil de usuario object from those HTTP parameters.
The security question is: should the remote client be allowed to specify arbitrary nested property paths reachable from Perfil de usuario?
Usually, the answer is no.
Spring’s own guidance after the incident emphasized that developers should reconsider using large domain objects directly as data-binding targets. The project recommends dedicated model objects that expose only properties relevant to the operation, or explicit allowed-field patterns rather than relying solely on denial rules. Spring also advises against using JPA or Hibernate domain entities directly as web data-binding models. (Inicio)
This is one of the most enduring lessons from Spring4Shell: the security problem was not merely “a bad URL parameter.” It was that an apparently convenient mapping mechanism gave attacker-controlled request data access to an unexpectedly powerful object graph.
The Classic Spring4Shell RCE Exploit Chain
The original attack can be understood conceptually as five stages:
Attacker-Controlled HTTP Parameters
↓
Spring MVC / WebFlux Data Binding
↓
Unexpected Property Traversal
↓
Class / Module / ClassLoader Objects
↓
Servlet-Container-Specific Writable Configuration
↓
Server-Side Code Execution
The first important point is that data binding itself is not equivalent to RCE. An attacker needs to transform the ability to manipulate unintended Java properties into a security-sensitive effect in the surrounding runtime. (Inicio)
Apache Tomcat provided such an environment in the original widely discussed exploit scenario. Spring specifically identified Tomcat versions 10.0.19, 9.0.61, 8.5.77 and earlier as known vulnerable to the relevant attack vector at disclosure time. Apache subsequently released Tomcat 10.0.20, 9.0.62 and 8.5.78 with class-loader hardening intended to close that Spring4Shell path. (Inicio)
Importantly, Spring clarified that the vulnerability was not a Tomcat vulnerability itself. Tomcat simply supplied one environment through which the Spring Framework weakness could be converted into practical code execution. That is why fixing Spring Framework remains the more fundamental remediation. (Inicio)
Exact Spring4Shell Exploit Conditions
For the originally reported CVE-2022-22965 exploitation scenario, Spring documented the following prerequisites:
- JDK 9 or later
- Spring MVC or Spring WebFlux
- A vulnerable Spring Framework version
- A traditional WAR deployment
- A standalone Servlet container capable of exposing the required ClassLoader path
Spring’s current security advisory specifically lists Apache Tomcat as the Servlet container required for the documented exploit, while the earlier detailed announcement also notes that later research identified vulnerable behavior in Payara and GlassFish. (Inicio)
But another application-specific condition matters just as much: there must be a reachable endpoint where attacker-controlled request parameters are subjected to Spring data binding.
Spring explains that this applies to controller parameters annotated with @ModelAttribute, or parameters that Spring implicitly treats as model attributes because they are not associated with another web annotation. (Inicio)
Therefore, a more useful exploitability equation is:
Vulnerable Spring Version
+
JDK 9+
+
Reachable Data-Binding Endpoint
+
Useful Object Property Graph
+
Exploitable Servlet Container / Deployment
=
Potential Spring4Shell RCE
This is why asset scanners and penetration tests should separate component vulnerability de demonstrated exploitability.
Es @RequestBody Vulnerable to Spring4Shell?
Not by the same mechanism.
Spring explicitly states that CVE-2022-22965’s data-binding issue does not concern controller method parameters using @RequestBody, such as ordinary JSON deserialization. (Inicio)
Por ejemplo:
@PostMapping("/users")
public void create(@RequestBody CreateUserRequest request) {
}
does not use the same form/query-parameter binding mechanism that triggered the reported Spring4Shell attack.
However, Spring also warns about an important edge case: a controller containing @RequestBody can still have otro parameter populated through data binding from query parameters. The presence of JSON handling therefore does not prove that the entire endpoint is unaffected. (Inicio)
Security teams should review complete controller signatures rather than simply searching source code for @RequestBody.
Why Traditional WAR Deployment Matters
Spring’s advisory makes a clear distinction between traditional WAR applications and Spring Boot’s usual executable-JAR model.
A classic enterprise deployment often looks like:
application.war
↓
Standalone Apache Tomcat
↓
Tomcat Web Application ClassLoader
The original Spring4Shell exploit depended on relationships available in this environment. (Inicio)
A typical Spring Boot application instead looks more like:
java -jar application.jar
↓
Spring Boot
↓
Embedded Servlet Container
Spring states that normal Spring Boot applications using an embedded Servlet container—or a reactive web server—are not affected by the specific reported exploit. (Inicio)
That wording matters.
It is incorrect to say:
Spring Boot applications can never be affected by CVE-2022-22965.
The safer statement is:
Default Spring Boot executable-JAR deployments do not satisfy the original publicly documented Spring4Shell exploit conditions.
Spring repeatedly cautioned that the underlying vulnerability was more general and that alternative exploitation paths could exist. (Inicio)
Which Spring Framework Versions Were Affected?
At disclosure, Spring identified the affected Spring Framework branches as:
| Spring Framework branch | Status |
|---|---|
| 5.3.0–5.3.17 | Vulnerable |
| 5.2.0–5.2.19 | Vulnerable |
| Older unsupported releases | Potentially affected |
| 5.3.18 | Original CVE-2022-22965 fix |
| 5.2.20 | Original CVE-2022-22965 fix |
Spring Framework 5.3.18 and 5.2.20 were released specifically with the CVE-2022-22965 fixes. Spring Boot 2.6.6 and 2.5.12 subsequently incorporated Spring Framework 5.3.18. (Inicio)
Today, however, organizations should not treat 5.3.18 or 5.2.20 as recommended modern target versions merely because they fixed Spring4Shell in 2022. They are historical remediation baselines. The correct operational approach is to migrate to a currently supported Spring Framework/Spring Boot release appropriate for the application rather than stopping at a four-year-old patch level.
How to Check Whether an Application Contains a Vulnerable Spring Version
For Maven projects, defenders can examine the dependency tree:
mvn dependency:tree | grep spring
or narrow the search:
mvn dependency:tree | grep spring-web
For Gradle:
./gradlew dependencies | grep spring
For packaged WAR files:
jar tf application.war | grep spring
A typical vulnerable artifact might expose something resembling:
WEB-INF/lib/spring-webmvc-5.3.17.jar
WEB-INF/lib/spring-beans-5.3.17.jar
WEB-INF/lib/spring-core-5.3.17.jar
Finding one of these historical versions establishes a strong need for remediation, but it does not independently demonstrate remote exploitability. The deployment model, Java version and reachable request-binding behavior still matter. (Inicio)
Spring4Shell Is Not CVE-2022-22963
Spring4Shell emerged during a confusing week for Spring security because another critical RCE—CVE-2022-22963—had been disclosed just beforehand.
They are different vulnerabilities.
CVE-2022-22963 affected Spring Cloud Function and concerned malicious Spring Expression Language processing. Spring published that vulnerability on March 29, 2022. CVE-2022-22965, disclosed two days later, concerned Spring Framework data binding. (Inicio)
A useful distinction is:
| Vulnerabilidad | Componente | Core mechanism |
|---|---|---|
| CVE-2022-22963 | Spring Cloud Function | Malicious Spring Expression |
| CVE-2022-22965 | Spring Framework | Data-binding property traversal |
Treating these CVEs as interchangeable can produce both false positives and false negatives during vulnerability management.
Spring4Shell Is Also Not Log4Shell
The nickname caused another widespread misconception.
Log4Shell, CVE-2021-44228, involved Apache Log4j and JNDI-related lookup behavior. Spring4Shell is a Spring Framework data-binding vulnerability. They affect different software components and use fundamentally different exploitation mechanisms.
The naming similarity came largely from the severity, timing and ubiquity concerns surrounding Spring—not from a technical relationship between the vulnerabilities.
For defenders, this distinction matters because Log4Shell detection signatures, JNDI network controls or Log4j dependency searches do not detect CVE-2022-22965.
Why CVE-2022-22965 Was So Dangerous
NVD currently assigns CVE-2022-22965 a CVSS v3.1 score of 9.8 Critical, using the vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
That reflects a vulnerability reachable over a network, requiring no prior privileges and no user interaction, with potentially high confidentiality, integrity and availability impact when successfully exploited. (National Vulnerability Database)
CISA added CVE-2022-22965 to its Known Exploited Vulnerabilities catalog on April 4, 2022, requiring covered U.S. federal organizations at the time to remediate it by April 25, 2022. The current NVD record continues to reference the KEV entry and describes the exploitation status as active in its CISA SSVC information. (National Vulnerability Database)
This is important in 2026 because the biggest Spring4Shell risk is no longer newly developed Spring applications. It is forgotten infrastructure: old WAR deployments, legacy internal portals, middleware, third-party enterprise products and Java applications that have survived multiple modernization cycles without dependency upgrades.
How Attackers Find Spring4Shell Targets
Attackers do not necessarily need to know that an application uses Spring before probing it. Internet-facing Java applications can be fingerprinted through response behavior, technology metadata, error handling, application structure or product intelligence.
A realistic attacker workflow may look like:
Internet Asset Discovery
↓
Java / Spring Fingerprinting
↓
Identify Candidate Request Parameters
↓
Probe Data-Binding Behavior
↓
Determine Runtime / Container Characteristics
↓
Attempt CVE-2022-22965 Validation
↓
Post-Exploitation
The key defensive implication is that vulnerability discovery and exploit verification are different stages. A scanner that sees Spring 5.3.17 should raise an important exposure finding; an authorized penetration test can then determine whether externally reachable request handling actually crosses the conditions required for RCE.
How to Detect Spring4Shell Exploitation
Detection should combine HTTP telemetry, JVM/application logs, filesystem changes and process activity rather than relying on one request signature.
At the application edge, security teams should investigate unusual query or form parameters containing deep Java-style property traversal, especially attempts to reference class-, module- or class-loader-related properties. These patterns are extremely unusual in legitimate user input and make useful hunting indicators.
A conceptual detection rule might focus on requests containing combinations conceptually similar to:
class
module
classLoader
within nested HTTP parameter names.
These should be treated as behavioral indicators rather than permanent exploit signatures because attackers can modify parameter structure and because the underlying weakness is broader than one proof-of-concept payload. Spring itself described the problem in terms of ClassLoader access through data binding rather than one fixed network string. (Inicio)
Filesystem Detection
Because the widely publicized Tomcat exploitation approach converted configuration manipulation into server-side code execution, unexpected file creation beneath web-accessible application directories is especially suspicious.
Defenders should investigate:
Unexpected .jsp creation
Changes beneath web application directories
Recently modified files owned by the Tomcat service account
Unrecognized JSP files containing command-execution logic
Unexpected modification of Tomcat logging configuration
Monitoring the web root for newly created executable content remains useful even beyond Spring4Shell because many Java web exploitation techniques eventually need a persistence or execution primitive.
A basic retrospective Linux hunt could include:
find /var/lib/tomcat* /opt/tomcat* \
-type f -name "*.jsp" \
-mtime -30 2>/dev/null
The exact application paths will vary substantially between environments, so defenders should adapt filesystem monitoring to their own Tomcat configuration.
Process-Level Detection
A successful Java web compromise often leaves process behavior that is easier to detect than the original HTTP request.
Examples worth investigating include a Tomcat or Java process unexpectedly spawning:
/bin/sh
/bin/bash
curl
wget
python
perl
nc
powershell.exe
cmd.exe
A high-value behavioral rule is:
Parent process: java / tomcat
↓
Unexpected command shell
↓
Network connection or downloaded executable
That chain does not uniquely identify Spring4Shell, but it is strongly relevant to detecting exploitation that has progressed beyond initial access.
Network Detection
Defenders should also correlate suspicious web requests with unusual outbound connections from Java application servers.
An application server that normally communicates only with a database and several internal APIs should not suddenly establish connections to arbitrary Internet hosts.
A useful investigation sequence is:
Suspicious HTTP Request
↓
Java Server
↓
Unexpected File Creation
↓
Shell Process
↓
External Network Connection
Correlating these events is substantially more reliable than treating a single WAF signature as proof of compromise.
How to Mitigate CVE-2022-22965
The primary remediation is straightforward:
Upgrade Spring Framework.
At disclosure, Spring released:
Spring Framework 5.3.18
Spring Framework 5.2.20
as the fixed versions for CVE-2022-22965. The project explicitly stated that updating Spring Framework addresses the root cause and should be preferred over container-specific workarounds. (Inicio)
For an organization maintaining systems today, however, those versions should be understood only as the minimum historical fixed points. New deployments should use an appropriate currently supported Spring release rather than deliberately upgrading an application to 5.3.18 merely to clear the original CVE.
Tomcat Mitigation
Apache Tomcat also hardened its class loader in response to the Spring Framework vulnerability.
The Spring and Apache records identify these releases as closing the original Tomcat-side attack vector:
Tomcat 10.0.20
Tomcat 9.0.62
Tomcat 8.5.78
Apache’s release notes explicitly describe the change as class-loader hardening to mitigate CVE-2022-22965. (Inicio)
Spring nevertheless stressed that upgrading Tomcat should be considered a tactical mitigation, particularly for applications stuck on unsupported Spring versions. Fixing the Spring Framework remains preferable because it addresses the root cause and other possible exploitation paths. (Inicio)
Java 8 as a Temporary Workaround
Spring also identified downgrading to Java 8 as a viable emergency workaround where neither Spring Framework nor Tomcat could immediately be updated. (Inicio)
That recommendation made sense specifically because the reported attack depended on functionality introduced with Java 9.
It should not be interpreted as:
Java 8 = secure configuration
Downgrading a runtime simply to avoid one vulnerability is not a sustainable security strategy. In a modern environment, patching the vulnerable framework and maintaining a supported Java runtime is much safer.
Do Not Rely Only on disallowedFields
Spring originally published a workaround based on restricting dangerous data-binding paths using WebDataBinder.setDisallowedFields().
Conceptually:
@InitBinder
public void initBinder(WebDataBinder binder) {
binder.setDisallowedFields(
"class.*",
"Class.*",
"*.class.*",
"*.Class.*"
);
}
Spring warned even at the time that centrally defined restrictions could be overridden by controller-specific @InitBinder configuration. (Inicio)
The situation became more significant two weeks later, when Spring published CVE-2022-22968 after discovering that disallowedFields matching had previously been case sensitive. Spring Framework 5.3.19 and 5.2.21 changed that behavior to make those patterns case-insensitive. (Inicio)
This history demonstrates why denylisting dangerous property names is weaker than eliminating the vulnerable data-binding boundary altogether.
Use Allowlisted Data-Binding Models
Spring’s longer-term recommendation is much stronger: expose only the fields that a request genuinely needs.
For example, instead of binding directly onto a database entity:
public class User {
private Long id;
private String username;
private String role;
private boolean admin;
// ...
}
create a dedicated request model:
public class UpdateProfileRequest {
private String displayName;
private String biography;
}
The latter defines a much smaller attack surface.
Spring specifically recommends dedicated model objects and notes that developers can use setAllowedFields() when explicit binding control is needed. It also warns against exposing JPA or Hibernate entity types directly to request data binding. (Inicio)
This is the architectural fix behind the patching conversation: untrusted request data should not be allowed to traverse powerful application object graphs simply because those objects expose JavaBean properties.
Recommended Remediation Priority
For defenders discovering Spring4Shell exposure today, a practical priority order is:
| Prioridad | Acción |
|---|---|
| Crítica | Identify Internet-facing vulnerable Spring Framework applications |
| Crítica | Upgrade to a supported Spring Framework/Spring Boot release |
| Crítica | Investigate exposed WAR deployments on standalone Servlet containers |
| Alta | Upgrade legacy Tomcat environments |
| Alta | Review request data-binding models |
| Alta | Hunt for historical compromise |
| Medio | Add behavioral WAF/IDS detection |
| Medio | Restrict unnecessary Internet exposure |
| Long term | Replace broad domain-object binding with explicit request DTOs |
The rationale comes directly from Spring’s preference for upgrading the framework and strengthening data-binding design rather than depending indefinitely on tactical container or binder denylist workarounds. (Inicio)
Should You Still Scan for Spring4Shell in 2026?
Yes—particularly in enterprise environments.
The vulnerability was published on March 31, 2022, yet it remains in CISA’s Known Exploited Vulnerabilities catalog, and NVD’s current CISA-derived SSVC information describes exploitation as active. (National Vulnerability Database)
That does not mean Spring4Shell should outrank every newly disclosed vulnerability. Risk should still be based on reachable assets and exploitability.
An Internet-facing Spring Framework 5.3.17 WAR running on an old standalone Tomcat server and JDK 11 deserves very different treatment from an isolated executable-JAR application whose affected dependency is unreachable through Spring MVC.
A modern vulnerability-management program should therefore ask:
Is the vulnerable component present?
↓
Is the affected code path reachable?
↓
Are the runtime exploit conditions present?
↓
Is the asset exposed to an attacker?
↓
Can exploitation be safely validated?
That model produces far better results than treating every CVE match as an equally urgent finding.
Spring4Shell and the Difference Between Scanning and Exploit Validation
CVE-2022-22965 is also an excellent example of why vulnerability scanning and penetration testing answer different questions.
Software composition analysis may tell you:
spring-webmvc 5.3.17 detected
→ CVE-2022-22965 present
That is valuable.
But it cannot necessarily tell you:
An unauthenticated attacker can reach a vulnerable binding endpoint,
traverse the required property graph,
reach a usable Servlet-container primitive,
and execute code.
Determining the latter requires runtime context.
For high-risk vulnerabilities such as Spring4Shell, security teams benefit from separating three concepts:
Vulnerable dependency
≠
Reachable vulnerability
≠
Confirmed exploitable asset
This distinction prevents both vulnerability fatigue and dangerous false confidence.
Spring4Shell Hardening Checklist
Security teams reviewing Spring applications should confirm that applications no longer rely on historical vulnerable Spring Framework versions, that standalone Servlet-container deployments have been updated, and that externally exposed request models use narrowly scoped properties.
Teams should also verify the Java runtime, identify whether applications are packaged as executable JARs or WARs, inventory spring-webmvc y spring-webflux, review controller parameters that use implicit or explicit model binding, monitor web directories for unexpected executable files, correlate Java processes spawning shells, and investigate unusual outbound network activity from application servers.
For development teams, the deeper corrective action is to stop exposing broad internal domain models to arbitrary HTTP binding when a dedicated request DTO can enforce the intended boundary much more clearly. Spring’s own post-incident guidance strongly recommends this design. (Inicio)
Frequently Asked Questions About CVE-2022-22965 Spring4Shell
Is CVE-2022-22965 remotely exploitable?
Yes. CVE-2022-22965 is classified as a remote code execution vulnerability. NVD assigns it a 9.8 CVSS v3.1 score with network attack vector, no required privileges and no user interaction. Actual exploitability nevertheless depends on application and deployment conditions. (National Vulnerability Database)
Does Spring4Shell affect every Spring Boot application?
No. Spring explicitly states that the originally reported exploit does not affect the default Spring Boot executable-JAR deployment. The classic attack required a traditional WAR deployment on a suitable Servlet container. (Inicio)
Does Spring4Shell require JDK 9 or higher?
The original reported exploit does. Spring lists JDK 9+ as one of the prerequisites for that scenario. (Inicio)
Does Spring4Shell require Tomcat?
The famous original exploitation technique used Tomcat, and the current Spring CVE advisory lists Tomcat as a prerequisite for the specific exploit. Spring’s more detailed disclosure later noted that Payara and GlassFish were also known to expose relevant attack vectors, emphasizing that the underlying flaw was not intrinsically limited to Tomcat. (Inicio)
What versions fix CVE-2022-22965?
The original fixed Spring Framework releases were 5.3.18 y 5.2.20. Organizations today should migrate to an appropriate currently supported Spring release rather than treating those historical releases as a modern target state. (Inicio)
Is upgrading Tomcat enough?
Tomcat 10.0.20, 9.0.62 and 8.5.78 hardened the class loader against the original attack path, but Spring explicitly described this as a tactical alternative. Upgrading Spring Framework is preferred because it addresses the root vulnerability. (Inicio)
Is CVE-2022-22965 still exploited?
CVE-2022-22965 remains in CISA’s Known Exploited Vulnerabilities catalog. NVD’s current CISA SSVC information marks exploitation as active. (National Vulnerability Database)
Reflexiones finales
CVE-2022-22965 Spring4Shell remains one of the clearest examples of why vulnerability severity cannot be understood from a dependency version alone. The underlying bug was critical, remotely exploitable and exploited in real environments, but the best-known RCE chain depended on a specific combination of Spring data binding, JDK 9+, application behavior and Servlet-container deployment. (spring.io)
The correct defensive response is therefore neither “every Spring server is compromised” nor “our proof of concept did not work, so we are safe.” Organizations should identify vulnerable Spring versions, determine the running Java and deployment model, inspect externally reachable data-binding surfaces, upgrade the framework, modernize old Servlet containers and hunt for evidence of previous exploitation.
Most importantly, Spring4Shell exposed a broader application-security principle that remains relevant well beyond this CVE: automatic data binding turns an object model into an externally reachable security boundary. The safest design is not an ever-growing list of forbidden property names, but a deliberately small request model containing only the fields an untrusted client should be able to modify. That is also the direction Spring itself recommended after its investigation into CVE-2022-22965 and the related data-binding weakness CVE-2022-22968. (Inicio)
Spanish 
English 
German 
French 
Portuguese 
Japanese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew