Spring – a widely-used Java framework from VMware – announced a remote code execution vulnerability that could affect users on 31 March 2021.
While VMware learned of the issue on 29 March, and released a patch by 31 March, news of the vulnerability leaked on before the patch had been released. Users quickly drew comparisons between it and Log4Shell, dubbing it Spring4Shell.
Spring4Shell is similar to Log4Shell in some ways (both affect popular Java frameworks), however, this comparison is not entirely accurate. Spring4Shell is still threatening but less so than Log4Shell. It is important to look past the hype to understand the reality of the situation and its potential impact.
Here is everything you need to know about Spring4Shell.
Spring4Shell vulnerability explained
Spring4Shell, the official identifier of which is CVE-2022-22965, bypasses the patch for a previous vulnerability, CVE-2010-1622. Since the Java Development Kit (JDK) versions 9 and onward have two sandbox restriction methods, cybercriminals could use one to bypass the previous patch and infiltrate Java systems.
Attackers can exploit this flaw by sending queries to create web shells to servers running the Spring framework. In some configurations, that’s remarkably simple, but in others, attackers will have to do more research to find a payload that works.
Notably, Spring4Shell also requires targeted apps to run on Tomcat as a web archive (WAR) deployment. Endpoints must also enable DataBinder, which automatically decodes data from requests. The vulnerability affects two Spring products – MVC and WebFlux – which help write and test apps.
Vulnerability severity
Given Spring4Shell’s relatively straightforward nature and Spring’s status as the most widely used open-source Java framework, this vulnerability is concerning. However, the scope of potentially affected apps, servers, and companies is fairly small. Spring4Shell requires a specific set of circumstances to work that most Spring users likely do not enable.
If Spring apps deploy as a Spring Boot executable jar, which is the default, the exploit won’t work. Several updates have also been released since the vulnerability became public knowledge, including two new versions of Spring Framework, two Spring Boot patches, and three patches for Tomcat’s side of the vulnerability. Users who always install the latest updates and use the default configuration have little to worry about.
Still, companies should take Spring4Shell seriously. Some companies, including Microsoft, have already noticed breaches from this vulnerability. While the circumstances that enable it are relatively narrow, they are not unheard of – and if attackers get through, they can cause substantial damage.
Even if attackers do not capitalize on this vulnerability, it can harm businesses that fail to patch it. Cisco had to pay $8.6 million in 2019 under the False Claims Act for having known but unpatched security flaws. Similar regulatory action could come to bear on organizations that have not responded to Spring4Shell.
Cyber security professionals respond
While cyber security teams ought not to panic over Spring4Shell, they should take it seriously. The Cybersecurity and Infrastructure Security Agency (CISA) urges users to install the latest updates and review VMware’s vulnerability report.
Businesses should look through the report and stay current on any updates to know which apps and processes are vulnerable. Developers should consider using non-affected apps or workflows, but even then, keep everything up to date.
VMware noted that given the general nature of this vulnerability, new exploits or attack vectors may still emerge. Security professionals should review their networks to highlight systems or devices that may be vulnerable to attacks and monitor them closely. Looking for further updates from VMware and other Java platforms will help stay on top of emerging threats.
Spring4Shell serves as a reminder
While Spring4Shell does not have the same scope and impact as Log4Shell, it could have been much worse. This time, the vulnerability might have only affected users running specific versions of specific apps, but similar zero-day exploits could emerge that are far more severe.
Cyber security teams should take this moment as a learning opportunity. Companies must always look out for new threats, install the latest patches to prevent them and avoid assuming they are safe.
