The Spring zero-day vulnerability named Spring4Shell (SpringShell) has been patched, just as several cybersecurity firms have confirmed seeing exploitation attempts.
The disclosure of several Spring vulnerabilities this week — including a critical flaw that was likely inadvertently disclosed — has led to confusion and concerns that organizations may be dealing with another Log4Shell.
The developers of Spring, which is owned by VMware and said to be the world’s most popular Java application development framework, announced patches for one medium-severity DoS vulnerability on March 28 (CVE-2022-22950), and another flaw affecting Spring Cloud Function (CVE-2022-22963) on March 29.
The advisory for CVE-2022-22963 initially said it was a medium-severity bug that could allow access to local resources, but its severity was later changed to “critical” after it came to light that it could also be exploited for remote code execution.
Spring4Shell, which on Thursday was assigned the CVE identifier CVE-2022-22965, was initially conflated with CVE-2022-22963 by many in the cybersecurity community, which led to a lot of confusion.
Spring4Shell is a remote code execution vulnerability in Spring Framework that can be exploited for remote code execution without authentication.
Spring developers on Thursday published a blog post announcing the availability of patches and to clarify that the vulnerabilities are unrelated.
Proof-of-concept (PoC) exploits are available for both Spring4Shell and CVE-2022-22963, and Akamai has reported seeing exploitation attempts targeting both vulnerabilities. According to the company, CVE-2022-22963 has been targeted since March 27, and attacks targeting Spring4Shell were first observed on March 30.
While some of the exploitation attempts appear to come from organizations checking to see if they are vulnerable to attacks, some attacks were conducted by malicious actors attempting to deploy a webshell that could be used to execute commands on the compromised systems, deliver other malware, or for lateral movement.
Palo Alto Networks has also reported seeing attempts to deliver webshells through the exploitation of CVE-2022-22965, in most cases using the publicly available PoC code.
Honeypots run by the SANS Institute have also picked up similar exploitation attempts.
Spring developers noted that they became aware of the Spring4Shell vulnerability on the evening of Tuesday, March 29, after being informed by researchers working at an affiliate of Chinese e-commerce giant Alibaba. The developers started working on a fix the next day and were planning on releasing an emergency patch on Thursday.
However, a researcher leaked information about the zero-day before they could release the patch — possibly by accident because the information was later removed.
“The vulnerability impacts Spring MVC and Spring WebFlux applications running on JDK 9+,” Spring developers explained in their blog post. “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.”
Patches for the vulnerability are included in Spring Framework versions 5.3.18+ and 5.2.20+, and some mitigations are available as well.
While the full extent of the impact of Spring4Shell on real-world applications is still being investigated, there is a consensus that the vulnerability is likely not as bad as Log4Shell. Based on what is known to date, there are certain conditions that need to be met for exploitation to be successful, and it appears that the exploit may need to be adapted for each targeted application.