Spring4Shell: Zero-Day Vulnerability in Spring Framework

Image of Claus Nielsen
Claus Nielsen

April 1, 2022

Holm Security is sharing the following vulnerability update in relation to Spring4Shell. The vulnerability affects SpringMVC and Spring WebFlux applications running on JDK 9+. CVE-2022-22965 was initially published on March 31, 2022. Our team will be updating this blog continually so please return regularly for additional information.

General information 

Two RCEs exist and three vectors are being discussed online (one of which is not known to be remotely exploitable):

  • Confirmed: CVE-2022-22965 "Spring4Shell" in Spring Core has been confirmed by several sources that leverage class injection (very severe).
  • Confirmed: CVE-2022-22963 in Spring Cloud Function (less severe).
  • Unconfirmed: A third weakness that was initially discussed as allowing RCE via Deserialization, but isn't exploitable (not severe currently). 

Spring4Shell is a bypass of an old code injection vulnerability in the Spring Core Framework. (CVE-2010-1622).

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. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.

Exploit scenario, patch, & mitigation status 

These are the requirements for the exploit:

  • JDK 9 or higher.
  • Apache Tomcat as the Servlet container.
  • Packaged as a traditional WAR (in contrast to a Spring Boot executable jar).
  • spring-webmvc or spring-webflux dependency.
  • Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions.

However, the nature of the vulnerability is more general, and there may be other ways to exploit it that have not been reported yet.

Resolution status

  • Spring Framework 5.3.18 and 5.2.20, which contain the fixes, have been released.
  • Spring Boot 2.6.6 and 2.5.12 depend on Spring Framework 5.3.18 have been released.

Level of severity

Given the broad use of Apache Tomcat by developers, this remote code execution vulnerability has a huge potential impact.

In certain configurations, exploitation of this issue is straightforward, as it only requires an attacker to send a crafted HTTP request to a vulnerable system. However, exploitation of different configurations will require the attacker to do additional research to find payloads that will be effective,” the Praetorian researchers noted.”

“Exploitation requires an endpoint with DataBinder enabled (e.g. a POST request that decodes data from the request body automatically) and depends heavily on the servlet container for the application. For example, when Spring is deployed to Apache Tomcat, the WebAppClassLoader is accessible, which allows an attacker to call getters and setters to ultimately write a malicious JSP file to disk. However, if Spring is deployed using the Embedded Tomcat Servlet Container the classloader is a LaunchedURLClassLoader which has limited access.

Is Spring4Shell vulnerability the new Log4Shell?

The vulnerability, dubbed SpringShell or Spring4Shell by cyber security analysts, has drawn inevitable comparisons with Log4Shell, a zero-day vulnerability in the popular Log4J java tool which caused widespread problems when it was discovered in December. Experts however do say that Spring4Shell is more difficult to exploit, but still has the potential to cause widespread damage.

Software developers online have started to call the vulnerability Spring4Shell, after Log4Shell. This is because of the popularity of the Spring Core Framework. However, there are some differences as Log4J is bundled up and included as a part of an application whereas the Spring Framework is a commercial product.

Holm Security’s Vulnerability Management Platform - status of detection

We have already released the detection script for identifying the Spring framework installed on Linux machines, keep in mind that authenticated scan is required for it.

In addition, we're are currently working on the vulnerability test which is currently on schedule to be released today. You can therefore expect that within the next 24Hrs all our scanner appliances and external scanning nodes will be updated to support this.

At the same time, we have already prepared a lab with the vulnerable Spring4Shell application running and are currently researching exploitation methods that will be able to be used for active vulnerability tests.

We will keep you updated as additional information becomes available.

Update 2022-04-01 16:46 Detection script and Vulnerability tests for Spring4Shell have been pushed out and will be available for scans tomorrow (2nd of April).

Detection scripts for Spring Framework (SSH and HTTP based) and a vulnerability test covering CVE-2022-22965.

HID-2-1-347323 VMware Spring Framework Detection (HTTP)
HID-2-1-347321 VMware Spring Framework (Core) Detection (Linux/Unix SSH Login)
HID-2-1-347320 VMware Spring Framework (Core) Detection Consolidation
HID-2-1-347322 VMware Spring Framework (Core) RCE Vulnerability (Spring4Shell, SpringShell) - Version Check