Spring MVC and WebFlux applications are vulnerable to Denial of Service (DoS) attacks when resolving static resources.
Affected versions:
Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.
In plain language
Written by AI from the record
If your business uses Spring Framework versions 5.3.0–5.3.48, 6.1.0–6.1.27, 6.2.0–6.2.18, or 7.0.0–7.0.7 and is configured to resolve versioned static resources, attackers can send crafted web requests to make your app run out of resources and become unresponsive.
Unauthenticated Denial of Service is possible in Spring Framework via specially crafted requests that cause resource-intensive operations while resolving versioned static resources in Spring MVC/WebFlux; fixed versions are 7.0.7.1, 6.2.18.1, 6.1.28, and 5.3.49.
If you're affected
Service outage or app unresponsiveness
Increased CPU and memory usage
Slower response times for customers
Business operations disruption
What is it
This flaw lets a remote attacker bombard a Spring-based web app with specially crafted requests so the server spends too much effort processing “versioned” static files (like JavaScript, CSS, or web assets). Over time, that can overwhelm the server so the app becomes slow or stops responding, similar to how too many people hitting a busy website’s asset pages can cause the site to buckle.
Who is affected
This matters if your business runs a Spring Framework-based application (Spring MVC or WebFlux) that uses the affected version range and is configured to resolve versioned static resources. The attack does not require a login or any user action, meaning it can be attempted by anyone who can reach the application’s network endpoint. The findings do not confirm whether it’s reachable in default setups, so the practical risk depends on whether your application is set up to resolve versioned static resources and is exposed to the network.
How urgent is it
This is AMBER: it’s a denial-of-service risk where an attacker can send unauthenticated network requests that make the app consume excessive resources. Even without public exploit code or confirmed real-world incidents in the findings, it’s important to fix because DoS issues can directly cause downtime.
What to do — in detail
Confirm exposure in your app.
Identify the exact Spring Framework version(s) your deployment uses.
Confirm whether your Spring MVC or WebFlux setup resolves “versioned static resources.” (Look for configuration that enables versioned/static resource resolution rather than plain static assets.)
Compare your version to the affected ranges.
Affected: 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.
Upgrade to the fixed versions matching your branch.
7.0.x: upgrade to 7.0.7.1
6.2.x: upgrade to 6.2.18.1
6.1.x: upgrade to 6.1.28
5.3.x: upgrade to 5.3.49
Regression test what changed.
Verify static web assets still load correctly (especially any versioned URLs you rely on).
Watch application responsiveness under normal load after the upgrade.
If you cannot patch immediately.
Reduce exposure by ensuring the endpoints serving/handling versioned static resource resolution are not unnecessarily exposed to the public internet.
Consider temporarily disabling any “versioned static resources” feature/configuration if your business can operate without it, and document the risk until the upgrade is complete.
Monitor after changes.
Review logs for bursts of unusual requests to static-resource-related paths and watch for spikes in CPU/memory and request failures.
CISA KEV note: this CVE is not listed in CISA KEV in the provided findings.
Technical context
Severity is High (CVSS 7.5) and the issue is categorized as CWE-400 (Uncontrolled Resource Consumption). The mechanism is a Denial of Service caused by specially crafted network requests that trigger resource-intensive behavior during Spring MVC/WebFlux static resource version resolution. The findings specify affected version ranges: Spring Framework 7.0.0–7.0.7, 6.2.0–6.2.18, 6.1.0–6.1.27, and 5.3.0–5.3.48, with a configuration prerequisite that the application resolves versioned static resources. In the provided findings, there is no CISA KEV listing and no confirmed press claim of exploitation; there is also no public exploit code on record. An EPSS prediction exists but is not an exploitation confirmation (and is not used as proof here).
This is a general assessment based on public vulnerability data. It does not account for your specific infrastructure — when in doubt, consult a security specialist.
