DoS Attack via Range Requests

Vulnerability

The vulnerability resides in the ResourceHttpRequestHandler used to serve static resources and, starting in Spring Framework 5.0, in annotated controller methods that return an org.springframework.core.io.Resource. When handling HTTP range requests, the implementation does not limit the number of ranges or validate range overlap. A malicious actor can send a single request with an HTTP Range header containing a high number of ranges, or very wide overlapping ranges, triggering excessive resource consumption. Affected versions are Spring Framework 5.1, 5.0.x prior to 5.0.10, 4.3.x prior to 4.3.20, and older unsupported 4.2.x branches. Applications are vulnerable if they use spring-webmvc or spring-webflux and either register static resource handling (e.g., JS, CSS, images) or have an annotated controller returning a Resource. Spring Boot applications using spring-boot-starter-web or spring-boot-starter-webflux are vulnerable by default because they serve static resources out of the box [1].

Exploitation

The attacker requires only network access to the application and the ability to send HTTP requests to an endpoint that returns a static resource or a Resource object. No authentication is required if the resource endpoint is public. The attacker crafts an HTTP request with a Range header containing many byte-range sets, wide overlapping ranges, or both. The server processes these ranges, allocating memory to satisfy each sub-range, leading to rapid memory exhaustion. Tools like curl or any HTTP client can be used to send the malicious request [1][2].

Impact

Successful exploitation causes a denial of service (DoS) by exhausting server memory or CPU, potentially rendering the application unresponsive. The attack does not lead to information disclosure or remote code execution; the primary outcome is temporary unavailability of the service. The impact is limited to systems that satisfy the prerequisite configuration (static resource serving or Resource-returning controllers) [1].

Mitigation

The Spring team released fixes in versions 5.0.10 and 4.3.20 on October 10, 2018, and version 5.1.1 on November 16, 2018. Users should upgrade to the fixed versions immediately. Applications on unsupported 4.2.x branches must upgrade to a supported branch with the fix. No workaround is provided in the references for unpatched versions; blocking Range headers at the proxy or web server layer may reduce exposure but is not an official mitigation. The vulnerability is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog as of the publication date [1]