April begins strong with the discovery of a 9.8 RCE (Remote Code Execution) new vulnerability without any prior authentication in the Java Spring opensource framework.


Context of the Spring4Shell attack

After the Java Log4j library, a Zero-Day vulnerability in the Java Spring framework was identified and fixed on 31 March. But it appears that it is already being actively exploited, and the code enabling it is also publicly available.

This framework is widely used for web application development and its inclusion in a large number of software packages portends the same nightmare as Log4shell for the developer community.


Vulnerability technical details

The vulnerability is present in the getCachedIntrospectionResults function which exposes the whole class of the object when associating the parameters. The mechanism for associating HTTP requests to objects in the application is therefore impacted. This means that the user can forge an HTTP request (via the URL) in order to get the details of the object class in return.

This type of exposure can be used to load malicious code in return that will dynamically modify the class or even execute code. Typically, in the observed case it is about loading a webshell that will give the remote user the total control of the machine, with the execution rights of the Java machine (often root).

In order to understand the origin of the vulnerability, we have to go back to the comment around a potentially dangerous function exposed by the Spring framework warning the developer of a security risk.

Figure 1:  ticket gh-28075 comments

This is the triggering event of several vulnerability searches conducted on this mechanism of the Spring framework that quickly led to the discovery of the CVE that interests us here, Spring4Shell.

However, Spring4Shell is only a workaround of an old vulnerability, the CVE-2010-1622, impacting the constructor of the CachedIntrospectionResults class which has already been patched.


Figure 2: 2 july 2010 CVE-2010-1622 patch of framework Spring v2.5


Figure 3: 31 march CVE-2022-22965 patch of framework Spring v5.3


Impacted software and versions

Proofs of concept have been observed on the following software and SDKs:

  • JDK 9 and higher,
  • Apache Tomcat Servlet as a container,
  • Spring-webmvc and spring-webflux dependencies,
  • The Spring framework in versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions,
  • Any Java application using the Spring Beans package.


We have found the following IPs trying to exploit the vulnerability:


Stormshield products protections

Stormshield Network Security

An IPS signature has been published on SNS, allowing to detect and block attempts to manipulate the "classLoader" class from an HTTP POST request. This works by analyzing the HTTP traffic, which must be in clear text when inspected. If the flow is encrypted, the SSL proxy must be activated (outgoing flow), or else decryption must be done on another upstream device (incoming flow). This signature is:

http:client:data.163  Spring4Shell RCE attempt on HTTP POST request (CVE-2022-22925)

All IoC’s listed in this article have been added to our IP Reputation.

Stormshield protection confidence index

Stormshield confidence index of no false positives

Stormshield Endpoint Security

The different versions of SES (7.2 and Evolution) being desktop and server protection solutions, they will not block the exploitation of this vulnerability directly. However, they will be able to prevent the payload from executing correctly and thus avoid any impact. The blocking will depend on the payload used.

Whatever your version of SES (7.2 or Evolution), it is nevertheless possible to add an audit rule for the creation of *.jsp files in the folders of the server that may be vulnerable to Spring4Shell. This will allow you to be alerted very quickly if an attacker would drop a file containing Java code via this attack.


We recommend to update Spring Framework to version 5.2.20 or 5.3.18.

Share on

[juiz_sps buttons="facebook, twitter, linkedin, mail"]
Our Threat Intelligence team has two key missions: to study cyber threats in order to understand them, and to continuously improve the protection offered by Stormshield products. The goal in each case is to contribute to the cybersecurity community's effort to address cyber threats.
About the author
Edouard Simpere Cyber Threat Intelligence Team Leader, Stormshield

With a strong appetite for dark humor, starred chefs' pastries and the Windows environment, Edouard is a cybersecurity buff, a real one. A living standard of internal mobility at Stormshield, he made his first, second and third steps around the Stormshield Endpoint Security Evolution product, as a developer, architect and technical leader. He then became head of the company's Threat Intelligence team, in charge of researching and maintaining the level of protection of all the company's products.