Spring4Shell: What we know about the Java RCE vulnerability

Already know about Spring4Shell? Jump straight to the Spring4Shell remediation section of this blog or read our Spring4Shell deep-dive to find out how the zero-day remote code execution (RCE) works.

Very early in the morning on March 30th (for me), my colleague DeveloperSteve posted a “Hey, have you seen this?” message in our slack channel. It was an “advance warning” of a “probable” remote code execution (RCE) in the massively popular Java Spring framework. I would come to find out that even earlier than that, the Snyk Security team started investigation a potential RCE in Spring after seeing a tweet that has since been deleted.

Details seemed sketchy at first. There was a tweet with screenshots that had been deleted. There were references to a pull request (PR) that, as it turns out, was first put up on February 18th, but only merged on March 29th.

Various parties were trying to make the nickname “Spring4Shell” stick (or, sometimes just SpringShell), while Spring Core maintainers were adding comments to the PR saying there was no known RCE.

So, just what the heck was going on and what is going on now?

So, what is Spring4Shell?

If you’ve used the @Autowired annotation or utilized the magic of constructor injection, you’ve encountered dependency injection in the Spring ecosystem.

In affected versions, an RCE is achievable by manipulating the ClassLoader via a carefully composed HTTP POST request.

At this time, the exploit is only known to be possible with a Java Runtime Environment (JRE) version 9 or greater AND Tomcat version 9 or greater.

Out of an abundance of caution and not wanting to act on incomplete information, security researchers at Snyk spent time reviewing the situation over the course of the day on March 30th.

At this time, our conclusion is that there’s a credible RCE threat in the Spring Core spring-beans package. For better or worse, Spring4Shell is the official name. It makes sense as there’s already a legitimate Spring Shell project in the Spring ecosystem.

We’ll continue to provide updates through our vulnerability database as the situation evolves.

Spring4Shell remediation

New versions of the Spring Framework have been released that the current exploit does not work on. They are versions 5.2.20and 5.3.18. And, if you work with Spring Boot, just today versions 2.5.12 and 2.6.6 were released which integrate the changes to the Spring framework and spring-beans.

Here’s a list of remediation steps you can take in order of preference:

• If you use Spring Framework directly, upgrade to version 5.2.20 or 5.3.18

• If you use Spring Boot, use version 2.15.12 or 2.6.6

• If you can’t upgrade your version of Spring at this time, use a version 8 JRE and/or Tomcat container to mitigate the issue

It’s worth noting that there will likely be additional updates to Spring as more (and potentially different) vulnerabilities are discovered. This is often the trajectory when a high degree of focus is put on a high severity issue like this (Log4Shell, anyone?).

Snyk’s tools have already been updated to notify you if your project is vulnerable!

Head on over to Snyk to sign up for a free account. From there (or on the command line) you can test your project to see if it’s vulnerable to Spring4Shell.

We expect to update this post and to produce a PoC code repository to demonstrate the RCE in version 9 and greater of the JRE and Tomcat. Tune in here for updates.

Exploring initial confusion around Spring4Shell

One of the first blog posts our team was alerted to in the wee hours of March 30th has since been deleted. This post referenced a tweet that was also deleted. Despite the double-delete, there was a verifiable reference to a commit to Spring Core related that is related to deserialization (a Java feature that has led to RCEs before - Log4Shell, anyone?).

The comment on this commit says:

1Since SerializationUtils#deserialize is based on Java's serialization
2mechanism, it can be the source of Remote Code Execution (RCE)
3vulnerabilities.

As the day progressed, there was more buzz (with very little verifiable fact to back it up) that we might be dealing with an RCE in Spring Core.

Further down in the comments, a Spring Core committer validated another comment stating that this commit had nothing to do with any known RCE.

And, in fact, if you look at the PR the commit resolves, it was first opened on February 18th.

Now, here’s the kicker: while all this was going on, the Interwebs was busy conflating this evolving issue with another known issue in a completely different project: Spring Cloud Function. So as to not further this confusion, I won’t go into the details of this vulnerability. Suffice it to say that if you’re reading something on vulnerabilities in Spring Cloud, you’re barking up the wrong tree for information on Spring4Shell (please, can we give it a different name?).

Bottom line

Protect yourself from Spring4Shell by performing the remediation actions recommended up above. You can sign up for a free Snyk account to start fixing.