CVE-2026-41838

What it actually does

The flaw is a cryptographic weakness in Spring Framework's spring-websocket module where WebSocket session identifiers are not generated with sufficient unpredictability. If an application relies on those identifiers as part of its authorization or session-isolation logic, an attacker who already has some level of access and can interact with a victim or target workflow may be able to infer or guess valid WebSocket session identifiers and access another user's WebSocket session context. The primary technical impact is unauthorized disclosure of data transmitted over or associated with WebSocket sessions; integrity and availability are not the primary impacts described.

Why it matters to the business

Applications using affected Spring Framework versions for WebSocket functionality may expose sensitive real-time application data if their authorization controls depend on WebSocket session IDs being unguessable. The risk is heightened for applications that handle chat, notifications, trading, collaboration, telemetry, administrative consoles, or other live user-specific data over WebSockets. Exploitation is not currently known to be widespread, is not listed in CISA KEV, has low EPSS, and requires specific application design weaknesses, but affected internet-facing or high-sensitivity WebSocket services should still be prioritized for upgrade because the weakness undermines an assumption many developers may make about session identifiers.

How an attack unfolds

An attacker first obtains legitimate low-privileged access to an application or otherwise reaches a WebSocket-enabled feature. They observe their own WebSocket behavior, session identifiers, message routing, connection metadata, and any predictable patterns in session ID assignment. If the application has inadequate authorization checks and treats possession or knowledge of a WebSocket session ID as sufficient to access session-scoped data, the attacker attempts to predict or enumerate another valid WebSocket session identifier. The attacker then sends crafted WebSocket requests, subscriptions, or messages referencing the guessed identifier. When the application fails to independently verify that the requester is authorized for the targeted session or destination, the attacker may receive data intended for another user or session. Successful exploitation depends on both the weak session ID generation and application-level authorization mistakes; the weak ID alone is not necessarily sufficient.

How to fix it

Upgrade Spring Framework to a version that contains the vendor fix for this issue. The affected ranges are Spring Framework 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. Because exact fixed versions were not provided in the input, consult the official Spring advisory and upgrade to the first fixed release for the maintained branch in use, or to the latest available patched release. In addition to upgrading, review WebSocket authorization design: do not treat WebSocket session IDs as secrets, do not authorize access based only on possession of a session identifier, enforce user and role authorization on every subscription and message-handling path, validate that requested destinations belong to the authenticated principal, and avoid exposing session identifiers in client-visible logs, URLs, or messages. Where immediate upgrade is not possible, reduce exposure by restricting WebSocket endpoints to trusted networks or authenticated users, disabling affected WebSocket features where feasible, and adding server-side authorization checks independent of session ID unpredictability.

How to confirm the fix worked

Confirm exposure by inventorying applications that include org.springframework:spring-websocket or Spring Framework versions in the affected ranges: 7.0.0-7.0.7, 6.2.0-6.2.18, 6.1.0-6.1.27, and 5.3.0-5.3.48. Use build manifests, SBOMs, dependency lock files, container image scans, and runtime classpath inspection to identify vulnerable versions, including transitive dependencies. After remediation, verify that the resolved Spring Framework version is outside the affected range and matches the vendor-fixed release line. Functionally test WebSocket endpoints to ensure a user cannot subscribe to, publish to, or retrieve data from another user's session, destination, queue, topic, or connection context even if a valid-looking or previously observed session identifier is supplied. Review automated tests for per-message and per-subscription authorization, not just authorization at initial WebSocket connection time.

Typical attack path

1. Identify an application endpoint or feature using Spring WebSocket functionality.
2. Authenticate or obtain the minimum access needed to open a legitimate WebSocket connection, if required.
3. Observe WebSocket session IDs, message destinations, subscriptions, cookies, headers, and connection behavior.
4. Infer whether WebSocket session identifiers follow a predictable or low-entropy pattern.
5. Test guessed or derived session identifiers against WebSocket routes, subscriptions, or message-handling endpoints.
6. Exploit weak or missing authorization checks to access messages or data associated with another user's WebSocket session.
7. Collect sensitive data exposed through the unauthorized WebSocket session context.

How to detect it

There are no public, reliable exploit-specific indicators for this issue, and exploitation may look like normal WebSocket traffic unless the application logs session-to-user mapping and authorization decisions. To investigate possible prior exploitation, review application logs, WebSocket/STOMP broker logs, reverse proxy logs, API gateway logs, WAF logs, and authentication/session logs for abnormal WebSocket behavior. Look for repeated connection or subscription attempts with varying session identifiers, subscription attempts to user-specific destinations not owned by the authenticated user, mismatches between authenticated user identity and WebSocket session owner, repeated 403/401 responses followed by successful WebSocket subscriptions, unusual access to /ws, /websocket, /stomp, or SockJS endpoints, and spikes in WebSocket connection attempts from a single account or source IP. If message broker relay or STOMP is used, examine SUBSCRIBE, SEND, CONNECT, and destination fields for cross-user destination probing. Correlate suspected activity with accounts that have low privilege but accessed high-sensitivity real-time data. Because the weakness is contextual, the strongest detection comes from application-specific authorization logs showing that a principal referenced or accessed another principal's WebSocket session, queue, topic, or destination.

What your security team should do

• Inventory all applications using Spring WebSocket and identify those running 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.
• Prioritize internet-facing, multi-tenant, high-privilege, or sensitive-data WebSocket applications for patching and design review.
• Upgrade to the applicable vendor-fixed Spring Framework release or the latest patched release in the supported branch.
• Review WebSocket authorization logic to ensure access decisions are tied to the authenticated principal and server-side permissions, not to possession of a WebSocket session ID.
• Add regression tests that attempt cross-user WebSocket subscription, message access, and session identifier manipulation.
• Increase logging for WebSocket connection establishment, subscription requests, destination access denials, and anomalous session identifier references.
• Search historical WebSocket logs for unusual enumeration, repeated failed subscriptions, or access attempts involving session identifiers not associated with the authenticated user.
• If high-sensitivity data is transmitted over affected WebSocket endpoints, consider incident review and targeted forensic analysis even though public exploit maturity and EPSS are currently low.