In this advisory, we will address the core facts regarding the recently disclosed security vulnerability in the Spring Framework, which has been informally nicknamed by some as “Spring4Shell”, why it’s important to address quickly, how to address it, and how to better prepare for future vulnerabilities.
The Spring Team has announced a critical vulnerability in the Spring Framework, a ubiquitous framework found in many Java applications.
The vulnerability has been informally nicknamed “Spring4Shell” by some observers (invoking the recent high-profile vulnerability that was dubbed Log4Shell), and has been logged in the National Vulnerability Database (NVD) as CVE-2022-22965.
From the Spring Framework early announcement blog post:
"The vulnerability impacts 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."
Many organizations using third-party software or developing custom applications with the Java programming language are potentially impacted.
Spring is one of the most ubiquitous application development frameworks in modern applications, appearing in a vast number of packaged and custom applications.
According to data tracked by Tidelift, impacted package spring-webmvc has over 2,200 dependent packages in the Java language ecosystem and over 111,000 dependent software repositories on public code collaboration platforms.
What makes this particular issue even more pernicious is, not only is Spring widely used, but this vulnerability is a Remote Code Execution (RCE) exploit. That means it’s possible to use this vulnerability to trigger arbitrary code execution on impacted systems, over a network.
Users of affected Spring Framework versions should apply the following mitigation: 5.3.x users should upgrade to 5.3.18+, 5.2.x users should upgrade to 5.2.20+.
There are other mitigation steps for applications that cannot immediately upgrade to the above versions, described in the Spring Framework RCE early announcement blog post.
Organizations should immediately upgrade applications to incorporate a version of the Spring library that resolves the issue, and redeploy all production workloads, especially those that are public network-facing.
Organizations should be sure to comprehensively audit all of their software applications (both internally developed and vendor-provided).
This vulnerability is an important reminder that organizations need to have an accurate and up to date software bill of materials (SBOM) to help identify and track exactly which open source components are in use across the organization so that they can rapidly respond when serious issues arise.
In the case of this vulnerability, centrally managing a catalog of approved open source components using the Tidelift Subscription makes it easy for an organization to quickly identify if the affected component is in use and where, so remediation can be handled in a timely and comprehensive manner.
Tidelift customers were made aware of this vulnerability via the Tidelift Subscription service. We recorded a vulnerability with guidance on the upgrade path and mitigation procedures that showed up as a Tidelift catalog task for customers to address.
To better prepare to react quickly to vulnerabilities like this in the future, Tidelift recommends organizations implement a comprehensive and unified approach to managing the health and security of the open source software supply chain.
If you’d like to learn more about the Tidelift approach to managing open source: