Vulnerability Directory | CVE-2026-41844

Overview

Spring Framework is the foundational application framework for the Java platform, providing the core inversion-of-control container along with the Spring MVC (servlet-based) and Spring WebFlux (reactive) web stacks. Both web stacks support view resolution, where a controller returns a logical view name that a ViewResolver turns into a rendered response. When a controller does not return an explicit view name, Spring derives a default view name from the incoming request path: DefaultRequestToViewNameTranslator does this in Spring MVC and ViewResolutionResultHandler does this in Spring WebFlux.

A medium-severity vulnerability (CVE-2026-41844) has been identified in that default view-name resolution. Spring's UrlBasedViewResolver treats the special redirect: prefix in a view name as an instruction to issue an HTTP redirect, and the forward: prefix (Spring MVC only) as an instruction to perform an internal RequestDispatcher forward. Because the default view name is derived verbatim from the request path, an application that maps a wildcard path such as /** to a handler that does not specify an explicit view name will translate a request path beginning with redirect: followed by an external URL into a redirect view. The resolver then issues a 302 redirect to the attacker-controlled external host. A victim who follows a crafted link is silently redirected off-site, which enables phishing and credential-harvesting attacks. In Spring MVC the same path-to-view-name translation also honors the forward: prefix, allowing an attacker to coerce an internal forward to an unintended server-side resource.

Per OWASP, unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause it to redirect the request to a URL contained within untrusted input; by modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. That is precisely the failure mode here: the untrusted request path flows unvalidated into the view name that drives redirect: and forward: handling.

The CVSS v3.1 base score for this vulnerability is 4.2 (Medium) with vector AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N. The attack vector is Network, attack complexity is High because exploitation requires the application to use a wildcard mapping with no explicit view name, no privileges are required, and User Interaction is Required because a victim must follow the crafted link. The scope is Unchanged, and the confidentiality and integrity impacts are Low (an off-site redirect or an unintended internal forward); there is no availability impact.

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.

‍

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
Package manager: Maven
Fixed in:
NES for Spring Framework 5.3.x, 6.1.x
Spring Framework 7.0.8, 6.2.19 (OSS)

Vulnerability Info

The vulnerability is in the default view-name resolution that Spring performs when a controller does not return an explicit view name. In Spring MVC this is DefaultRequestToViewNameTranslator.getViewName(HttpServletRequest) in the spring-webmvc module; in Spring WebFlux it is ViewResolutionResultHandler.getDefaultViewName(ServerWebExchange) in the spring-webflux module. Both build the view name directly from the request path and then hand it to a UrlBasedViewResolver, which interprets the redirect: and (for MVC) forward: prefixes as redirect and forward instructions respectively.

Pre-fix, the Spring MVC translator returned the path-derived view name with no inspection of its prefix:‍

@Override
public String getViewName(HttpServletRequest request) {
    String path = ServletRequestPathUtils.getCachedPathValue(request);
    return (this.prefix + transformPath(path) + this.suffix);
}

‍The Spring WebFlux handler likewise derived the default view name from the request path with no prefix check:

private String getDefaultViewName(ServerWebExchange exchange) {
    String path = exchange.getRequest().getPath().pathWithinApplication().value();
    if (path.startsWith("/")) {
        path = path.substring(1);
    }
    if (path.endsWith("/")) {
        path = path.substring(0, path.length() - 1);
    }
    return StringUtils.stripFilenameExtension(path);
}

‍

When such a handler is reached through a wildcard mapping like /**, the attacker controls the path, and therefore controls the prefix of the resulting view name. A request whose path is redirect: followed by an external URL produces a view name with that same redirect: prefix, which UrlBasedViewResolver resolves to a RedirectView and emits as a 302 to the external host. In Spring MVC a request whose path begins with forward: similarly produces a server-side forward to an unintended resource.

The default view-name translation behavior predates the advisory's listed range. DefaultRequestToViewNameTranslator has existed since Spring 2.0 and ViewResolutionResultHandler since Spring 5.0, and both derived the default view name from the request path without prefix validation throughout. The advisory's listed floor of 5.3.0 reflects Spring's currently-supported scope; older lines, including the lines covered by NES support, are also affected through the same Spring MVC code path.

‍

Steps To Reproduce

1. Build a Spring MVC (or Spring WebFlux) application on an affected version (for example Spring Framework 5.3.48) with a controller mapped to a wildcard path that returns no explicit view name:

   @Controller
   public class CatchAllController {

       @GetMapping("/**")
       public void handle() {
           // no explicit view name: the framework derives one from the request path
       }
   }

‍

2. Configure a UrlBasedViewResolver (or any subclass, such as InternalResourceViewResolver or ThymeleafViewResolver) so that view names are resolved through the standard view-resolution chain. This is the default in typical Spring MVC and WebFlux setups.

3. Send a request whose path begins with the redirect: prefix:

   GET /redirect:https://attacker.example/ HTTP/1.1
   Host: victim.example

4. Observe that the application responds with a 302 redirect (a Location header pointing at the attacker-controlled host):

 HTTP/1.1 302 Found
   Location: https://attacker.example/

5. For Spring MVC, repeat with a forward: prefix (for example GET /forward:/WEB-INF/internal-page) and observe that the request is forwarded internally to the named resource.

6. After upgrading to a fixed version (Spring Framework 6.2.19 or 7.0.8), repeat steps 3 through 5. The application now responds with HTTP 400 (Bad Request) and a message rejecting the path that carries a redirect: or forward: prefix, and no redirect or forward is performed.

‍

Mitigation

Only recent versions of Spring Framework receive community support and updates. For this vulnerability there is no public open-source fix for the 5.3.x or 6.1.x lines: the open-source fixes ship only in Spring Framework 6.2.19 and 7.0.8. The 5.3.x line in particular is past its open-source end-of-life and will not receive further community updates.

Users of the affected components should apply one of the following mitigations:

Upgrade to a currently supported open-source version of Spring Framework. The open-source fix ships in Spring Framework 6.2.19 (6.2.x line) and 7.0.8 (7.0.x line).
As an interim hardening step on a vulnerable deployment, avoid wildcard handler mappings (/**) that fall through to default view-name resolution, and ensure controllers return explicit, application-controlled view names rather than relying on path-derived defaults. Front the application with a proxy or filter that rejects request paths containing a redirect: or forward: segment.
Leverage a commercial support partner like HeroDevs for post-EOL security support through Never-Ending Support (NES) for Spring Framework.

‍