In recent days, many organizations have asked for our help in making the right decisions around applications in response to the Spring4Shell vulnerability. More and more details are becoming known but far from everything is completely clear. Nevertheless, it is advised to take action as soon as possible and take the appropriate measures to prevent unauthorized access to your systems. To help you make the right decisions, we have developed a Spring4Shell flow chart for you. This flow chart will help you make the right choices with the information that is currently available. Given the developments, it is advisable to check this page and our
Threat Intelligence Report
regularly. This is because they are updated as soon as new information is available.
Description:What is the Spring Core Framework?
Spring Core Framework is a collection of Java software libraries that can be used in software programs written in Java. Spring Core is embedded in many Java software.
The vulnerability allows an attacker - without requiring authentication - to execute unauthorized code in certain circumstances and gain access to the program/application and the information in that program/application.
To be able to abuse this vulnerability, several technical prerequisites are currently known, this list may not yet be complete.
As far as we know now, the application is vulnerable if it meets the following conditions:
- Uses Spring Core Framework (up to and including version 5.3.17);
- Uses spring-webmvc or spring-webflux dependencies (unconfirmed)
- Uses form bindings with "name=value" data.
- Does not use an allowlist or denylist that excludes the use of specific fields (such as "class", "module" and "classLoader").
- Runs on Java version 9 (JDK) or higher.
In short: Applications that are remotely accessible, can process user input, and use Spring Core Framework (a version lower than 5.3.17) to process this input may be vulnerable.
What potential impact does this vulnerability have?
If an attacker is able to successfully exploit the vulnerability then it can lead to the execution of unauthorized code on the affected systems. This could potentially result in the server running the application becoming compromised. This attack can be performed from the Internet where no authentication is required.
From a compromised server, an attacker could potentially gain access to the rest of the network. For this reason, the CVSS vulnerability score was classified as critical (9.8).
What are the Indications abuse of this vulnerability?
At the time of writing, there are multiple indicators that there are active attempts to exploit the vulnerability - including attempts by known rogue IP addresses to exploit the vulnerability: https://otx.alienvault.com/pulse/6246c5778ca27726b90d842e
How is it detectable?
Because the vulnerable functionality resides in a popular Java software library which is widely used, the current scope or impact is not transparent. It is very likely that many used applications are vulnerable which are not known at the time of writing. The above makes fully detecting any abuse of the vulnerability, at the time of writing, complex.
However, a scanner has been published which may be able to detect the presence of the Spring Framework on (local) systems - this scanner is published via the code platform GitHub: https://github.com/hillu/local-spring-vuln-scanner
What are the recommendations?
For developers of applications using Spring Framework, the following advice applies:
A new version of Spring Framework is available which can be downloaded from the URL The recommendation is to at least update to Spring Framework version 5.3.18 (with Spring Boot 2.6.6 or 2.5.12) or Spring Framework 5.2.20.
NFIR recommends upgrading as soon as possible and then deploying to affected systems and applications.
At the point when upgrading is not possible, the following mitigation can be applied:
- For organizations that use Spring Framework itself and have specific bindings within applications that use non-standard data types, it is important to specify the allowed fields that the application may use - More information on this is available in the Spring Documentation: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/validation/DataBinder.html#:~:text=fields20when20binding.-,setAllowedFields,-publicC2A0voidC2A0setAllowedFields
- A second available mitigation (in the case that Tomcat is used as the underlying web server) involves updating Tomcat to versions 10.0.20, 9.0.62, and 8.5.78 (or higher) which will render the attack route via Tomcat inoperable. More information is available on the Spring website: https://spring.io/blog/2022/04/01/spring-framework-rce-mitigation-alternative
For third-party applications that you use, NFIR recommends that you contact the vendor for any updates.
Is there a plan of action?
It is important for your organization to take at least the following steps:
- Map out which individual vendors you have for on-premises software packages, Software-as-a-Service (SaaS) or other application vendors;
- Consult your vendor's website and determine if there is some form of 'dependency lists' available within which you can verify that 'Spring Framework' is being used within the application;
- Contact your vendors to verify if 'Spring Framework' is used within the applications and which version of Spring Framework is used;
- Prepare your organization for the situation when patches need to be executed unexpectedly (outside the regular update timeframes) and apply patches in a controlled manner according to the procedure usual for your organization.
Do you have systems where the risk is high (for example, systems with sensitive or special personal data)? If so, do you have any possible indications that Java is being used with Spring Framework and updates are not yet available? Then consider temporarily disabling the system.
What should your organization do in case of potential abuse?
If your organization is suspected to have been the victim of an attack, the urgent advice is to have research conducted into the cause, to what extent attackers may have compromised other systems and what information may have been accessed unauthorized.
- If possible, disconnect affected systems from the network, but leave them on (because of possible traces such as volatile memory - RAM);
- Have the affected systems forensically examined; ensure adequate backups;
- Reset your passwords and user data;
- Report to the Police;
- Consider filing a report with the Personal Data Authority.
Does your organization currently have an incident? Our Computer Emergency Response Teams (CERT) are available to organizations 24/7 to support IT Security Incidents.
Is your organization suspected of being the victim of an attack? If so, we urgently advise you to have an investigation carried out into the cause of the attack, the extent to which attackers may have compromised other systems and what information may have been accessed without authorisation.
Disclaimer: NFIR has made every effort to make this information accurate and reliable. However, the information provided is without any guarantee of any kind and its use is entirely at the risk of the user. NFIR assumes no responsibility or liability for the accuracy, content, completeness, legality or reliability of the information provided.