MEDIUM 4.2

CVE-2026-41839: Spring Framework WebFlux Session Fixation Vulnerability

Spring Framework versions 5.3, 6.1, 6.2, and 7.0 contain a session management flaw in WebFlux applications. If an attacker first compromises a subdomain (through XSS or similar attack), they can trade a known session ID for one belonging to an authenticated user, potentially gaining unauthorized access to that user's account or data. The flaw requires two conditions: initial subdomain compromise and user interaction, which limits its immediate exploitability but remains a meaningful risk in multi-tenant or loosely-segmented environments.

Source data · NVD / CISA · public domain

CVSS
3.1 · 4.2 MEDIUM · CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N
Weaknesses (CWE)
CWE-384
Affected products
1 configuration(s)
Published / Modified
2026-06-09 / 2026-07-14

NVD description (verbatim)

A WebFlux application with a compromised subdomain (for example, compromised via cross-site scripting (XSS)) is vulnerable to an escalation attack exchanging a known session ID for that of an authenticated user. Affected versions: Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.

1 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

This vulnerability stems from improper session validation in Spring Framework's WebFlux reactive stack. The flaw allows session fixation attacks where an attacker who controls a compromised subdomain can exchange a predictable session identifier for a legitimate authenticated session. The issue is classified under CWE-384 (Session Fixation), indicating the framework does not properly invalidate or rotate session tokens when transitioning from an untrusted to a trusted context. The attack chain requires: (1) XSS or subdomain compromise to inject malicious content, (2) a victim visiting the attacker-controlled subdomain while authenticated, and (3) the framework accepting the session exchange without re-validation. This is distinct from traditional session hijacking because the attacker starts with a known, dummy session rather than attempting to predict or intercept an existing one.

Business impact

Successful exploitation could allow attackers to impersonate legitimate users within affected WebFlux applications. In customer-facing or multi-user systems, this translates to potential unauthorized access to sensitive data, transaction manipulation, or privilege escalation depending on the victim's role. The requirement for prior subdomain compromise and user interaction reduces the attack surface compared to unauthenticated remote code execution, but organizations running Spring Framework should still treat this as a priority given the widespread use of Spring in enterprise applications. Data breach, compliance violations, and reputational harm are plausible outcomes if systems process sensitive information.

Affected systems

VMware Spring Framework versions 5.3.0 through 5.3.48, 6.1.0 through 6.1.27, 6.2.0 through 6.2.18, and 7.0.0 through 7.0.7 are vulnerable. All four major version lines in current and recent support windows are impacted. Applications using Spring WebFlux for reactive web development are at risk; applications using the traditional Spring MVC servlet stack are not directly vulnerable. Verify your Spring Framework version in your build configuration (pom.xml, build.gradle, or equivalent) and confirm you are using WebFlux.

Exploitability

Exploitability is limited by prerequisite conditions. An attacker must first compromise a subdomain, typically via stored or reflected XSS, DNS hijacking, or misconfigured DNS records. They then must manipulate an authenticated user into visiting that compromised subdomain while logged into the target application. The CVSS 3.1 score of 4.2 (MEDIUM) reflects these constraints: network-accessible but high attack complexity, no privileges required, and user interaction mandatory. This is not a zero-click or zero-day-like scenario, but organizations with lax XSS protections or overly permissive subdomain handling should assess their specific risk.

Remediation

Upgrade Spring Framework to patched versions: 7.0.8 or later, 6.2.19 or later, 6.1.28 or later, or 5.3.49 or later—verify exact patch versions against the VMware Spring Framework security advisory. If immediate upgrade is not feasible, implement strict Content Security Policy (CSP) headers to prevent XSS in WebFlux applications, enforce HTTPS with Strict-Transport-Security (HSTS), and segregate subdomains with SameSite cookie attributes set to 'Strict' or 'Lax' rather than 'None'. Review and harden subdomain access controls and DNS configurations to reduce the likelihood of subdomain compromise.

Patch guidance

Prioritize patching development and testing environments first to validate application compatibility. Spring Framework patch releases are typically backward-compatible within a minor version line (e.g., 7.0.x to 7.0.8), so most applications should upgrade without code changes. Test thoroughly in staging before deploying to production, particularly for custom session management, authentication filters, or security configurations that may interact with the patched session handling. Consult the VMware Spring Framework release notes for each version line to confirm any breaking changes or migration steps.

Detection guidance

Monitor Spring Framework application logs for unusual session transitions or warnings related to session validation failures. Look for patterns of session IDs being exchanged or rotated unexpectedly. In access logs, identify requests originating from unexpected subdomains or referring to cross-subdomain navigation. Deploy intrusion detection signatures that flag session fixation attempts. Implement centralized logging and correlation rules to detect users with multiple concurrent sessions or rapid session changes. Additionally, monitor DNS and subdomain access logs for signs of subdomain compromise (unusual DNS queries, failed authentication attempts against subdomains, or traffic to non-existent subdomains).

Why prioritize this

Although the CVSS score is MEDIUM and the vulnerability is not yet in the CISA Known Exploited Vulnerabilities (KEV) catalog, the combination of broad version range impact (four major Spring versions), ubiquitous use of Spring Framework in enterprise applications, and the session-level nature of the vulnerability (authentication bypass) warrants prompt remediation. Organizations should schedule patching within 30 days, sooner if they operate multi-tenant or subdomain-heavy architectures or have elevated XSS risk due to user-generated content.

Risk score, explained

The CVSS 3.1 score of 4.2 reflects a network-accessible vulnerability with high attack complexity (requires prior subdomain compromise and user interaction). The impact is limited to confidentiality and integrity loss for a single user session—not system-wide. The absence of availability impact and the requirement for user interaction prevent a higher score. However, the real-world risk may feel higher in environments where XSS is common or where session tokens grant broad access; adjust your internal risk rating based on your attack surface and the sensitivity of data protected by these sessions.

Frequently asked questions

Does this vulnerability affect Spring MVC applications?

No. This vulnerability is specific to Spring WebFlux, the reactive web framework within Spring Framework. Traditional Spring MVC servlet-based applications are not affected. Confirm which framework you use by checking your application's configuration and dependencies.

What is a subdomain compromise, and how would an attacker achieve it?

A subdomain compromise typically occurs via reflected or stored XSS attacks where an attacker injects malicious JavaScript into a webpage served from a subdomain of your application. Other routes include DNS hijacking, misconfigured DNS records, or control of a subdomain that was previously abandoned but still trusted by your application. Implementing strict CSP, validating input, and maintaining clean DNS records mitigate these risks.

Are there any active exploits for this vulnerability?

As of the last update, this vulnerability is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, meaning no widespread active exploitation has been reported. However, this does not guarantee exploits do not exist; patch promptly rather than waiting for public exploit confirmation.

If I upgrade Spring Framework, do I need to invalidate existing user sessions?

It is a best practice to invalidate all active sessions after patching security vulnerabilities involving session handling. This prevents attackers from reusing compromised or fixed session tokens and ensures all users re-authenticate under the patched code path. Implement a session invalidation strategy (e.g., clearing session store, rotating session tokens) as part of your deployment plan.

This analysis is based on information available as of the publication date. CVE details, patch versions, and CVSS scores are subject to revision by VMware and security databases. Organizations should verify patch version numbers and compatibility against official VMware Spring Framework security advisories before deployment. This document is for informational purposes and does not constitute professional security advice; engage qualified security professionals for assessment and remediation planning specific to your environment. Source: NVD (public-domain), retrieved 2026-07-15. Analysis generated by SEC.co (claude-haiku-4-5).