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:
- https://tanzu.vmware.com/security/cve-2022-22965
- https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/validation/DataBinder.html#setAllowedFields-java.lang.String
To stay up to date on recent security vulnerabilities subscribe to our blog!