CVE-2026-47889

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 reactive Spring WebFlux web stack. WebFlux runs on top of pluggable server adapters in the spring-web module, and one of those adapters, JettyCoreHttpHandlerAdapter, lets a WebFlux application run directly on the Jetty 12 Core Handler API without the Servlet layer.

An information exposure vulnerability (CVE-2026-47889) has been identified in JettyCoreServerHttpResponse, which allows attackers to have a victim's browser attach the application's cookies to cross-site requests that the application intended to exclude. When a WebFlux application is served through the Jetty 12 Core reactive adapter, every Set-Cookie header is written without the SameSite attribute, even when the application set one. This includes the SESSION cookie issued by Spring's own CookieWebSessionIdResolver, which is configured with SameSite=Lax by default, so the cross-site request protection the application believed it had for its session cookie is silently absent.

Per CWE: the SameSite attribute for sensitive cookies is not set, or an insecure value is used.

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:N/A:N, which corresponds to a base score of 4.3. The attack vector is Network and no privileges are required because the attacker only needs to host a page that makes cross-site requests to the application, user interaction is Required because the victim has to visit that page while logged in, and the Confidentiality impact is Low because the consequence is that cookies the application marked as same-site are sent along with cross-site requests rather than direct access to data inside 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

• Product: Spring Framework
• Affected packages: org.springframework:spring-web
• Affected versions: >=6.2.0 <=6.2.19, >=7.0.0 <=7.0.8
• GitHub repository: https://github.com/spring-projects/spring-framework
• Published packages: https://central.sonatype.com/artifact/org.springframework/spring-web
• Package manager: Maven
• Fixed in:
  
  • NES for Spring Framework nes-v6.2.21
  • Spring Framework 7.0.9 (OSS)

Vulnerability Info

This Medium-severity vulnerability is found in the spring-web package in multiple versions of Spring Framework, and is reached only by WebFlux applications that run on the Jetty 12 Core reactive adapter (JettyCoreHttpHandlerAdapter), not by applications that use the Servlet-based JettyHttpHandlerAdapter. Spring Boot does not auto-configure the Jetty Core adapter, so the affected deployments are those that wire it up themselves or through a third-party starter.

When the response is committed, JettyCoreServerHttpResponse.applyCookies hands every ResponseCookie to Jetty wrapped in the adapter's own ResponseHttpCookie, and Jetty serializes the Set-Cookie header from that wrapper:

@Override
protected void applyCookies() {
    getCookies().values().stream()
            .flatMap(List::stream)
            .forEach(cookie -> Response.addCookie(this.response, new ResponseHttpCookie(cookie)));
}

The wrapper forwards the name, value, domain, path, max-age, Secure, HttpOnly, and Partitioned settings of the Spring cookie, but its getSameSite() method never consults the ResponseCookie at all:

private static class ResponseHttpCookie implements org.eclipse.jetty.http.HttpCookie {

    private final ResponseCookie responseCookie;

    // ...

    @Nullable
    @Override
    public SameSite getSameSite() {
        // Adding non-null return site breaks tests.
        return null;
    }
}

Jetty only appends ;SameSite=... to the header when the wrapper returns a non-null value, so the attribute is dropped for every cookie regardless of what the application passed to ResponseCookie.from(...).sameSite(...). Nothing the application can do through the Spring API restores it, because the value is discarded after the point where it was set. The incoming direction is not affected: Set-Cookie fields that already exist on the Jetty response are converted back into ResponseCookie objects with their SameSite value intact, so only cookies written by the application are exposed.

The practical effect is that browsers fall back to their own default handling for the affected cookies. A cross-site page can then cause the victim's browser to include the session cookie on cross-site top-level navigations, and on browsers that do not apply a Lax default, on cross-site sub-requests as well. Applications that rely on SameSite=Lax or SameSite=Strict as their defense against cross-site request forgery are therefore running without it.

This vulnerability was introduced in 2024 with Spring Framework 6.2.0.

‍

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 cannot upgrade immediately can set the Jetty context attribute org.eclipse.jetty.cookie.sameSiteDefault (for example to Lax) so that Jetty itself supplies a SameSite value for cookies that arrive without one. This applies a single value to every cookie the application writes and does not restore per-cookie settings, so 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

• No public finder credit is listed in the advisory sources checked for this entry.