CVE-2026-47883

URL Redirect/Open Redirect
Affects
Spring Framework
in
Spring
No items found.
Versions
>=6.2.0 <=6.2.19, >=7.0.0 <=7.0.8
Exclamation circle icon
Patch Available

This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.

Overview

Spring Framework is a widely used application framework for the Java platform that provides the core programming and configuration model for modern Java enterprise applications, including the Spring MVC servlet web stack and the reactive Spring WebFlux web stack. Both web stacks ship an optional UrlHandlerFilter in the spring-web module that an application can register to handle requests whose path ends in a trailing slash, either by wrapping the request or by sending the client a redirect to the same path without the trailing slash.

An open redirect vulnerability (CVE-2026-47883) has been identified in UrlHandlerFilter, which allows attackers to redirect a victim's browser to an arbitrary external site. When the filter is configured to redirect and is registered with a very broadly matching pattern such as /**, a request whose path starts with two slashes, for example //attacker.example/, is answered with a redirect whose Location header repeats the path unchanged. A browser treats //attacker.example as a protocol-relative URL and navigates off-site, so a link that appears to point at the trusted application can be used for phishing. Both the Spring MVC (spring-webmvc) and Spring WebFlux (spring-webflux) variants of the filter are affected.

Per OWASP: Unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application 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.

The advisory rates this vulnerability Medium severity with the CVSS v3.1 vector AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N, which corresponds to a base score of 5.4. The attack vector is Network and no privileges are required, but user interaction is required because the victim has to follow the crafted link, and the Confidentiality and Integrity impacts are Low because the consequence is an off-site redirect that enables phishing or token leakage rather than direct compromise of the application.

This issue affects Spring Framework >=6.2.0 <=6.2.19 and >=7.0.0 <=7.0.8, including the End-of-Life 6.2.x line supported by NES for Spring Framework.

Details

Module Info

Vulnerability Info

This Medium-severity vulnerability is found in the spring-web package in multiple versions of Spring Framework, and is reached through the UrlHandlerFilter used by both spring-webmvc and spring-webflux applications. The filter is opt-in: an application builds it with one or more path patterns and chooses, per pattern, whether a request with a trailing slash is wrapped or redirected. The upstream advisory attributes the issue to spring-webmvc and spring-webflux because those are the two web stacks in which the filter is used; the vulnerable code itself is in the spring-web artifact.

When a redirect handler is configured, the servlet variant builds the redirect target directly from the raw request URI after trimming the trailing slash:

@Override
public void handleInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
        throws IOException {

    response.resetBuffer();
    response.setStatus(this.httpStatus.value());
    response.setHeader(HttpHeaders.LOCATION, trimTrailingSlash(request.getRequestURI()));
    response.flushBuffer();
}

The reactive variant does the same with the raw path of the ServerHttpRequest:

@Override
public Mono<Void> handleInternal(ServerWebExchange exchange, WebFilterChain chain) {
    ServerHttpResponse response = exchange.getResponse();
    response.setStatusCode(this.statusCode);
    response.getHeaders().set(HttpHeaders.LOCATION, trimTrailingSlash(exchange.getRequest()));
    return Mono.empty();
}

In both cases trimTrailingSlash only removes everything from the last / onward; nothing inspects the start of the path. A request for //attacker.example/ therefore matches a catch-all pattern such as /**, and the filter responds with Location: //attacker.example. Because the value begins with two slashes, the browser interprets it as a protocol-relative URL, keeps the current scheme, and navigates to attacker.example instead of a path on the original host. The redirect status is whatever the application configured, typically 308 Permanent Redirect, so the browser follows it without any prompt. Applications that register the filter only for narrow patterns such as /path/* are not exposed in this way, because the protocol-relative path does not match those patterns.

This vulnerability was introduced in 2024 with Spring Framework 6.2.0.

Steps To Reproduce

1. Add an affected version of spring-web to a project, for example 6.2.19, together with spring-context and spring-test for the filter's base class and the mock servlet classes, and build a UrlHandlerFilter that redirects on a catch-all pattern:

UrlHandlerFilter filter = UrlHandlerFilter
        .trailingSlashHandler("/**").redirect(HttpStatus.PERMANENT_REDIRECT)
        .build();

MockHttpServletRequest request = new MockHttpServletRequest("GET", "//attacker.example/");
MockHttpServletResponse response = new MockHttpServletResponse();

filter.doFilter(request, response, new MockFilterChain());
System.out.println(response.getStatus() + " " + response.getHeader(HttpHeaders.LOCATION));

2. Observe the output 308 //attacker.example. The Location header is protocol-relative, so a browser that receives this response leaves the application's origin for attacker.example.

3. Repeat the same call on a patched version, for example 7.0.9, and observe that the header is collapsed to /attacker.example, a path on the same origin.

4. Against a running application that registers the filter this way, the same effect is triggered by sending a victim a link of the form https://trusted.example//attacker.example/.

Mitigation

Only recent versions of Spring Framework receive community support. The 6.2.x line is End-of-Life and will not receive public updates to address this issue, so there is no publicly available fix for that line other than through a commercial support partner.

Applications that only need trailing-slash handling for specific paths can reduce their exposure by registering UrlHandlerFilter with narrow patterns instead of a catch-all such as /**, but upgrading remains the only complete fix.

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

  • Upgrade to a currently supported version of Spring Framework. The open-source fix ships in Spring Framework 7.0.9 on the 7.0.x line.
  • Leverage a commercial support partner like HeroDevs for post-EOL security support, which provides the fix for the 6.2.x line in nes-v6.2.21.

Credits

Vulnerability Details
Severity
Level
CVSS Assessment
Low
>=0 <4
Medium
>=4 <6
High
>=6 <8
Critical
>=8 <10
Medium
ID
CVE-2026-47883
PROJECT Affected
Spring Framework
Versions Affected
>=6.2.0 <=6.2.19, >=7.0.0 <=7.0.8
NES Versions Affected
Published date
August 27, 2026
≈ Fix date
August 25, 2026
Category
URL Redirect/Open Redirect
Vex Document
Download VEXHow do I use it?
Sign up for the latest vulnerability alerts fixed in
NES for Spring
Rss feed icon
Subscribe via RSS
or

By submitting the form I acknowledge receipt of our Privacy Policy.

Thanks for signing up for our Newsletter! We look forward to connecting with you.
Oops! Something went wrong while submitting the form.