Spring confirms ‘Spring4Shell’ zero-day, releases patched update

Earlier this week, experts released details on a remote code execution (RCE) vulnerability affecting the Spring Framework.

Digital Shadows co-founder James Chappell told The Record that the Spring Framework provides tools and utilities for Java-based enterprise applications, effectively serving as important “plumbing” used in Java web applications to help reduce the amount of effort required to produce a working application.  

The kind of applications created using Spring include popular web servers and more, according to Chappell.

In a blog post published Thursday, Spring’s Rossen Stoyanchev confirmed that the zero-day vulnerability (tagged as CVE-2022-22965) in the popular Spring Framework was leaked ahead of CVE publication. 

Stoyanchev said the issue was first reported to VMware late on Tuesday evening and the team spent most of Wednesday investigating the issue, analyzing the vulnerability, identifying a fix and testing it. They aimed for the emergency releases to come out on Thursday but on Wednesday, details were leaked in full detail online.

A Java Springcore RCE 0day exploit has been leaked. It was leaked by a Chinese security researcher who, since sharing and/or leaking it, has deleted their Twitter account.

We have not verified the exploit.

tl;dr big if true

Download the 0day POC here: https://t.co/SgPCdI00TS

— vx-underground (@vxunderground) March 30, 2022

Stoyanchev explained that several parameters need to be in place for a deployment to be vulnerable, including the use of Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older. 

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

VMware echoed that assessment, adding that if the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. But they too said the nature of the vulnerability is more general and that other exploits may emerge in the coming days. 

On Thursday afternoon, Spring released Spring Framework 5.3.18 and 5.2.20, which contain the fixes for the issue. Spring Boot 2.6.6 and 2.5.12 that depend on Spring Framework 5.3.18 have also been released, with 6 bug fixes, documentation improvements, and dependency upgrades.

Stoyanchev also shared potential workarounds from Spring in the blog. 

Multiple cybersecurity firms told The Record that an exploit for the remote code execution vulnerability was leaked online and was making the rounds among cybersecurity experts in China. 

An expert from cybersecurity firm Praetorian said exploitation requires an endpoint with DataBinder and noted that they have sent their exploit to the Spring security team. 

In certain configurations, exploitation of the issue is straightforward, however, exploitation of different configurations will require the attacker to do additional research to find payloads that will be effective, they noted. 

Chappell and others said CERT teams such as SingCERT have issued useful advice on how to configure Spring Core to avoid this weakness and suggested web application firewall rules that can filter attempts to exploit.

Spring4Shell vs. Log4j

Chappell noted that while many are drawing similarities between the Spring issues and the ubiquitous Log4j, an attacker has to conduct additional effort to research specific instances and the weakness is dependent on the specific configuration of the Java application, requiring significantly more effort for the attacker to exploit.

“In Log4j – it was the ubiquity of the logging library that resulted in security teams having to scramble to defend vulnerable systems and services before the weakness was widely exploited,” he added. 

“Enough web servers and hosts would need to have the specific set of configurations that would make them widely exploitable. At present it seems that this is not as broadly available as Log4j which was almost universally exploitable on all systems. That said, the Spring Core library is often used in commonly found web servers so there is still potential for this to have a significant impact, albeit not on quite the same scale as Log4j.”

While many initially downplayed the issue and questioned its significance, others have already compared it to the widespread Log4Shell vulnerability that caused global concern in December and January, dubbing the latest issue “Spring4Shell” or “SpringShell.”

Cybersecurity researchers Chris Partridge and Yuesong Wang said on a GitHub page explaining the issue that there are cases in the wild where this vulnerability is working, most notably in the "Handling Form Submission" tutorial from Spring.

I was able to confirm that the #Spring4Shell exploit works against the "Handling Form Submission" tutorial from here: https://t.co/HCHBFy6JC0

Methodology followed (thanks esell & @BobTShoplifter)https://t.co/MXNzEiH2JF pic.twitter.com/cHisyIerGi

— Colin (@th3_protoCOL) March 31, 2022

“In my opinion, any news article going out of its way to say ‘could this be the next log4shell?!?’ is willfully overblowing this – this is a severe vulnerability, sure, but it only impacts nondefault usage of SpringCore with no proven widespread viability,” the two said. 

“It's categorically not log4shell-like. While this currently does not seem like it's going to be a cataclysmic event, given this is RCE it it at least worth the research to figure out how much risk exposure your organization could have.”

Cybersecurity firm Rapid7 echoed that the vulnerability and proof of concept isn’t exploitable with out-of-the-box installations of Spring Framework.

David Lindner, CISO at Contrast Security, said his team has confirmed the Spring4Shell zero-day. He added that the Spring-core artifact is used widely in 74% of Java applications.

“The Contrast Labs team has proven the exploit due to how a Spring application handles binding, and we believe it could have a larger impact than Log4j. Our team is continuing to explore this vulnerability,” Lindner said.  

“We recommend Java developers to specifically set the allowed fields property or properly set the disallowed fields for the known malicious attack patterns within the DataBinder class.”

Additionally, Lindner said his team has seen a 20x increase in attacks targeting the Java ClassLoader — a critical link in the public exploit for the Spring4Shell vulnerability — since Wednesday. "This is an indicator that hackers are attempting to exploit this vulnerability in the wild and we recommend that organizations not only take this vulnerability seriously but also put mitigation in place as soon as possible," he said.

Lindner added that concerns need to be raised considering data shows that over 40% of Log4j downloads are still of vulnerable versions more than four months post-discovery. 

The famous Equifax hack resulted from a remote code execution vulnerability, Lindner noted, adding that the results of Spring4Shell “could be devastating.”

Netenrich’s John Bambenek, said that what made Log4j such a problem is that it is often installed on appliances and other ‘headless’ devices that are not maintained by the end customer. 

“It is unclear how true this will be for Spring, but any RCE issue should go straight to the top of the pile for security teams to address,” he explained.

Correction: An earlier version of this story incorrectly stated that CVE-2022-22965 was given a critical CVSS score of 9.8. That score was assigned to a different Spring-based vulnerability (CVE-2022-22963), and CVE-2022-22965 has not been given a CVSS score yet.