CVE-2026-41839

What it actually does

This is a session-confusion/session-fixation style authentication weakness in Spring Framework WebFlux applications. If an attacker controls or compromises a related subdomain, such as through XSS, and session cookies are scoped in a way that allows interaction across subdomains, the attacker may be able to cause a victim to use a session identifier already known to the attacker and later exchange or associate that known session with the victim’s authenticated session. Successful exploitation can allow limited unauthorized access to the victim’s authenticated context, affecting confidentiality and integrity, but it requires user interaction and a prerequisite compromise of a subdomain or equivalent client-side foothold.

Why it matters to the business

An attacker who first compromises a related subdomain could potentially hijack authenticated user sessions in affected WebFlux applications, leading to unauthorized access to user data or actions performed as the victim. The CVSS score is moderate, EPSS is very low and stable, there is no known CISA KEV listing, no ransomware association, and no reported exploit maturity in the provided data, so broad exploitation risk appears low; however, internet-facing applications with shared parent-domain cookies or weak subdomain isolation should still prioritize remediation because session hijacking can directly affect user trust and account security.

How an attack unfolds

An attacker first obtains control of script execution on a subdomain trusted by the same parent domain as the target WebFlux application, commonly through XSS or subdomain compromise. From that position, the attacker manipulates the victim’s browser into using a session identifier already known to the attacker, typically by abusing cookie scope, browser behavior, or shared domain assumptions. The victim then visits or authenticates to the vulnerable WebFlux application while carrying the attacker-known session identifier. Due to the vulnerable session handling behavior, the authenticated state can become associated with that known session, allowing the attacker to reuse or exchange the session identifier to access some of the victim’s authenticated application context. The attack is not a simple unauthenticated remote exploit: it requires a compromised subdomain or client-side foothold and user interaction.

How to fix it

Upgrade Spring Framework to a fixed release outside the affected ranges. The affected branches are 7.0.0 through 7.0.7, 6.2.0 through 6.2.18, 6.1.0 through 6.1.27, and 5.3.0 through 5.3.48; use the vendor-advised patched maintenance release for the branch in use or a later supported version. In addition, reduce exploitability by avoiding parent-domain-wide session cookies unless strictly required, setting cookies with tight host-only scope where possible, using Secure, HttpOnly, and SameSite attributes, rotating the session identifier immediately after authentication, invalidating pre-authentication sessions on login, isolating untrusted subdomains from authenticated application domains, fixing XSS across all related subdomains, removing dangling DNS records, and enforcing strong Content Security Policy on applications sharing a parent domain.

How to confirm the fix worked

Confirm exposure by inventorying applications that use Spring WebFlux and checking the resolved Spring Framework versions in build manifests and runtime dependency output. Maven users should inspect dependency trees for org.springframework:spring-webflux, org.springframework:spring-web, and spring-core versions; Gradle users should inspect dependencyInsight output for Spring Framework modules. Any application resolving Spring Framework 7.0.0-7.0.7, 6.2.0-6.2.18, 6.1.0-6.1.27, or 5.3.0-5.3.48 should be treated as affected unless the vendor has documented an equivalent backport. After upgrading, verify that the runtime classpath no longer contains affected Spring Framework versions. Also validate cookie behavior in a browser or proxy: session cookies should not be unnecessarily scoped to a parent domain, should be Secure and HttpOnly, and authentication should issue a new session identifier rather than preserving a pre-authentication identifier.

Typical attack path

1. Identify a Spring WebFlux application running an affected Spring Framework version: 7.0.0-7.0.7, 6.2.0-6.2.18, 6.1.0-6.1.27, or 5.3.0-5.3.48.
2. Find or compromise a related subdomain that can influence the victim’s browser, for example through XSS, stale DNS, abandoned hosting, or weak subdomain controls.
3. Determine whether session cookies are scoped broadly enough across the parent domain or otherwise usable in a cross-subdomain session interaction.
4. Cause a targeted authenticated user to visit the compromised subdomain or attacker-controlled content.
5. Set, inject, or induce use of a session identifier known to the attacker in the victim’s browser.
6. Wait for the victim to authenticate to or access the vulnerable WebFlux application using that session context.
7. Reuse or exchange the known session identifier to access the victim’s authenticated session context.
8. Perform limited unauthorized reads or actions as the victim, depending on application authorization controls and session handling.

How to detect it

Investigate whether exploitation has already occurred by correlating web access logs, reverse proxy logs, application authentication logs, session-store audit records, WAF logs, DNS/subdomain inventory changes, CSP violation reports, and XSS reports from related subdomains. Look for the same session identifier appearing before and after authentication, the same session identifier used by different source IP addresses or user agents, a session changing from anonymous to authenticated without expected session rotation, login events preceded by visits to compromised or unusual subdomains, and authenticated requests that begin immediately after a suspicious cookie-setting event. Also review evidence of prerequisite compromise: XSS payloads on sibling subdomains, unexpected JavaScript changes, dangling CNAME takeover, unusual Set-Cookie headers from subdomains, and parent-domain scoped session cookies. There are no public exploit-specific payload strings in the provided data, so detection should focus on behavioral session anomalies and subdomain compromise indicators rather than a single signature.

• Set-Cookie: SESSION=
• Cookie: SESSION=
• Domain=.
• SameSite=None
• org.springframework:spring-webflux:7.0.0
• org.springframework:spring-webflux:7.0.1
• org.springframework:spring-webflux:7.0.2
• org.springframework:spring-webflux:7.0.3
• org.springframework:spring-webflux:7.0.4
• org.springframework:spring-webflux:7.0.5
• org.springframework:spring-webflux:7.0.6
• org.springframework:spring-webflux:7.0.7
• org.springframework:spring-webflux:6.2.0
• org.springframework:spring-webflux:6.2.18
• org.springframework:spring-webflux:6.1.0
• org.springframework:spring-webflux:6.1.27
• org.springframework:spring-webflux:5.3.0
• org.springframework:spring-webflux:5.3.48

What your security team should do

• Patch affected Spring Framework WebFlux applications to vendor-fixed versions or later supported releases, prioritizing internet-facing applications and applications sharing cookies across subdomains.
• Inventory subdomains under the same parent domains as authenticated WebFlux applications and remediate XSS, dangling DNS, abandoned cloud resources, and weak hosting controls.
• Review session cookie configuration and remove unnecessary Domain attributes that allow parent-domain or cross-subdomain cookie scope.
• Require session identifier rotation after login and invalidate anonymous or pre-authentication sessions when authentication succeeds.
• Search authentication and access logs for evidence of session identifiers reused across different IP addresses, user agents, geographies, or identities around login events.
• Harden browser-facing controls with HttpOnly, Secure, SameSite, HSTS, and Content Security Policy where compatible with application requirements.
• Because this issue is not KEV-listed, has very low EPSS, and has no known exploit maturity in the provided data, handle as a targeted-risk patch rather than an emergency mass-exploitation event unless local telemetry shows suspicious session activity.