CVE-2026-41842
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
Spring Framework is a widely used application framework and inversion-of-control container for the Java platform, providing the Spring MVC and Spring WebFlux web stacks used to build server-side web applications and REST services. Both web stacks can serve static resources (CSS, JavaScript, images) through a configurable resource-resolver chain, and they support versioned resources: a strategy in which a content hash or fixed version string is embedded in the resource URL (for example css/main-e36d2e05253c6c7085a91522ce43a0b4.css) so the asset can be cached far in the future and only re-fetched when its content, and therefore its URL, changes. The component that maps a versioned request URL back to the underlying file is VersionResourceResolver.
A high-severity vulnerability (CVE-2026-41842) has been identified in the versioned-resource handling of Spring MVC and Spring WebFlux. When an application is configured to serve static resources with versioned resources enabled, an attacker can send specially crafted requests that are slow to resolve, forcing the resolver into expensive lookup work on each request and potentially leading to a Denial of Service in the application.
Per OWASP, a Denial of Service attack is meant to deny legitimate users access to a resource such as a website, network, or email, or to make it extremely slow, and is usually implemented by hitting the target resource such as a web server with too many requests at the same time. A request that is individually slow to resolve amplifies this effect: each malicious request occupies a request-handling thread or connection for an extended period, so a modest volume of crafted requests can exhaust the server's capacity to serve legitimate traffic.
This issue affects Spring Framework >=4.3.0 <=4.3.30, >=5.3.0 <=5.3.48, >=6.1.0 <=6.1.27, >=6.2.0 <=6.2.18, and >=7.0.0 <=7.0.7. The versioned-resource resolver has existed since Spring Framework 4.1, so older unsupported lines that predate the advisory's listed range are also affected.
Details
Module Info
- Product: Spring Framework
- Affected packages: spring-webmvc, spring-webflux
- Affected versions: >=4.3.0 <=4.3.30, >=5.3.0 <=5.3.48, >=6.1.0 <=6.1.27, >=6.2.0 <=6.2.18, >=7.0.0 <=7.0.7
- GitHub repository: https://github.com/spring-projects/spring-framework
- Published packages: https://central.sonatype.com/artifact/org.springframework/spring-webmvc, https://central.sonatype.com/artifact/org.springframework/spring-webflux
- Package manager: Maven
- Fixed in:
- NES for Spring Framework 6.1.x, 5.3.x, 4.3.x
- Spring Framework 6.2.19, 7.0.8 (OSS)
Vulnerability Info
The vulnerability is in VersionResourceResolver, present in both the spring-webmvc (Spring MVC) and spring-webflux (Spring WebFlux) modules. The fix is related to CVE-2026-41843. This resolver participates in the static-resource resolver chain whenever an application enables versioned resources, for example by registering a resource handler with a resolver chain and a content version strategy:
registry.addResourceHandler("/resources/**")
.addResourceLocations("classpath:/static/")
.resourceChain(true)
.addResolver(new VersionResourceResolver().addContentVersionStrategy("/**"));
On a cache miss, the resolver's internal resolution method extracts a candidate version from the incoming request path, strips that version to produce a simplePath, and then asks the rest of the resolver chain to resolve simplePath against the configured resource locations. That chain reaches PathResourceResolver, which performs real filesystem resolution. Pre-fix, the derived simplePath was passed straight into the chain with no validity check:
String candidateVersion = versionStrategy.extractVersion(requestPath);
if (!StringUtils.hasLength(candidateVersion)) {
return null;
}
String simplePath = versionStrategy.removeVersion(requestPath, candidateVersion);
Resource baseResource = chain.resolveResource(request, simplePath, locations);
if (baseResource == null) {
return null;
}
The root cause is that the derived simplePath was handed to the resolver chain unconditionally, with no validity check between version stripping and filesystem resolution. An attacker who knows the versioned-resource URL shape can craft request paths whose stripped form is empty, blank, or otherwise invalid yet still flows into PathResourceResolver's filesystem resolution and path-normalization work on every request. Because each such request occupies a request-handling thread or connection while doing this work, a flood of them exhausts the server's capacity and produces a Denial of Service. The fix short-circuits empty or invalid derived paths before that costly resolution:
String simplePath = versionStrategy.removeVersion(requestPath, candidateVersion);
if (ResourceHandlerUtils.shouldIgnoreInputPath(simplePath)) {
return null; // short-circuit empty/invalid derived paths before costly resolution
}
Resource baseResource = chain.resolveResource(request, simplePath, locations);
A companion change in the same commit makes version stripping remove only the trailing version token (lastIndexOf) rather than every occurrence; that hardens path integrity but is not itself the DoS fix. The CVSS vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H reflects this: the impact is availability-only (the resolution path consumes resources but does not disclose or modify data), the attack is remote and unauthenticated, and complexity is low.
Mitigation
Spring Framework 4.3.x, 5.3.x, and 6.1.x have reached the end of their open source support lifecycle and will not receive open source patches for this vulnerability; see the Spring support policy for current support timelines.
Users of the affected components should apply one of the following mitigations:
- Upgrade to a currently supported version of Spring Framework that contains the fix. The OSS fix ships in Spring Framework 6.2.19 (6.2.x line) and 7.0.8 (7.0.x line).
- For the open source end-of-life lines (4.3.x, 5.3.x, and 6.1.x), leverage a commercial support partner like HeroDevs for post-EOL security support through Never-Ending Support (NES) for Spring Framework.
