CVE-2024-38816: Spring Framework Path Traversal Vulnerability Threatens Millions
A serious security vulnerability, identified as CVE-2024-38816 (CVSS 7.5), has been discovered in the popular Spring Framework, potentially affecting millions of Java applications worldwide. This path traversal vulnerability allows attackers to gain unauthorized access to sensitive files on the server, posing a significant risk of data breaches and system compromise.
The vulnerability lies in how Spring Framework handles static resources served through the functional web frameworks WebMvc.fn or WebFlux.fn. By crafting malicious HTTP requests, attackers can bypass security measures and retrieve arbitrary files from the server’s file system, including configuration files, source code, and user data.
Specifically, an application is vulnerable when both of the following are true:
- the web application uses RouterFunctions to serve static resources
- resource handling is explicitly configured with a FileSystemResource location
However, malicious requests are blocked and rejected when any of the following is true:
- the Spring Security HTTP Firewall is in use
- the application runs on Tomcat or Jetty
The impact of the CVE-2024-38816 vulnerability is far-reaching, as Spring Framework is widely adopted across various industries and applications. Any application using the affected versions of Spring Framework (5.3.0 to 5.3.39, 6.0.0 to 6.0.23, and 6.1.0 to 6.1.12) and serving static resources through the vulnerable components is at risk.
The Spring team has released patched versions to address this vulnerability. It is crucial for organizations to upgrade their Spring Framework installations to the latest versions immediately.
- Upgrade to the Latest Version: The most effective mitigation is to upgrade to the fixed versions: 5.3.40, 6.0.24, or 6.1.13, depending on your current version.
- Enable Spring Security’s HTTP Firewall: For older, unsupported versions, enabling the Spring Security HTTP Firewall can provide an additional layer of protection.
- Switch to Tomcat or Jetty: If feasible, consider switching to Tomcat or Jetty as your web server, as they inherently reject the malicious requests that exploit this vulnerability.
