New Java Framework Vulnerability and Mitigations: Spring4Shell

The Spring4Shell is a critical vulnerability that places executable code from the outside of the framework. It gained its name from the similarity with the infamous Log4Shell threat in the Spring Java framework. Spring4Shell came to light in early April, and researchers are already patching it.

To ensure the safety of any Java device you might be using, you must update your Java Spring framework to version 5.3.18 or newer. Otherwise, any device using this framework can become a target of an attack. It can even become a beachfront for parallel attacks.

Affected devices can include:

  • Desktops
  • Servers
  • Smart TVs
  • Smartphones
  • Tablets
  • Blu-ray players

The threat can introduce any type of code to the framework, including command sets. That means it can damage the device itself and any devices connected to it. In a business or IoT environment, it’ll make a Java device a critical weak point for your cybersecurity.

Image of a personal computer running Java with wireless devices around.
Spring4Shell, affecting your Java devices and others connected to them.

Spring4Shell Technical Details

Specifically, the Spring4Shell and SpringShell vulnerabilities are designated as CVE-2022-22965. It’s a data binding function stored inside HTTP requests, and also leaks data or executes external code. Another designation is CVE-2022-22963. It allows exploiters to enter code from the outside using SpEL, the Spring Expression Language.

Through CVE-2022-22965, exploiters can get unauthorized access to the framework. How? They may abuse the getCachedIntrospectionResults. It’ll pass their class names with an HTTP request and risk an information leak or code execution.

Because it looks very similar to the five-month-old CVE-2021-44228, researchers have called the vulnerability Spring4Shell. The issue isn’t identical, but it happened because of the newer version of the Java Development Kit (JDK), which allows the exploit through the Java 9 Platform Module System.

Through this exploit, a malicious entity can change the Tomcat log configuration and upload a whole JSP web-shell. These Java Service Pages web-shell can also further execute any command on a server running the framework.

Similarly, the CVE-2022-22963 vulnerability exploits the routing function of the SCF (Spring Cloud Functions).  Here, a hacker can use a simple expression header added to the HTTP request. That way, they can introduce foreign code that would have gone unnoticed by the framework.

Risk Indicators for Spring4Shell

The best way to test whether the Spring4Shell vulnerability has compromised your system is via the MD5 hashes and verdicts.

Exploit MD5 hashes are as follows:

  • 7e46801dd171bb5bf1771df1239d760c – shell.jsp
  • 3de4e174c2c8612aebb3adef10027679 –

You can also find the Product Data Management file Exploit.Win32.Generic, which is a system-sensitive executable. You can also look for UMIDS named Intrusion.Generic.Agent.gen and Intrusion.Generic.CVE-2022-22965. 

Image of a computer screen with exploited Java Code.
Java Code that Spring4Shell exploits.

Affected Devices

Currently, five configurations are vulnerable:

  1. Java Developer Kit 9+
  2. Apache Tomcat
  3. Version 5.3.18 of the Spring Framework and older
  4. WAR file applications
  5. Dependency on spring-webmvc or spring-webflux

From the above, we can deduce that this vulnerability mainly targets devices with a lot of direct connections. In fact, cybercriminals also take advantage of connections where they can use an executable file. This will primarily affect any server that isn’t patched over with the JSF version 5.3.18. Spring4Shell will also target servers with a lot of personal computers or other Java-capable devices connected to it.

Additionally, all IoT devices running Java (even wirelessly) can take the hit.  This issue can also pose a personal risk, because the vulnerability can hit Android or Windows OS smart-home appliances. That even extends to home cameras.

A special issue may come with IoT devices for those who are working remotely. An attack can affect their personal devices and compromise the server where they have access.

It’s always recommended that you regularly update to the newest version of the Java Spring Framework. That way, you allow as little time as possible from the moment the issue arises to when it is resolved. .

Image of a computer screen with code written on it.
Java Code Inspector.

Security Route and Mitigation

The best method of mitigating any risk currently is immediately updating to the Spring Framework 5.3.18 and 5.2.20 or newer, depending on when you’re reading this. This way, you’ll ensure that the vulnerability is no longer executable, and you won’t be at risk anymore.

Alternatively, we have several workarounds for those who can’t update due to server uptime demands or other circumstances.

Primarily, you should upgrade Tomcat as a tactical solution. You can upgrade to version 8.5.78, version 9.0.62, or version 10.0.20. These may give you enough protection until you can update the Spring Framework.

Further, you may want to downgrade your system to Java version 8. If for any reason, you can’t update JSF or Tomcat, The downgrade will disallow access to the compromised portions of the HTTP.

Finally, you can set disallowedFields on your web data binder to remove access globally. This is a general command, so you should note any loopholes. You should also notice if the command removes some services.

You can see the Spring suggested workaround on their blog for Spring MVC.

Regardless, you should create a backup and update your system to the new version. Otherwise, you may want to announce a downtime if possible. The workaround will take just a couple of minutes of downtime, as the vulnerability hasn’t affected any of the internal systems, only the JSF version.

The Bottom Line

Thankfully for everyone using the Java Development Kit, a complete workaround and update became available less than 4 hours after the issue popped up. Because of that, the intrusion likely only affected the targets that originally suffered from the breach.

Still, it’s important for all Java device users, both business and individual, to update regularly and to check their system for any intrusions or suspicious code.

Get The Latest CyberSecurity News


TechGenix: Log4Shell, A Quick Overview

Read more about the most dangerous Java exploit in years here

TechGenix: Javascript Tactical Cache Attacks

Discover all about practical cache attacks in Javascript here

TechGenix: Is Java Still Alive?

Read this article for our insights on Java in the enterprise.

TechGenix: Java Security Warning Feature

Learn about Java’s security warning feature here

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top