News

VMware Confirms Zero-Day Vulnerability in Spring Framework Dubbed 'Spring4Shell'

• By Kurt Mackie
• 03/31/2022

The Spring Framework can be subject to newly a disclosed "zero-day" vulnerability (CVE-2022-22965) that's deemed "Critical," according to a Thursday announcement by Spring developer VMware.

The vulnerability could enable remote code execution (RCE) attacks, but it appears to be largely at the proof-of-concept stage right now for specific Spring Framework implementations. VMware is advising upgrades to Spring Framework 5.3.18 and 5.2.20, which contain fixes for the vulnerability.

Vulnerable Implementations
The CVE-2022-22965 vulnerability only affects specific Spring Framework implementations, which may not be standard ones. Here's VMware's list of the conditions that render organizations vulnerable:

• 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

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

Spring4Shell Hype
Some security researchers have described this vulnerability (CVE-2022-22965) as "Spring4Shell." It's a label that recalls the infamous and ubiquitous "Log4Shell" vulnerability, a RCE flaw found late last year in the widely used Log4J Java logging framework.

However, the easy exploit circumstances of Log4Shell are getting downplayed in comments about "Spring4Shell" by security researchers. For instance, the use of Web Application Archive (WAR) packaging instead of Java Archive (JAR), as required for a successful Spring4Shell attack, is deemed to be nonstandard and not commonly used.

Security solutions firm Rapid7 posted its analysis of CVE-2022-22965, indicating that it's a real vulnerability at the proof-of -concept stage, "but it's currently unclear which real-world applications use the vulnerable functionality." The post included a "Known Risk" section that outlines the very specific conditions that need to be in place for such an exploit to work.

Confusion with Spring Cloud Function CVE
Moreover, CVE-2022-22965 was earlier this week confused with a separate and different RCE vulnerability in Spring Cloud Function versions 3.1.6, 3.2.2 and older, which is labeled as "CVE-2022-22963."

Will Dormann, a vulnerability analyst with U.S. CERT/CC, early on described the confusion between CVE-2022-22965 and CVE-2022-2963 in this Twitter thread. However, he ultimately did confirm that what's being called Spring4Shell (CVE-2022-22965) is Critical, with a Common Vulnerability Scoring System ranking of 9.8 (out of 10).

Other Opinion
Open source security tools maker LunaSec, in an evolving blog post on the Spring4Shell vulnerability opined that CVE-2022-22965 is not as bad as Log4Shell, due to its complexity and the level of Java understanding needed.

What is important to remember is that this vulnerability is NOT as bad a Log4Shell. All attack scenario[s] are more complex and have more mitigating factors than Log4Shell did because of the nature of how Class Loader Manipulation attacks work in Java.

Security expert Kevin Beaumont, formerly of Microsoft, chronicled his understanding of Spring4Shell in this Twitter thread, saying that "I haven't been able to find a single off the shelf application so far that is this exploitable to RCE (other than deliberately vulnerable PoC code)." He also suggested that the proof-of-concept attack "relies on essentially introducing a vulnerability" and it was "without a real world risk."

Beaumont referred IT pros to this "tweedge" GitHub post as a good summary about Spring4Shell. Other security researchers are adding to the conversation. The CVE-2022-22965 zero-day vulnerability was confirmed in this Contrast Security post, for instance.

VMware indicated that the CVE-2022-22965 vulnerability disclosure was leaked ahead of its CVE publication. It was first reported to VMware late on Tuesday by researchers at AntGroup FG.