Patching without tears – fixing the Spring4Shell vulnerability

Introducing Spring4Shell

On March 29, 2022, information regarding a remote code execution vulnerability began to circulate. It started with a set of Tweets and a proof-of-concept committed to GitHub that exploited a zero-day vulnerability in the Spring framework. The vulnerability was very soon verified by several independent analysts. 

On March 31, Spring confirmed it and provided continuous updates about the vulnerability. Recalling Log4Shell a few months ago, a zero-day RCE vulnerability in a popular open-source Java library, this new vulnerability quickly received much attention in the community. Was history repeating itself?

Looking at the details, it seems clear that it can not really match Log4Shell’s severity. Though details are still being worked out, using the Spring Framework together with Apache Tomcat seems to be at the highest risk of exploitation. It also requires that JDK 9 or higher has been used. Still, it should be noted that the CVSS score assumes vulnerable configurations (if they are reasonable), so the severity will still be regarded as critical. Since information about the vulnerability is still evolving, the best approach is to update the library to a secure version as soon as possible.

Identifier and vulnerable versions

The vulnerability was quickly referred to as Spring4Shell, hinting at the similarities to the Log4Shell vulnerability. The versions of the Spring Framework that are vulnerable are 5.3.0 to 5.3.17 and 5.2.0 to 5.2.19. On March 31, two new versions were released that fixed the vulnerability, namely 5.3.18 and 5.2.20. The same day, the vulnerability received an identifier, CVE-2022-22965.

Some confusion

The fact that Spring4Shell did not have a CVE identifier from the start created some confusion. The reason was that there was another vulnerability in Spring published the day before, on March 29. That vulnerability was identified as CVE-2022-22963. It should be noted that the two vulnerabilities are not in any way related. The latter is not a vulnerability in the Spring Framework but in Spring Cloud Function. 

Remediating Spring4Shell

Debricked allows you to scan your applications to find out if you are using an insecure version of Spring Framework. With just a few clicks, you can get an account, connect it to your GitHub repositories and scan for vulnerabilities. We also allow integrations with several different CI/CD systems. In the case of Spring4Shell (CVE-2022-22965), we can find out if you are using a vulnerable version before it is listed on NVD. The same goes for the previous CVE-2022-22963.

What you can expect from Debricked

Debricked is powered by state-of-the-art machine learning, allowing us to have new vulnerabilities in our database within minutes from the time that they’re published. However, in some cases, information about vulnerabilities pop up on blogs, Twitter, or on online forums before they are listed by NVD and similar. 

Debricked’s SCA tool is constantly monitoring new vulnerabilities, not only on the well-known databases but also by analyzing the ecosystem buzz. When new vulnerabilities are discovered and discussed, we make sure to enter the information into our database as soon as possible. In that way, our customers can find them in their scans even before they are available on other common sources. 

Wanna know if you’re affected by Spring4Shell? Create a free Debricked account today to find out! 

No Debricked services or products are affected by Spring4Shell. Communication has been sent out to our customers.