Just in Time

Just in Time Bulletin: CVE-2022-22965 Spring4Shell

Apr 01, 2022

What is Spring4Shell (CVE-2022-22965)?

CVE-2022-22965 known as Spring4Shell is an unauthenticated remote command execution vulnerability that impacts the Java Spring core framework running Java JDK 9 or higher. The vulnerability impacts applications that use DataBinding with non-standard data types or POJOs (plain-old-java-objects). The vulnerability introduces a condition where a “Class Loader Manipulation” attack is possible when @RequestMapping is used to parse a request.

How bad is this?

CVE	CVSSv3 Score
CVE-2022-22965	9.5

Active exploitation today: Exploited in the wild, proof of concept code publicly available.

Severity: Critical

Unauthenticated remote command execution
Results in trivial remote command execution on vulnerable platforms
Likely to be chained with privilege escalation exploits (DirtyPipe, PwnKit, SpoolFool, PrintNightmware, etc)

Who is affected by this?

Vulnerable applications have to satisfy a few non-standard requirements.

Endpoints running Java JDK 9 or higher
Applications must use Tomcat as a servlet container
Applications must be packaged as WARs (default is JAR)
Must use the Spring MVC or WebFlux dependencies
Must use DataBinding with non-standard parameter types

It is not yet clear how many real-world applications satisfy these requirements, but active exploitation and scanning is ongoing by attackers.

How are they exploited?

Exploitation is trivial and can be accomplished with a crafted request using cURL, however this is only possible under certain configurations.

Am I at Risk?

Spring Framework versions 4.3.0 through 5.3.15 are vulnerable to Spring4Shell.

Spring Framework Version	Fixed Spring Framework Version
5.3.0 to 5.3.17	5.3.18
5.2.0 to 5.2.19	5.2.20

How do I protect myself?

It is recommended that Spring Framework be updated to 5.2.20 or 5.3.18 to address the vulnerability.

If updating the Spring Framework is not possible, there are workarounds that can be applied to reduce the risk of exploitation. It is recommended in the Spring documentation that Spring applications specify the allowedFields property on the DataBinder to prevent values being submitted via request parameters that do not exist on the form.

Mitigating factors?

This requires that the source code of the vulnerable application be modified and recompiled. The following code provides an example of how to define an array that sets the “allowedFields”:

@ControllerAdvice

@Order(Ordered.LOWEST_PRECEDENCE)

public class BinderControllerAdvice {

@InitBinder

public void setAllowedFields(WebDataBinder dataBinder) {

String[] denylist = new String[]{“class.*”, “Class.*”, “*.class.*”, “*.Class.*”};

dataBinder.setDisallowedFields(denylist);

}

Additional Resources:

To stay up to date on recent security vulnerabilities subscribe to our blog!

Managed Security Services