Skip links

Patch now: RCE Spring4shell hits Java Spring framework

Another Java Remote Code Execution vulnerability has reared its head, this time in the popular Spring Framework and, goodness, it’s a nasty one.

Dubbed “Springshell” or “Spring4Shell”, the vulnerability requires an endpoint with DataBinder enabled. “For example,” explained security shop Praetorian, “when Spring is deployed to Apache Tomcat, the WebAppClassLoader is accessible, which allows an attacker to call getters and setters to ultimately write a malicious JSP file to disk.”

This is a severe remote code execution zero day that can be accessed over HTTP or HTTPS

“Spring have acknowledged the vulnerability and released 5.3.18 and 5.2.20 to patch the issue,” said Sonatype, “We recommend an immediate upgrade for all users.”

Got weekend plans? You might want to consider cancelling and plan your patching instead.

Spring acknowledged the issue today, which was first reported to VMware on Tuesday evening. The team worked through the investigation on Wednesday and pushed out an emergency release this morning, ahead of the CVE report.

The vulnerability comes hot on the heels of another Spring whoopsie. That one, tracked as CVE-2022-22963, was a Spring Expression language (SpEL) vulnerability in Spring Cloud and unconnected to the latest nasty to crawl out of the woodwork.

Brian Fox, CTO of Sonatype, noted that the new vulnerability had a potentially greater impact than its predecessor. Fox said: “The new vulnerability does seem to allow unauthenticated RCE but at the same time, has mitigations and is not currently at the level of impact of Log4j.”

“We can appreciate the recent Log4shell memory is rightfully causing anxiety in the industry,” he added, “as Spring is one of the most popular software frameworks out there. Regardless, this should act as another reason for every organization to take stock of how they are managing their third-party components.”

Jamie Moles, senior sales engineer at ExtraHop, commented: “While Spring has moved remarkably fast on deploying a patch, this is still a customer responsibility. CISOs need to conduct regular assessment of vulnerabilities and patch them – no vendor is going to do it for them. There will also be many organizations out there who have bought applications that use the Spring framework without their knowledge. In this case, vendors will need to rapidly reach out and inform them that they need to patch.

“It’s difficult to predict the final impact, but the IT community and Spring have reacted very quickly. Ultimately, it all depends on how quickly bad actors can undertake reconnaissance for vulnerabilities and add it to their playbook for attacks. Java is in 3 billion devices worldwide, so this has every possibility of becoming a silent but deadly tactic that hackers leverage.”

Jeff Costlow, CISO of the org, warned: “This remote code execution vulnerability has huge potential impact.”

“We have reports of scanning already for this vulnerability so it is only a matter of time before a fully weaponized POC is leveraged,” he said. “This is a severe remote code execution zero day that can be accessed over HTTP or HTTPS.”

Spring Core on JDK9+ is where the vulnerability lies and a mitigation has been published by the Praetorian team in the event that it is not possible to apply the fix released by Spring. The Spring team also noted that the vulnerability was not related to the deprecation of SerializationUtils.

Spring is a popular framework, and the vulnerability is a reminder of the importance of knowing what your apps depend on, and how those dependencies are used.

Costlow added: “While open source code is truly the building block of our internet and software universe, this vulnerability yet again shines a light on the issue of such an ubiquitous framework in the context of cybersecurity.”

Quite. ®