Spring4Shell is a critical vulnerability (CVSSv3 9.8) targetting Java’s most popular framework, Spring, and was disclosed on 31 March ...
back to BLOG

Spring4Shell [CVE-2022-22965]: What it is and how to detect it

Benjamin Marr

What is Spring4Shell (CVE-2022-22965)?

Spring4Shell (CVE-2022-22965) is a critical vulnerability (CVSSv3 9.8) targeting Java’s most popular framework, Spring, and was disclosed on 31 March 2022 by VMWare. The vulnerability affects Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, as well as all older versions. For an application to be fully vulnerable to the currently (13/04/2020) known vectors, the additional pre-requisites will be required:

What does the Spring4Shell vulnerability enable attackers to do?

The Spring4Shell vulnerability allows attackers to execute arbitrary code on the application server where a number of pre-requisites are met.

Now that we've had some time to assess the impact, and despite the initial furore online, we're happy with our initial gut feeling that this was not going to be as impactful as Log4j due to the number of pre-requisites. We like to be evidence-based, and since the disclosure of this vulnerability, we have used various detection techniques against our clients' assets (>25,000). As of today (13/04/2022), we have yet to find a vulnerable application. Though with the caveat that the community accepted detection method similar to @_teedge's work has thrown some false positives. These individual occurrences have been marked down as WAF intervention or specific application quirks (non-Java apps throwing an HTTP 400).

As with any vulnerability, things could change the moment a bypass or alternative route of exploitation is disclosed. As such, we continue to monitor the impact of this vulnerability as it develops and will provide further updates when required.

How to detect Spring4Shell

From an external perspective, identifying the vulnerability can be very tricky due to the several pre-requisites. However, @_tweedge on Twitter has put together a simple payload that can induce a HTTP 400 error as shown below:


From an internal perspective, there are two methods.

The first is to identify if the target application/system meets the following:

  1. JDK v9+
  2. Tomcat Apache versions below 10.0.20, 9.0.62, and 8.5.78
  3. The application is packaged as a WAR
  4. Using Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older
  5. Utilising either the spring-webmvc or spring-webflux dependencies

The second option is to refer to rules which the community is collating for open source SAST software, such as SemGrep rules (source):

How you can fix the Spring4Shell vulnerability

The most effective solution to fix the Spring4Shell vulnerability is to upgrade to Spring Framework 5.3.18 and 5.2.20.

If you are unable to upgrade the Spring Framework, there are a handful of workarounds that you can deploy. These are either:

How you can defend against exploitation

There are two steps you can take to defend against exploitation.

Firstly, include WAF rules for indicators that attacks are attempting to exploit the application. The current known attack vectors revolve around the modification of Tomcat's logging capabilities. This can be matched through the following string:

Alternatively, vendors are releasing detection rules for their offerings:

Next, monitor the application's root for the inclusion of any web backdoors.

How you can identify exploitation


There has been a number of tooling releases since the initial post, these include Nmap detection scripts, plugins for open source scanners such as Nuclei, additionally all of the major vulnerability management vendors should have detections in place including Intruder.

Detection Rules

We have gathered tips from three sources: one trusted; one semi-trusted and one untested.

UNTESTED Source – a west-wind has built some Splunk rules for detection:

Detect requests that attempt to change logging within Tomcat:

Detect a weaponised payload based off the basic proof of concepts available:

Semi-Trusted Source - Splunk rules by Alex

Trusted Source: Community YARA rules for detection by Florian Roth

Vulnerable Application to Sandbox attacks against


Spring4Shell scanner: how Intruder is helping

We are doing all we can to help Intruder customers and are closely monitoring the situation as it develops.

In addition, we're running exploratory checks for our Vanguard customers and sending them security advisories if any issues are detected. Internal checks are already available, we recommend scheduling a security scan to review the security of your systems.

A screenshot of the Intruder issues page with the detected Spring4Shell Command Injection vulnerability

Intruder offers a 14-day free trial, where you can run unlimited scans to check your system for multiple vulnerabilities, including Spring4Shell weaknesses.



Release Date
Level of Ideal
Before CVE details are published
Limited public information is available about the vulnerability.

Red teamers, security researchers, detection engineers, threat actors have to actively research type of vulnerability, location in vulnerable software and build an associated exploit.

Tenable release checks for 47.43% of the CVEs they cover in this window, and Greenbone release 32.96%.
Day of CVE publish
Vulnerability information is publicly accessible.

Red teamers, security researchers, detection engineers and threat actors now have access to some of the information they were previously having to hunt themselves, speeding up potential exploit creation.

Tenable release checks for 17.12% of the CVEs they cover in this window, and Greenbone release 17.69%.
First week since CVE publish
Vulnerability information has been publicly available for up to 1 week.

The likelihood that exploitation in the wild is going to be happening is steadily increasing.

Tenable release checks for 10.9% of the CVEs they cover in this window, and Greenbone release 20.69%.
Between 1 week and 1 month since CVE publish
Vulnerability information has been publicly available for up to 1 month, and some very clever people have had time to craft an exploit.

We’re starting to lose some of the benefit of rapid, automated vulnerability detection.

Tenable release checks for 9.58% of the CVEs they cover in this window, and Greenbone release 12.43%.
After 1 month since CVE publish
Information has been publicly available for more than 31 days.

Any detection released a month after the details are publicly available is decreasing in value for me.

Tenable release checks for 14.97% of the CVEs they cover over a month after the CVE details have been published, and Greenbone release 16.23%.

With this information in mind, I wanted to check what is the delay for both Tenable and Greenbone to release a detection for their scanners. The following section will focus on vulnerabilities which:

These are the ones where an attacker can point their exploit code at your vulnerable system and gain unauthorised access.

We’ve seen previously that Tenable have remote checks for 643 critical vulnerabilities, and OpenVAS have remote checks for 450 critical vulnerabilities. Tenable release remote checks for critical vulnerabilities within 1 month of the details being made public 58.4% of the time, but Greenbone release their checks within 1 month 76.8% of the time. So, even though OpenVAS has fewer checks for those critical vulnerabilities, you are more likely to get them within 1 month of the details being made public. Let’s break that down further.

In Figure 10 we can see the absolute number of remote checks released on a given day after a CVE for a critical vulnerability has been published. What you can immediately see is that both Tenable and OpenVAS release the majority of their checks on or before the CVE details are made public; Tenable have released checks for 247 CVEs, and OpenVAS have released checks for 144 CVEs. Then since 2010 Tenable have remote released checks for 147 critical CVEs and OpenVAS 79 critical CVEs on the same day as the vulnerability details were published. The number of vulnerabilities then drops off across the first week and drops further after 1 week, as we would hope for in an efficient time-to-release scenario.

Figure 10: Absolute numbers of critical CVEs with a remote check release date from the date a CVE is published

While raw numbers are good, Tenable have a larger number of checks available so it could be unfair to go on raw numbers alone. It’s potentially more important to understand the likelihood that OpenVAS or Tenable will release a check of a vulnerability on any given day after a CVE for a critical vulnerability is released. In Figure 11 we can see that Tenable release 61% their checks on or before the date that a CVE is published, and OpenVAS release a shade under 50% of their checks on or before the day that a CVE is published.

Figure 11: Percentage chance of delay for critical vulnerabilities

So, since 2010 Tenable has more frequently released their checks before or on the same day as the CVE details have been published for critical vulnerabilities. While Tenable is leading at this point, Greenbone’s community feed still gets a considerable percentage of their checks out on or before day 0.

I thought I’d go another step further and try and see if I could identify any trend in each organisations release delay, are they getting better year-on-year or are their releases getting later? In Figure 12 I’ve taken the mean delay for critical vulnerabilities per year and plotted them. The mean as a metric is particularly influenced by outliers in a data set, so I expected some wackiness and limited the mean to only checks released 180 days prior to a CVE being published and 31 days after a CVE being published. These seem to me like reasonable limits, as anything greater than 6 months prior to CVE details being released is potentially a quirk of the check details and anything after a 1-month delay is less important for us.

What can we take away from Figure 12?

Figure 12: Release delay year-on-year (lower is better)

With the larger number of checks, and still being able to release a greater percentage of their remote checks for critical vulnerabilities Tenable could win this category. However, the delay time from 2019 and 2020 going to OpenVAS, and the trend lines being so close, I am going to declare this one a tie. It’s a tie.

The takeaway from this is that both vendors are getting their checks out the majority of the time either before the CVE details are published or on the day the details are published. This is overwhelmingly positive for both scanning solutions. Over time both also appear to be releasing remote checks for critical vulnerabilities more quickly.

Written by

Benjamin Marr

Recommended articles

Ready to get started with your 14-day trial?

try for free