Vulnerability Directory | CVE-2026-41706

Overview

Spring Security is the de facto standard framework for authentication and authorization in Spring-based applications, providing the filter chains, login flows, and access-control infrastructure that protect Servlet and reactive web applications.

A medium-severity vulnerability (CVE-2026-41706) has been identified in Spring Security. The CookieRequestCache (Servlet) and CookieServerRequestCache (WebFlux) implementations of the RequestCache contract store the URL of the request that triggered authentication in a browser cookie named REDIRECT_URI, so that the user can be returned to their intended destination after logging in. In affected versions, the full absolute URL, including scheme, host, and port, is stored in the cookie and is used without validation as the post-login redirect target. An attacker who can influence the value of the REDIRECT_URI cookie, for example through cookie injection via a related subdomain, an HTTP response splitting attack, or a protocol downgrade from HTTPS to HTTP, can cause an authenticated user to be redirected to an attacker-controlled URL immediately after a successful login, enabling convincing phishing attacks.

Per OWASP, unvalidated redirects and forwards occur "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."

This issue affects versions >=5.4.0 <=5.5.8, >=5.7.0 <=5.7.23, >=5.8.0 <=5.8.25, >=6.2.0 <=6.2.8, >=6.3.0 <=6.3.16, >=6.4.0 <=6.4.16, >=6.5.0 <=6.5.10, and >=7.0.0 <=7.0.5, as well as older, unsupported versions, of Spring Security.

‍

Details

Module Info

Product: Spring Security
Affected packages: spring-security-web
Affected versions: >=5.4.0 <=5.5.8, >=5.7.0 <=5.7.23, >=5.8.0 <=5.8.25, >=6.2.0 <=6.2.8, >=6.3.0 <=6.3.16, >=6.4.0 <=6.4.16, >=6.5.0 <=6.5.10, >=7.0.0 <=7.0.5
GitHub repository: https://github.com/spring-projects/spring-security
Published packages: https://central.sonatype.com/artifact/org.springframework.security/spring-security-web
Package manager: Maven
Fixed in:
NES for Spring Security 5.5.x, 5.7.x, 5.8.x, 6.2.x, 6.3.x, 6.4.x
Spring Security 6.5.11, 7.0.6 (OSS)

Vulnerability Info

Spring Security applications that want to avoid server-side session state can configure CookieRequestCache (Servlet stack) or CookieServerRequestCache (reactive stack) as their RequestCache. When an unauthenticated user requests a protected page, the cache saves that request so the login flow can redirect the user back to it afterwards. The cookie-based implementations persist this saved request in a Base64-encoded browser cookie named REDIRECT_URI.

On the Servlet side, CookieRequestCache.saveRequest() wrote the complete absolute URL of the original request into the cookie:

@Override
public void saveRequest(HttpServletRequest request, HttpServletResponse response) {
    if (!this.requestMatcher.matches(request)) {
        this.logger.debug("Request not saved as configured RequestMatcher did not match");
        return;
    }
    String redirectUrl = UrlUtils.buildFullRequestUrl(request);
    Cookie savedCookie = new Cookie(COOKIE_NAME, encodeCookie(redirectUrl));
    ...
}

After a successful login, getRequest() decoded the cookie and rebuilt the saved request directly from whatever the cookie contained, trusting its scheme, host, and port as the redirect destination:

UriComponents uriComponents = UriComponentsBuilder.fromUriString(originalURI).build();
DefaultSavedRequest.Builder builder = new DefaultSavedRequest.Builder();
int port = getPort(uriComponents);
return builder.setScheme(uriComponents.getScheme())
        .setServerName(uriComponents.getHost())
        .setRequestURI(uriComponents.getPath())
        .setQueryString(uriComponents.getQuery())
        .setServerPort(port)
        ...

The reactive CookieServerRequestCache.getRedirectUri() likewise mapped the decoded cookie value straight to a URI with no check that it referred to the current application. Because browsers attach cookies based on domain and path rather than on which server set them, the cookie value is not trustworthy: a malicious or compromised related subdomain can set a REDIRECT_URI cookie for the parent domain, and HTTP response splitting or an HTTPS to HTTP downgrade can achieve the same result. An attacker who plants a cookie containing an absolute URL such as https://evil.example/phishing causes the victim to be redirected there immediately after they authenticate, at the exact moment they most trust the application. The remediation stores only the relative path and query string in the cookie, rejects any saved value that is not a relative path (including protocol-relative //host forms), and rebuilds the redirect target from the current request's own scheme, host, and port.

‍

Mitigation

Spring Security 6.5.x and 7.0.x receive the fix in the open-source releases 6.5.11 and 7.0.6; the 5.7.x, 5.8.x, 6.3.x, and 6.4.x lines, along with older lines such as 5.5.x and 6.2.x, are past their open-source support window and have no publicly available fix. Users still running an affected open-source line that no longer receives free updates should not attempt to hand-patch the saved-request handling.

To remediate this issue, affected users have two recommended options:

Upgrade to a supported, fixed release of Spring Security (6.5.11 or 7.0.6).
Adopt HeroDevs Never-Ending Support (NES) for Spring Security, which provides a drop-in compatible build with this vulnerability fixed for release lines that are otherwise end-of-life, with no code changes required. Learn more about HeroDevs Never-Ending Support for Spring Security and request coverage at https://www.herodevs.com/support/spring-nes

‍