3rd Party Risk Management , Application Security , Cybercrime

SpringShell, Spring Cloud Function Bugs Need Urgent Patching

Proof-of-Concept Exploits Exist for Both Bugs; At Least 1 Being Actively Exploited
SpringShell, Spring Cloud Function Bugs Need Urgent Patching
Spring IO's logo

Two serious remote-code-execution vulnerabilities have been discovered in VMware's widely used Spring IO, which is a widely used platform for building online applications.

See Also: Splunk Named a 10-Time Leader in Gartner® Magic Quadrant™ for SIEM

Proof-of-concept exploits reportedly exist for both flaws, and at least one of the vulnerabilities is actively being exploited in the wild. VMware has released patches and is urging users to apply them as quickly as possible.

Spring Cloud Function Vulnerability

The first of the two flaws, the Spring Cloud Function vulnerability tracked as CVE-2022-22963, is remotely exploitable under the default configuration while running a Spring Boot application that depends on the Spring Cloud Function.

VMware, which owns Spring, says in a security alert that Spring Cloud Function versions 3.1.6, 3.2.2 and older unsupported versions are all affected by CVE-2022-22963. Explaining how the vulnerability is exploited, VMware says that "when using routing functionality it is possible for a user to provide a specially crafted SpEL as a routing-expression," and that this "may result in remote code execution and access to local resources."

"A Spring Boot application is vulnerable only when depending on packages like 'spring-cloud-function-web' and 'spring-cloud-starter-function-web' which enable Spring Cloud Function," JFrog, a security solutions provider, says in a tweet. "Check your 'pom[.]xml for any package that depends on 'spring-cloud-function-core.'"

VMware initially assigned the Spring Cloud Function vulnerability a CVSS score of 5.4 and a severity rating of "medium," says Will Dormann, a vulnerability analyst at the CERT/CC. But many researchers, including Dormann, considered the score and rating inaccurate, and on Thursday, VMware changed the severity rating to "critical."

VMware recommends that users of affected versions upgrade to 3.1.7 and 3.2.3 - whichever is appropriate. "No other steps are necessary," its security report says.

VMware has attributed the finding of the vulnerability to an external researcher who uses the name m09u3r.

POC Exploit Available

A proof-of-concept exploit for this vulnerability is known to be available, and cybersecurity researcher Souiane Tahiri says someone appears to have published the exploit on GitHub.

Spring Framework Vulnerability

The Spring Framework RCE flaw, which is now being called the SpringShell or Spring4Shell vulnerability, is being tracked as CVE-2022-22965.

According to a blog post published by Spring, the vulnerability affects Spring MVC and Spring WebFlux applications running on JDK 9+. "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 that have not been reported yet," the post says.

Dormann of CERT/CC says: "By providing crafted data to a Spring Java application, such as a web application, an attacker may be able to execute arbitrary code with the privileges of the affected application. Depending on the application, exploitation may be possible by a remote attacker without requiring authentication.

The RCE vulnerability in the Spring Framework was first reported to VMware late Tuesday evening by researchers from AntGroup FG, reports Rossen Stoyanchev, a Spring Framework committer. The Spring team says it investigated and analyzed the report, developed a fix and tested it Wednesday, while aiming for an emergency release Thursday.

On Wednesday, however, full details of the vulnerability were leaked online, forcing Spring to provide an update ahead of the releases and even before a CVE number could be assigned to the flaw.

Stoyanchev says that exploiting the Spring Framework or SpringShell vulnerability requires all of the following conditions to to met:

  • JDK 9 or higher;
  • Apache Tomcat as the Servlet container;
  • packaged as WAR;
  • "spring-webmvc" or "spring-webflux" dependency.

VMware says that Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older unsupported versions all have this flaw. Spring has also released patches to address the CVE-2022-22965 vulnerability, and VMware says that "5.3.x users should upgrade to 5.3.18+" and "5.2.x users should upgrade to 5.2.20+."

If patches are applied properly, no other steps are required, it says. But the company has also published workarounds if the patch cannot be applied, or applied immediately.

Proof-of-Concept Exploit Available

VMware has yet to comment on reports that at least one of the vulnerabilities are being actively exploited in the wild. Dormann, however, confirms that a working exploit for the Spring4Shell is available in the wild and works against the stock "Handling Form Submission" sample code from Spring IO.

As Big as Log4j?

Many in the information security community have compared the potential disruption from the Spring4Shell/SpringShell vulnerability with that of Log4j/Log4Shell because of its similarly wide use.

But even though some online reports have suggested strong similarities between the two groups of vulnerabilities, there are some notable differences, says Brian Fox, CTO of software firm Sonatype.

"Despite some reports online, the new critical vulnerability, dubbed 'SpringShell' by the open-source community, has not yet been proven to be quite as dangerous as the widely known Log4j vulnerability. However, the massive popularity of Spring and the low skill level needed to execute this type of attack has rightly raised alarms across the industry, which is why the comparison is being made," he tells Information Security Media Group.

On the upside, JFrog says that not all Spring apps are vulnerable, in part because JDK 8 use remains widespread; many apps have yet to be migrated to JDK 9+ version.

Staff writer Devon Warren-Kachelein contributed to this story.

About the Author

Mihir Bagwe

Mihir Bagwe

Principal Correspondent, Global News Desk, ISMG

Bagwe previously worked at CISO magazine, reporting the latest cybersecurity news and trends and interviewing cybersecurity subject matter experts.

Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing govinfosecurity.com, you agree to our use of cookies.