Spring Framework Zero-Day Remote Code Execution (Spring4Shell) Vulnerability 

This page last updated: April 7^th

A new zero-day Remote Code Execution (RCE) vulnerability, “Spring4Shell” or “SpringShell” was disclosed in the Spring framework. An unauthorized attacker can exploit this vulnerability to remotely execute arbitrary code on the target device. 

What is Spring Framework? 

Spring-core is a prevalent framework widely used in Java applications that allows software developers to develop Java applications with enterprise-level components effortlessly. 

Which versions are vulnerable? 

The vulnerability requires JDK version 9 or later to be running. Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions are vulnerable. It allows remote attackers to plant a web shell when running Spring framework apps on top of JRE 9. It is caused by unsafe deserialization of given arguments that a simple HTTP POST request can trigger to allow full remote access. 

How can this be exploited? 

The exploitation of this vulnerability relies on an endpoint with DataBinder enabled, which decodes data from the request body automatically. This property could enable an attacker to leverage Spring4Shell against a vulnerable application. In fact, the Spring framework class DataBinder warns about this in its documentation: 

“Note that there are potential security implications in failing to set an array of allowed fields. In the case of HTTP form POST data, for example, malicious clients can attempt to subvert an application by supplying values for fields or properties that do not exist on the form. In some cases, this could lead to illegal data being set on command objects or their nested objects. For this reason, it is highly recommended to specify the allowedFields property on the DataBinder.” 

What are the prerequisites to exploit this vulnerability? 

• JDK 9 or higher 
• Apache Tomcat as the Servlet container 
• Packaged as a traditional WAR (in contrast to a Spring Boot executable jar) 
• spring-webmvc or spring-webflux dependency 
• Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions 

Is there a patch available for Spring4Shell? 

Spring Framework 5.3.18 and 5.2.20, that contain the fixes, have been released. If you’re able to upgrade to Spring Framework 5.3.18 and 5.2.20, no workarounds are necessary. 

In case you cannot update to the latest Spring Framework version upgrading to Apache Tomcat  10.0.20, 9.0.62, or  8.5.78 provides adequate protection but not solves the vulnerability completely.  

In addition, there are multiple working proof-of-concept (PoC) exploits available for Spring4Shell. We strongly recommend that organizations deploy these mitigations or use a third-party firewall for defense. 

Qualys Coverage 

Qualys Research Team has released the following authenticated QIDs to address this vulnerability for now. These QIDs will be available starting with vulnsigs version VULNSIGS-2.5.438-3 and in Cloud Agent manifest version LX_MANIFEST-2.5.438.3-2. 

QID	Title	Version	Available for
376506	Spring Core Remote Code Execution (RCE) Vulnerability (Spring4Shell)	VULNSIGS-2.5.438-3	Scanner/Cloud Agent
45525	Spring core or Spring beans jar detected	VULNSIGS-2.5.438-3	Scanner/Cloud Agent
150494	Spring Cloud Function Remote Code Execution (RCE) Vulnerability (CVE-2022-22963)	VULNSIGS-2.5.440-3	Web Application Security
376508	Spring Cloud Function Remote Code Execution (RCE) Vulnerability (Authenticated)	VULNSIGS-2.5.440-6/ lx_manifest-2.5.440.6-5	Scanner/Cloud Agent
730418	Spring Cloud Function Remote Code Execution (RCE) Vulnerability (Unauthenticated Check)	VULNSIGS-2.5.440-6	Scanner
150495	Spring Core Remote Code Execution (RCE) Vulnerability CVE-2022-22965 (Spring4Shell)	VULNSIGS-2.5.443-3	Web Application Security
48209	Spring Framework and Spring Boot JARs Spring Cloud JARs Detected Scan Utility	VULNSIGS-2.5.444-2/manifest 2.5.444.2-1	Scanner/Cloud Agent
376514	Spring Framework Remote Code Execution (RCE) Vulnerability (Spring4Shell) Scan Utility	VULNSIGS-2.5.444-2/manifest 2.5.444.2-1	Scanner/Cloud Agent
376520	Spring Cloud Function Remote Code Execution (RCE) Vulnerability Scan Utility	VULNSIGS-2.5.444-2/manifest 2.5.444.2-1	Scanner/Cloud Agent
730416	Spring Core Remote Code Execution (RCE) Vulnerability (Spring4Shell) (Unauthenticated Check)	VULNSIGS-2.5.445-3	Scanner

Discover Your Attack Surface with up-to-date CyberSecurity Asset Management 

As a first step, Qualys recommends assessing all assets in your environment to map the entire attack surface of your organization.  

Scoping Potential Attack Surface 

Qualys Cybersecurity Asset Management (CSAM) continuously inventories all your assets and software. Use CSAM to find assets with Apache Tomcat running on JDK 9 or higher. 

QQL: software:(name:tomcat) and software:(name:"jdk" and version>=9) 

Finding Vulnerable Spring Components and Versions 

Qualys CSAM can further help you narrow down the scope by adding Spring Framework to the search criteria, and specifically match on vulnerable components and versions.  This can be used to find assets that have not yet been scanned with VMDR for the Spring4Shell QIDs yet. 

QQL: software:(name:tomcat) and software:(name:"jdk" and version>=9) and software:(name:"Spring" and version:"vulnerable") 

Monitoring Upgrades and Mitigations 

Upgrading to Spring Framework 5.3.18+ or 5.2.20+ addresses the root cause and prevents other attack vectors, and it adds protection for other CVEs. Qualys CSAM allows customers to list all Spring Framework versions and verify upgrades. 

However, some may be in a position where upgrading is not possible to do quickly.  VMware provided the mitigation alternative to upgrade Apache Tomcat to versions 10.0.20, 9.0.62, or 8.5.78, which close the attack vector on Tomcat’s side.  Qualys CSAM allows you to check for the presence or absence of these Tomcat updates. 

QQL for assets with mitigated Tomcat: 

software:(name:tomcat and update:[`10.0.20`,`9.0.62`,`8.5.78`]) 

QQL for assets excluding mitigated Tomcat: 

software:(name:tomcat and not update:[`10.0.20`,`9.0.62`,`8.5.78`]) and software:(name:"jdk" and version>=9) and software:(name:"Spring" and version:"vulnerable") 

Context Is Critical to Prioritize and Remediate 

Security teams need to understand the distribution of affected assets from different perspectives, such as internet-exposed, production versus non-production, and which of these assets support business-critical services. Qualys CSAM integrates with additional sources, to import asset and business context, that helps customers further understand their impact, prioritize assets based on business criticality, and work with corresponding asset owners and support groups to take remedial actions. 

QQL for assets with Tomcat exposed to the internet and visible in Shodan: 

software:(name:tomcat) and software:(name:"jdk" and version>=9) and tags.name:shodan 

Detect the Vulnerability with Qualys WAS

Second, protect your public Internet-facing apps, as they are the most exposed to attack and therefore high priority.  

The Qualys WAS Research Team has developed two signatures for detecting vulnerable versions of the Spring Framework.  

• QID 150494 (released April 1^st) will report vulnerable versions of Spring Cloud Applications (CVE-2022-22963). 
• QID 150495 (released on 6^th) will report vulnerable versions of Spring Core Applications (CVE-2022-22965).  

These QIDs are automatically added to the Core Detection Scope.  If you are scanning web applications with the Initial WAS Option Profile then there is no further action necessary.  Your scans will automatically test for vulnerable versions of the Spring Framework and report any vulnerable instances found. 

If you are using a custom Option Profile for your scans, please ensure you are either using the Core Detection Scope in your Option Profile or adding the above QIDs to any static or dynamic Custom Search Lists. 

These QIDs collectively use a combination of Out-of-Band and non-Out-of-Band tests for accurate detection.   

The WAS Research Team is investigating other safe methods for detecting this vulnerability to compensate for potential False Negatives or False Positive cases.  In the meantime, it is recommended to use WAS in coordination with other Qualys modules for a more comprehensive methodology for detecting the Spring4Shell vulnerability. 

If your application is vulnerable to Spring4Shell, it is recommended that you immediately follow the steps outlined in the “Is there a patch available for Spring4Shell?” section of this blog. 

Detect Spring4Shell Vulnerability Using Qualys VMDR

Next, it’s time to find Spring4Shell wherever it is hiding in your environment and prioritize your response.

Qualys VMDR customers should ensure all their assets are scanned against the above QIDs. As this vulnerability only targets the Spring Framework when deployed with JDK>9 and Tomcat, customers must at least ensure assets with Tomcat and JDK>9 are scanned. The following QQL can be used to find such assets: 

software:(name:tomcat and not update:[`10.0.20`,`9.0.62`,`8.5.78`]) and software:(name:"jdk" and version>=9) 

Once assets have been scanned for the above QIDs, customers can use the following QQL to search for the Spring4Shell vulnerability in their environment: 

vulnerabilities.vulnerability.qid:376506 

Track Spring4Shell Progress with Unified Dashboard

The Unified Dashboard enables you to track this vulnerability and its impacted hosts, their status, and overall management in real-time. To help you quickly find vulnerable hosts and software, a new unified dashboard is created on the Qualys platform. This dashboard has extremely useful widgets listing all the vulnerable hosts, applications with vulnerable versions of Spring, and most importantly all the vulnerable hosts visible on the Internet. It provides visibility to compliance configurations and software on your ‘External Attack Surface’ visible on Shodan being the low-hanging opportunities for attackers. These widgets also list workloads hosted on shared cloud infrastructure and that have public IP addresses. To use this capability, download and import this Global Dashboard. 

Detect Spring4Shell Vulnerabilities in Running Containers & Images

If you run Apache Tomcat in containers, then it is critical that you check for Spring4Shell vulnerabilities, given the high severity of this potential exploit. Qualys Container Security offers multiple methods to help you detect Spring4Shell vulnerabilities in your container environment. The Container Security sensor checks both running containers and container images for the following vulnerabilities: 

• QID 376506(CVE-2022-22965) 
• QID 376508 (CVE-2022-22963 

To detect vulnerabilities in running containers, you must deploy the Container Security sensor in “General” mode on the hosts running the containers. You can view the containers impacted by these vulnerabilities by navigating to the “Container Security” application, then selecting the “Assets-> Container” tab, and using the following QQL query:   

vulnerabilities.qid:376506 or vulnerabilities.qid:376508 

To view details of the vulnerability, you can click on the vulnerable container and navigate to the “Vulnerabilities” tab as shown in the screenshot below: 

In addition to scanning running containers, Qualys recommends that you scan container images for Spring4Shell vulnerabilities. Catching and remediating Spring4Shell vulnerabilities in container images will eliminate exposure to the vulnerabilities when the image is instantiated as a container. 

To view all the impacted images, navigate to the Qualys Container Security app, then select the “Assets -> Images” tab, and use the following QQL query:  

vulnerabilities.qid:376506 or vulnerabilities.qid:376508 

To view details of the vulnerability, you can click on the image and navigate to the “Vulnerabilities” tab as shown in the screenshot below: 

Qualys Container Security offers a comprehensive solution for detecting vulnerabilities, including Spring4Shell, across the entire lifecycle of the container from build time to runtime. 

Remediate Spring4Shell Using Qualys Patch Management

The recommended way to patch this vulnerability is by updating to Spring Framework 5.3.18 and 5.2.20 or greater. Customers can use Patch Management’s install software action to download and script the upgrade. Note that customers can create a patch job that only includes the install/script action, in such case there is no need to add patches to the job. Alternatively, if upgrading the Spring Framework is not possible, customers can use Qualys patch management to patch Tomcat to versions: 10.0.20, 9.0.62, or 8.5.78. Tomcat patches are supported out-of-the-box and require no special configuration.  

Detect Spring4Shell Exploitation Attempts with Qualys XDR

An important last step in confronting Spring4Shell is to ensure that your organization has not already been targeted by attacks that exploit this vulnerability.  

The Qualys Threat Intelligence team has released the following XDR correlation rules for detecting Remote Code Execution exploitation attempts. These rules are available today via your TAM for quick import and implementation and will be delivered as part of a rule pack in a future XDR release. 

T1190 – [Palo Alto Firewall] Spring4Shell RCE Vulnerability Exploitation Detected (CVE-2022-22965) 

T1190 – [Check Point IPS] Spring4Shell RCE Vulnerability Exploitation Detected (CVE-2022-22965) 

T1190 – [Fortinet Firewall] Spring4Shell RCE Vulnerability Exploitation Detected (CVE-2022-22965) 

T1190 – [Trend Micro TippingPoint IPS] Spring4Shell RCE Vulnerability Exploitation Detected (CVE-2022-22965) 

FAQ: 

Is this vulnerability related to CVE-2022-22963? 

There is some confusion about this zero-day vulnerability due to another unrelated Spring vulnerability (CVE-2022-22963) published on March 29, 2022. This vulnerability, CVE-2022-22963, impacts Spring Cloud Function, which is not in Spring Framework.  

QIDs 376508 and 730418 are available to address this CVE. 

What is the detection logic for QID 376506: Spring Core Remote Code Execution (RCE) Vulnerability (Spring4Shell)? 

QID 376506 is an authenticated check currently supported on Linux and Windows Operating Systems. 

On Linux systems, detection checks if system has java 9 or later versions and executes ‘locate’ and ‘  ls -l /proc/*/fd  ‘ to checks if one of the ‘  spring-webmvc-*.jar  ‘, ‘  spring-webflux*.jar  ‘ or ‘  spring-boot.*jar  ‘ present on the system. 

On Windows system, detection checks vulnerable instances of Spring via WMI to check spring-webmvc, spring-webflux and spring-boot are included in the running processes via command-line with JDK9 or higher. 

Container Sensor image scanning uses find command to check for spring-webmvc, spring-webflux and spring-boot jars from .war files along with JDK9 or higher. 

Under what situations would QID 376506 not detect the vulnerability? 

QID 376506 might not be detected if access to /proc/*/fd is restricted or if the spring-core or spring-beans file is embedded inside other binaries, such as jar, war, etc. 

Furthermore, this QID might not be detected if the locate command is not available on the target. Targets on Java versions less than 9 are not vulnerable. 

What is the detection logic for QID 730416 (unauthenticated check)? 

QID 730416 is a remote unauthenticated check. It sends a specially crafted HTTP GET request to the remote web application and tries to get a callback on scanner using payload:

"?class.module.classLoader.resources.context.configFile=http://<Scanner_IP>:<Random_port>&class.module.classLoader.resources.context.configFile" 

QID 730416 is an intrusive check. The payload used in the detection may in some cases change the Spring configuration on the target application which can hamper the application’s logging capabilities. 

Under what conditions would QID 730416 not work? 

QID 730416 will not work if the following conditions are present: 

• “Do not exclude Intrusive checks” is not enabled in Scan Option Profile 
• This QID only checks for the vulnerability at root URI. If the vulnerability lies in non-root URIs, the QID would not be detected. 
• If communication from host to scanner is blocked. 
• The payload gets blocked by a firewall, IPS, etc. that is between the host and the scanner. 

Updates

Update – April 7 

A new QID (730416) was added to address CVE-2022-22963 under “QID Coverage”.  

Update – April 6 

Several new QIDs to address CVE-2022-22963 are now available under “QID Coverage”. The CSAM section has been expanded.  

Update – April 5 

Guidance added for detection using Qualys CSAM, VMDR and XDR, and tracking remediation progress using Unified Dashboards and Patch Management. 

Update – April 4  

Qualys has added a scan utility for Windows and scan utility for Linux to scan the entire hard drive(s), including archives (and nested JARs,) that indicate the Java application contains a vulnerable Spring Framework or Spring Cloud library. 

Update – April 1 

New QIDs to address CVE-2022-22963 are now available. See section “QID Coverage” section. 

Update – March 31 

CVE-2022-22965 is now assigned to this vulnerability.  Qualys Research Team has released QIDs as of March 30 and will keep updating those QIDs as new information is available.