Spring4Shell vulnerability: Should you patch?

The remote code execution (RCE) vulnerability in Spring Core, known as Spring4Shell, is not an “everything’s on fire kind of issue,” according to Dallas Kaman, one of the security engineers who first posted confirmation of the vulnerability after it leaked this week. But patching will still be the wisest course of action for many organizations, said Kaman, principal security engineer at Praetorian — given that much remains unknown about the potential risks of the open source vulnerability.

In particular, there’s a possibility that attackers will find new ways to exploit the vulnerability, says Praetorian CTO Richard Ford. This suggests that anyone who uses Spring, a popular framework in the development of Java applications, should consider deploying the patch — not just those who know they’re vulnerable, according to Ford.

Free Wortley, founder and CEO of LunaSec, which has also published an analysis on Spring4Shell, echoed that this issue is a primary concern with the vulnerability.

“I’ve had several companies reach out asking if their specific configuration is vulnerable, and my advice is to still patch,” Wortley said in an email to VentureBeat. “[It’s] not at the same priority as Log4Shell — but they still need to patch because attackers will be finding new ways to trigger this. Spring is simply too ubiquitous for them to ignore.”

Many security experts have pointed to the differences between Spring4Shell and Log4Shell — a far-more-critical but similarly named RCE flaw — indicating that this new RCE vulnerability is not the “next Log4Shell” as some had initially feared.

At the same time, Spring4Shell is, in fact, being actively targeted in attacks, according to reports from Kasada, GreyNoise Intelligence and Bad Packets. And researchers suspect that real-world applications are likely to be vulnerable (even though reports still have yet to emerge confirming this).

Other exploits possible

On Thursday, Spring published a blog post with details about patches, exploit requirements and suggested workarounds for Spring4Shell (CVE-2022-22965). The RCE vulnerability affects JDK 9 or higher and currently is known to have several additional requirements for it to be exploited, the Spring blog post says.

The initial exploit requires the application to run on Apache Tomcat as a WAR deployment, which is not the default way of deploying applications — limiting the scope of the vulnerability’s impact somewhat. The default, on the other hand, is not vulnerable to the initial exploit of Spring4Shell.

However, “the nature of the vulnerability is more general, and there may be other ways to exploit it,” Spring said in its blog post.

On Friday, new versions of Apache Tomcat were released that address the attack vector involved with the vulnerability.

At this early stage, plenty remains unknown about the potential exploitability of Spring4Shell. For example, there are other servlet containers, besides Tomcat, that development teams use with Spring Core — such as Jetty.

And while Tomcat offers certain features that are utilized as part of exploiting the vulnerability, and is the most widely used Java servlet container, alternatives to Tomcat could potentially offer features for this, the Praetorian researchers said.

“I would imagine that in the coming weeks, people are going to start taking a look at the other servlet containers to see if there are components available that allow for this type of thing as well,” Kaman said.

In laymen’s terms, to take advantage of the vulnerability in Spring Core, “you need a hammer, a nail and 2×4. Tomcat’s providing the hammer, nail and 2×4,” Ford said. “For other systems [besides Tomcat], people are going to say, ‘Well maybe I don’t need a hammer — can I get away with a screwdriver?’ It’s essentially using those gadgets that are present in the environment to get your job done.”

The bottom line being: Because Spring4Shell is a “more general vulnerability” — as Spring notes in its blog — the best advice is that “you should patch,” Ford said. “Because there may be more general exploits available.”

Who should patch?

That advice extends to anyone that uses vulnerable versions of Spring, he said — not just those using the configuration that is currently known to be vulnerable.

“If you’re using Tomcat and a vulnerable version of Spring, you pretty much have a problem, and should be patching now,” Ford said. “But the underlying vulnerability is in Spring Core, whether Tomcat is there or not. And so, the recommendation is that if you’re using Spring Core, you should be looking at patching to the latest version.”

LunaSec recommends the same approach to organizations because the reality is that when it comes to Spring4Shell, “this is still very new,” according to Wortley.

“We haven’t had time to analyze the variety of ways that this could be triggered and turned into an RCE exploit,” Wortley said.

However, from past lessons with other Java vulnerabilities — such as Log4Shell, which affected the Apache Log4j logging software — the security community knows that “demonstrating a single bypass usually means that there are more,” he said.

“There are a lot of very smart, very motivated attackers out there trying to find other ways to trigger this exploit right now,” Wortley said. “The ways that this exploit can be leveraged are very broad and not something that can be fully understood within a short time period.”

Additionally, code and infrastructure are not static, he noted — meaning that just because an organization doesn’t believe itself to be vulnerable today, doesn’t mean that will continue to be the case.

Thus, if an organization is assessing its risk from Spring4Shell and concludes that “‘we don’t use X so we’re good'” — that “can be a dangerous way of thinking,” Wortley said.

Patch now or wait?

If you aren’t using a vulnerable configuration and need to wait a few weeks to patch, that’s probably fine, he noted.

“But the longer you wait, the more likely you are to forget about this — and for either an attacker to figure out a new bypass, or for one of the pieces of your infrastructure to change and now you’re vulnerable,” Wortley said.

Ultimately, attackers are preying on the fact that many companies are unable to move quickly to patch, and will therefore be vulnerable for some time, he said.

The Apache Struts RCE (CVE-2017-5638) that led to the Equifax breach in 2017 was a result of the credit reporting firm waiting to patch, Wortley said. In that case, it took about two months before the exploit was weaponized and used on them, he said.

That example is a reminder of “how important it is to patch juicy vulnerabilities like Spring4Shell more quickly than other, smaller vulnerabilities,” Wortley said.

Regardless of what happens with future exploits of Spring4Shell, however, researchers do not see a potential for the vulnerability to turn into a repeat of Log4Shell.

Even with the worst-case scenario for Spring4Shell, it is “very unlikely we will end up in a similar situation” as Log4Shell, Ford said. But at the same time, “for impacted customers, it is a big deal,” he said.

Note: This article was edited after initial publishing to read that there is a “possibility” (rather than a “likelihood”) “that attackers will find new ways to exploit the vulnerability.”