By now you have probably heard about another raft of high-severity vulnerabilities in the open-source Java application framework, Spring. The Spring Framework is a collection of programming libraries which allow developers to easily integrate features into their apps such as authentication, data access, testing, and even the creation of web applications on top of Java Enterprise Edition.

Of the three new vulnerabilities, one of them sounds worryingly similar to the recent high-severity exploit, Log4Shell. While the vulnerabilities discovered in the Spring framework do have some things in common with Log4Shell, there are also some significant differences that impact how we should respond. The purpose of this article, therefore, is to explore these weaknesses, how they are exploited, and some general steps to mitigate your risk.

Of the three Spring vulnerabilities, two are critical and allow for remote code execution (RCE), and the third is a denial-of-service vulnerability. We will explore each in turn below.

CVE-2022-22963

This is a vulnerability in the Spring Cloud Function software, versions 3.1.6 and 3.2.2 as well as in older, unsupported versions. A user can provide a specially crafted routing expression in the Spring Expression Language (SpEL) to gain access to local resources and possibly achieve remote code execution.

It was originally given a Medium CVSS severity score but has since been reclassified as Critical. A fix is available by upgrading to versions 3.1.7 or 3.2.3.

It is also important to recognize that, despite some early confusion, this is not the same vulnerability as “Spring4Shell”, which has been assigned CVE-2022-22965, which we detail below.

CVE-2022-22965

This is a vulnerability in Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, as well as older unsupported versions. The vulnerability impacts Spring MVC and Spring WebFlux applications running on Java Development Kit (JDK) 9+. The initially reported exploit requires that the affected application be running as a WAR deployment in Apache Tomcat. Applications running as JAR deployments (the default) are not vulnerable to the initially reported exploit, but the vendor acknowledges that they may be affected by other exploitation techniques.

The CVSS Severity score for this is Critical. Fixes are available in Spring Framework 5.3.18+ and 5.2.20+.

CVE-2022-22950

This is a denial-of-service vulnerability in Spring Framework versions 5.3.0-5.3.16 and older unsupported versions. A user can use a specially crafted SpEL expression that can cause a denial-of-service condition. It is unrelated to the above two vulnerabilities and was announced originally on March 28^th, 2022.

The CVSS severity score for this is Medium. There are fixes available in Spring Framework 5.3.17+.

What is SpEL and How Does It Relate?

SpEL is the “Spring Expression Language” a custom language used to write configuration information to Spring components. Understanding how it is used can help with understanding how these vulnerabilities are exploited.

In CVE-2022-22965, a crafted SpEL expression is sent to change the logging configuration of the affected component, causing a file accessible to the attacker in the application’s root directory to be used for logging output. The attacker then sends another request that will generate a logging action to write code (for example, a web shell) into the file. A third request from the attacker will execute this code. Since this also causes other logs to be written to this file, the attacker will also have access to logged data.

In CVE-2022-22963, a specially crafted SpEL expression is sent in the “spring.cloud.function.routing-expression” HTTP header. Because that header is unvalidated by Spring Cloud Function, this causes attacker supplied input to be executed as a command.

In CVE-2022-22950, a specially crafted SpEL expression is used to trigger a denial-of-service condition (i.e. crashing the application). Precise details of this have not been published, to our knowledge.

Tracking Spring4Shell Exploits In The Wild

Using data provided by the F5 Threat Campaigns service, F5 Labs detected active exploits of the vulnerabilities in the wild as early as March 30^th, as shown in Figure 1. This provides more evidence of the speed in which threat actors can weaponize newly announced vulnerabilities.