Spring4Shell Explained — Is Your Spring Application Still Vulnerable?

Spring4Shell, tracked as CVE-2022-22965, was disclosed in March 2022 and quickly created panic across the Java ecosystem. The timing made it even more alarming: it arrived only months after Log4Shell, another critical Java vulnerability that had already forced engineering and security teams into emergency patching mode.

The spring4shell vulnerability is a Remote Code Execution flaw in the Spring Framework’s data binding mechanism. Under specific conditions, an attacker can send crafted HTTP requests that manipulate Java class properties and potentially lead to arbitrary code execution on the server.

But there is an important nuance many early reports missed: not every Spring application was vulnerable. The original CVE-2022-22965 exploit required a specific combination of Spring Framework versions, JDK version, servlet container, deployment format, and classpath components. Most modern Spring Boot applications deployed as executable JAR files were not affected by the original exploit path.

This guide explains what Spring4Shell actually is, the exact conditions required for exploitation, how it differs from other Spring CVEs disclosed around the same time, how to check your application, and exactly what to upgrade.

What Spring4Shell Actually Is

Spring Framework is one of the most widely used Java application frameworks. It powers web applications, APIs, enterprise systems, internal tools, microservices, and backend services across thousands of organizations. Because Spring is so widely deployed, any critical vulnerability in it gets immediate attention.

CVE-2022-22965 is a Remote Code Execution vulnerability involving Spring’s data binding functionality. Data binding is a normal framework feature that maps incoming request parameters to Java objects. In typical web applications, this allows developers to receive form fields or request parameters and bind them to model objects automatically.

The problem was that under certain conditions, attackers could abuse this binding behavior to manipulate sensitive Java class properties. When combined with Apache Tomcat and WAR deployment, that manipulation could be used to write a malicious web shell or otherwise gain code execution.

This made the issue serious. Remote Code Execution means an attacker may be able to run commands or code on the affected server. In a vulnerable internet-facing application, that can lead to web shell deployment, data theft, lateral movement, service disruption, or full server compromise.

The spring4shell vulnerability was rated critical because exploitation could be performed remotely against affected applications. However, the exploitability depended heavily on deployment details, which is why accurate assessment was so important.

The Exact Conditions Required for Exploitation

The most important part of Spring4Shell is understanding who was actually affected. Early reporting caused confusion because many teams heard “Spring RCE” and assumed every Spring or Spring Boot application was vulnerable. That was not correct.

For the original CVE-2022-22965 exploit path, the application needed to meet a specific set of conditions. The official Spring guidance described the issue as affecting Spring MVC or Spring WebFlux applications running on JDK 9 or higher, with the specific exploit requiring the application to be packaged and deployed as a traditional WAR on a servlet container such as Tomcat.

In practical terms, the common affected configuration was:

• Spring Framework 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, or older unsupported versions.
• JDK 9 or higher. The attack path relied on Java 9+ behavior.
• Apache Tomcat as the servlet container.
• Traditional WAR deployment.
• spring-webmvc or spring-webflux on the classpath.

Important: Spring Boot apps deployed as executable JAR files are not affected by CVE-2022-22965’s original exploit path — despite widespread reporting suggesting otherwise.

This does not mean Spring Boot users could ignore the issue completely. Many Spring Boot projects still depended on vulnerable Spring Framework versions, and some teams deployed Spring Boot applications as WAR files to external servlet containers. The correct response was to check the exact deployment model and dependency versions, then upgrade where needed.

If your application used Spring Boot’s default executable JAR packaging with embedded Tomcat, it was not vulnerable to the original exploit described in the advisory. If your application was packaged as a WAR and deployed to external Tomcat, you needed to investigate immediately.

Spring4Shell vs Spring Cloud Function vs CVE-2022-22968 — Three Different Things

Spring4Shell was not the only Spring-related security issue discussed in 2022. Around the same time, multiple Spring CVEs appeared in advisories and news reports. This caused confusion because developers saw different CVE IDs, different products, and different exploit details all being discussed together.

The three commonly confused issues are:

CVE-2022-22965 Spring4Shell is the main Spring Framework RCE issue discussed in this article. It is not the same as CVE-2022-22963, which affected Spring Cloud Function and involved SpEL expression injection. It is also different from CVE-2022-22968, which involved data binding rules and did not represent the same original Spring4Shell RCE scenario.

During vulnerability response, mixing these CVEs can cause bad decisions. A team may patch Spring Cloud Function and think Spring Framework is fixed, or upgrade Spring Framework and assume a Spring Cloud Function issue is gone. Always check the exact CVE ID, affected component, version range, and fix version.

How to Check If Your Application Is Vulnerable

Start by identifying your Spring Framework version. In Maven projects, use mvn dependency:tree to inspect resolved dependencies. This is important because you may not declare spring-webmvc directly; it may arrive through Spring Boot starters or other dependencies.

mvn dependency:tree | grep spring

You can also search for specific Spring Framework artifacts:

mvn dependency:tree | grep spring-webmvc
mvn dependency:tree | grep spring-webflux
mvn dependency:tree | grep spring-core
mvn dependency:tree | grep spring-beans

Next, confirm your deployment model. Ask these questions:

• Are you using Spring Framework 5.3.0–5.3.17, 5.2.0–5.2.19, or older?
• Are you running on JDK 9 or higher?
• Are you deploying to Apache Tomcat?
• Is the application packaged as a WAR file?
• Do you have spring-webmvc or spring-webflux on the classpath?

If all of these are true, your application should be treated as vulnerable until patched or proven otherwise. If you use Spring Boot executable JAR packaging, the original exploit path does not apply, but upgrading is still recommended because patched Framework versions remove the underlying issue.

You should also check CI/CD build files, parent POMs, dependency management sections, Docker images, legacy WAR deployments, and application servers. Enterprise Java environments often have older applications that are still running because they are stable and hard to migrate.

The Fix — Exactly What to Upgrade To

The fix for CVE-2022-22965 is to upgrade Spring Framework to patched versions. Spring Framework 5.3.18+ and 5.2.20+ contain the fix. For Spring Boot users, Spring Boot 2.6.6+ and 2.5.12+ include the corresponding patched Spring Framework versions.

If your project manages Spring Framework directly, update the affected Spring dependencies. Example:

<properties>
  <spring-framework.version>5.3.18</spring-framework.version>
</properties>

If your project uses Spring Boot dependency management, upgrade the Spring Boot parent version:

<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>2.6.6</version>
  <relativePath/>
</parent>

For applications on the Spring Boot 2.5 line, upgrade to at least:

<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>2.5.12</version>
  <relativePath/>
</parent>

After upgrading, rebuild and verify the resolved dependency tree:

mvn clean package
mvn dependency:tree | grep spring-framework
mvn dependency:tree | grep spring-core
mvn dependency:tree | grep spring-webmvc

If you cannot upgrade immediately, review vendor mitigations and restrict exposure. However, mitigation should only be temporary. The correct long-term fix is to upgrade to a patched Spring Framework or Spring Boot version.

Is Your Application Still at Risk in 2026?

Yes, some applications can still be at risk in 2026. Many enterprise Java systems run older Spring versions because of compatibility constraints, long release cycles, legacy application servers, old WAR deployment models, or business-critical systems that are difficult to modify.

The spring4shell vulnerability is old enough that many teams assume it is already resolved. That assumption can be dangerous. If a legacy application still uses vulnerable Spring Framework versions and matches the exploit conditions, it may remain exposed. Attackers often continue scanning for old CVEs because unpatched systems remain valuable targets.

Legacy Java environments deserve special attention. Look for applications deployed as WAR files to external Tomcat, older JDK upgrades that moved systems to JDK 9+, unmanaged application servers, and custom enterprise apps outside modern CI/CD pipelines.

Use dependency scanning to verify exposure rather than relying on memory. A single organization may have dozens or hundreds of Java repositories. Some may use parent POMs, internal BOMs, shaded dependencies, or vendor packages. Manual checks are easy to miss.

How Vulert Helps Check Spring Dependencies

Vulert is a Software Composition Analysis tool that helps developers and security teams detect known vulnerabilities in open-source dependencies. For Java projects, Vulert can analyze Maven and Gradle dependency files to identify vulnerable packages, including direct and transitive dependencies.

If you want to check for the spring4shell vulnerability or other Spring Framework issues, upload your pom.xml, build.gradle, or SBOM to Vulert. Vulert checks your dependency versions against its vulnerability database and shows which packages are affected, which versions fix the issue, and what remediation steps are available.

Vulert is useful because Spring vulnerabilities may appear through dependency management rather than a direct declaration. A project may not explicitly list every Spring artifact, but those artifacts can still appear in the resolved dependency tree. Vulert helps teams identify risk across dependency files without requiring source code access.

Vulert supports multiple manifest and lock files across ecosystems, including package-lock.json, yarn.lock, pom.xml, build.gradle, requirements.txt, composer.lock, go.sum, Gemfile.lock, Cargo.lock, pubspec.lock, mix.lock, *.csproj, packages.lock.json, and SBOM formats such as SPDX and CycloneDX.

Key Takeaways

• Spring4Shell is CVE-2022-22965: It is a critical Spring Framework Remote Code Execution vulnerability involving data binding.
• Not every Spring app was vulnerable: The original exploit required specific conditions, including JDK 9+, Tomcat, WAR deployment, and Spring MVC/WebFlux.
• Spring Boot executable JARs were not affected by the original exploit path: This was one of the most misunderstood parts of the issue.
• CVE-2022-22963 is different: It affects Spring Cloud Function and should not be confused with Spring4Shell.
• The fix is clear: Upgrade to Spring Framework 5.3.18+ or 5.2.20+, or Spring Boot 2.6.6+ or 2.5.12+.
• Legacy apps may still be exposed: Older enterprise Java deployments should still be checked in 2026.

Frequently Asked Questions

1. Does Spring4Shell affect Spring Boot?

Spring Boot applications deployed as executable JAR files were not affected by the original CVE-2022-22965 exploit path. However, Spring Boot applications deployed as WAR files to external servlet containers could be affected if they met the vulnerable conditions. Upgrading Spring Boot to 2.6.6+ or 2.5.12+ is recommended.

2. What’s the difference between Log4Shell and Spring4Shell?

Log4Shell is CVE-2021-44228 in Apache Log4j. Spring4Shell is CVE-2022-22965 in Spring Framework. Both are Java ecosystem Remote Code Execution vulnerabilities, but they affect different components and require different exploitation conditions.

3. Can Vulert check my Spring dependencies?

Yes. Upload your pom.xml, build.gradle, or SBOM to Vulert to check whether your Spring dependencies or transitive dependencies are affected by known CVEs.