This Spring4Shell flow chart helps you make the right decisions

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.

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).

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

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

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:

1. 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
2. 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.

It is important for your organization to take at least the following steps:

1. Map out which individual vendors you have for on-premises software packages, Software-as-a-Service (SaaS) or other application vendors;
2. 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;
3. Contact your vendors to verify if 'Spring Framework' is used within the applications and which version of Spring Framework is used;
4. 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.

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.

1. If possible, disconnect affected systems from the network, but leave them on (because of possible traces such as volatile memory - RAM);
2. Have the affected systems forensically examined; ensure adequate backups;
3. Reset your passwords and user data;
4. Report to the Police;
5. 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.

Then call 088 133 0700 and we will do our utmost to help you as quickly as possible.(Learn more about our Incident Response Service.)