CVE-2025-41254: Spring Framework STOMP over WebSocket applications may allow attackers to send unauthorized messages

The vulnerability, CVE-2025-41254, allows an attacker to send unauthorized STOMP messages over a WebSocket connection. The root cause lies in a state management flaw within the StompSubProtocolHandler class in spring-websocket.

My analysis of the patch between the vulnerable version (6.2.11) and the fixed version (6.2.12) pinpoints the commit c88bfc54c9256e3c07511aa303be2b136c03e0e2, which refactors this state management.

In the vulnerable version, the handler used separate maps to track message channels and authenticated STOMP users (stompAuthentications). A user was associated with a session via a callback after a CONNECT message was sent for processing. This created a race condition. An attacker could send a WebSocket message containing multiple STOMP frames, such as a SEND or SUBSCRIBE frame before the initial CONNECT frame was fully processed and authenticated.

The handleMessageFromClient function would process these frames sequentially. Before the STOMP user was established in the stompAuthentications map, the getUser function would fall back to using the principal from the underlying WebSocket session. This could allow messages to be processed with incorrect permissions, either those of an anonymous user or a less-privileged user associated with the WebSocket handshake, bypassing the intended STOMP-level authorization.

The fix introduces a SessionInfo class that atomically holds all session-related state, including the message channel and the user principal. This SessionInfo object is created and stored in a map only upon receiving a CONNECT frame. For any subsequent frames, the code now asserts that a session must already exist. This enforces a strict protocol flow, ensuring no STOMP messages are processed before a session is properly established and authenticated, thus closing the security bypass.

The primary vulnerable function is handleMessageFromClient as it's the entry point for processing malicious STOMP messages. The getUser function is also a key part of the vulnerable logic.