Introduction
A missing Origin validation check in Spring for GraphQL's WebSocket transport means that any authenticated user who visits a malicious webpage can have their entire GraphQL session silently hijacked, allowing an attacker to run arbitrary queries and mutations under the victim's identity. Published on June 11, 2026 as part of what has been called the largest coordinated Spring security update in the framework's 23 year history, CVE-2026-41700 carries a CVSS 8.1 (HIGH) score and affects every major version line of Spring for GraphQL from 1.0.0 through 2.0.3.
Spring for GraphQL is the official Spring integration for GraphQL Java, a joint collaboration between the GraphQL Java team and Spring engineering. It is the primary recommended path for building GraphQL services in the Spring ecosystem, which means this vulnerability has broad potential reach across enterprise Java deployments worldwide.
Technical Information
Root Cause: Missing Origin Validation on WebSocket Handshake
At its core, CVE-2026-41700 is a Cross-Site WebSocket Hijacking (CSWSH) vulnerability. The weakness is formally classified as CWE-346 (Origin Validation Error) and more specifically CWE-1385 (Missing Origin Validation in WebSockets). CWE-1385 addresses the scenario where "the product uses a WebSocket, but it does not properly verify that the source of data or communication is valid."
When a browser initiates a WebSocket connection, it automatically includes the user's cookies for the target domain in the HTTP upgrade (handshake) request. This is a fundamental property of the browser WebSocket API: unlike regular HTTP requests made via fetch or XMLHttpRequest, the WebSocket constructor does not allow custom headers to be set during the handshake. The browser does, however, send an Origin header indicating which site initiated the connection.
The vulnerability exists because Spring for GraphQL does not validate this Origin header during the WebSocket handshake. Any webpage, regardless of its origin, can open a WebSocket connection to the GraphQL endpoint, and the server will accept it as legitimate.
CVSS Breakdown
The CVSS v3.1 vector is AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N, which breaks down as follows:
| Component | Value | Meaning |
|---|---|---|
| Attack Vector | Network | Exploitable remotely |
| Attack Complexity | Low | No special conditions beyond the three prerequisites |
| Privileges Required | None | Attacker needs no authentication |
| User Interaction | Required | Victim must visit a malicious page |
| Scope | Unchanged | Impact confined to the vulnerable component |
| Confidentiality | High | Full information disclosure possible |
| Integrity | High | Full integrity compromise possible |
| Availability | None | No direct availability impact |
The C:H and I:H ratings mean an attacker can read any data the authenticated user can access and execute any GraphQL operations the user is authorized to perform.
Three Prerequisites for Exploitation
The Spring advisory specifies that an application is vulnerable only when all three of the following conditions are true:
-
The application has enabled the GraphQL WebSocket transport. Spring for GraphQL supports both HTTP and WebSocket transports; only deployments using the WebSocket endpoint are affected.
-
The application relies on cookie-based session authentication. If authentication uses a mechanism that is not automatically included by the browser (such as an Authorization header with a bearer token), the cross-origin WebSocket handshake will not carry valid credentials.
-
Custom Spring Security WebSocket-level Origin enforcement is not configured. Spring Security provides mechanisms for Origin validation on WebSocket connections, but they are not enabled by default for the GraphQL WebSocket transport.
Attack Flow
The exploitation sequence proceeds through five stages:
-
Attacker prepares a malicious webpage. The page contains JavaScript that opens a WebSocket connection to the target Spring for GraphQL WebSocket endpoint (for example,
wss://target-app.example.com/graphql). -
Victim is lured to the malicious page. This can happen through phishing emails, social engineering, malicious advertisements, or cross-site scripting on an unrelated domain. The only requirement is that the victim has an active authenticated session with the target application.
-
Browser sends the WebSocket handshake with cookies. When the malicious JavaScript calls
new WebSocket('wss://target-app.example.com/graphql'), the browser automatically attaches the victim's session cookies fortarget-app.example.comto the HTTP upgrade request. -
Server accepts the cross-origin handshake. Because Spring for GraphQL does not validate the Origin header, the server sees valid session cookies and establishes the WebSocket connection as if it were a legitimate request from the authenticated user.
-
Attacker executes arbitrary GraphQL operations. Through the established WebSocket, the attacker's JavaScript can send GraphQL queries, mutations, and subscription requests. All operations execute with the victim's full authorization context. Data returned by the server flows back to the attacker's page.
As PortSwigger's documentation explains, "Cross-site WebSocket hijacking involves a cross-site request forgery vulnerability on a WebSocket handshake. It arises when the WebSocket handshake request relies solely on HTTP cookies for session handling."
Why This Is Not Mitigated by Standard CSRF Protections
Standard CSRF protections (such as anti-CSRF tokens in forms or the SameSite cookie attribute) do not automatically protect WebSocket handshakes. The WebSocket API does not support custom headers during the handshake, so token-based CSRF defenses that rely on custom request headers cannot be applied in the same way they are for regular HTTP requests. The SecureFlag knowledge base notes that "the usual CSRF prevention may be implemented for the endpoint that serves the WebSocket (e.g., introducing a CSRF token)" but this requires explicit implementation, which was absent in the affected Spring for GraphQL versions.
Spring Security does support CSRF tokens for STOMP-based WebSocket connections (where "by default, Spring Security requires the CSRF token in any CONNECT message type"), but this protection was not extended to the GraphQL WebSocket transport.
Affected Systems and Versions
Four major version lines of Spring for GraphQL are affected:
| Version Line | Affected Range | Fixed Version | Availability |
|---|---|---|---|
| 2.0.x | 2.0.0 through 2.0.3 | 2.0.4 | Open source |
| 1.4.x | 1.4.0 through 1.4.5 | 1.4.6 | Open source |
| 1.3.x | 1.3.0 through 1.3.8 | 1.3.9 | Commercial (Enterprise support only) |
| 1.0.x | 1.0.0 through 1.0.6 | 1.0.7 | Commercial (Enterprise support only) |
This spans the entire release history of Spring for GraphQL. Unsupported versions are also considered affected.
Vulnerable configuration requirements: An application is only exploitable if it (1) has enabled the GraphQL WebSocket transport, (2) uses cookie-based session authentication, and (3) has not configured custom Spring Security WebSocket-level Origin enforcement. Applications using token-based authentication (such as bearer tokens in Authorization headers) or that have already implemented Origin validation are not vulnerable.
Vendor Security History
Spring has experienced notable security vulnerabilities in the past, most prominently Spring4Shell (CVE-2022-22965), which enabled remote code execution and was widely exploited. VMware published guidance on hunting for Spring4Shell and Java Spring vulnerabilities in 2022.
The current CVE was released alongside multiple other security fixes as part of what Techzine described as "the largest Spring security update ever" in the framework's 23 year history. The coordinated release also addressed CVE-2026-41699 (unsafe deserialization with RCE potential), CVE-2026-41856 (annotation detection weaknesses), CVE-2026-41843 (path traversal), and CVE-2026-22752 (authorization server issues).
Broadcom's simultaneous announcement of expanded security investment, including SLSA Level 3 supply chain integrity and day zero patch availability for Enterprise customers, signals a systematic security review of the Spring portfolio. Organizations should anticipate additional CVEs as this review continues and should proactively audit their Spring component inventory, particularly for features involving real-time transports (WebSocket, Server-Sent Events, RSocket) where Origin validation and CSRF protections may be similarly absent.
The existence of CVE-2026-41700 itself, a well understood weakness class that OWASP and CWE have documented for years, indicates that foundational security practices were not consistently applied during the initial development of the GraphQL WebSocket transport feature.
References
- Spring Advisory: CVE-2026-41700
- GitHub Advisory: GHSA-m39w-hqxx-3r48
- Spring Security Advisories
- SecurityOnline: CVE-2026-41700 Archives
- SecurityOnline: Spring GraphQL Security Patches for Deserialization Flaws
- CWE-1385: Missing Origin Validation in WebSockets
- CWE-346: Origin Validation Error
- OWASP WebSocket Security Cheat Sheet
- PortSwigger: Cross-site WebSocket Hijacking
- Include Security: Cross-Site WebSocket Hijacking Exploitation in 2025
- SecureFlag: Cross-Site WebSocket Hijacking Vulnerability
- Spring Security WebSocket Documentation
- Broadcom: Expands Investment in Spring and Java Ecosystem Security
- Techzine: Broadcom Bolsters Spring Security with Largest Update Ever
- Spring for GraphQL Project Page
- Christian Schneider: Cross-Site WebSocket Hijacking (CSWSH)
- Praetorian: Cross-Site WebSocket Hijacking



