Spring Framework CVE-2026-47893

Exploitation requires three concurrent conditions: (1) the target application must use the Spring WebFlux reactive stack - not Spring MVC; (2) the application must have WebSocket support explicitly configured and expose at least one WebSocket endpoint to the attacker; (3) the attacker must be able to reach that endpoint over the network and trigger a server-side exception during WebSocket handshake or session handling. The CVSS PR:N metric reflects that no authentication is needed to initiate a WebSocket connection. Exploitation is limited by the requirement that the application specifically enable WebSocket support, which is a non-default configuration in WebFlux - pure HTTP/REST WebFlux applications are not vulnerable. The 'indirectly sensitive' language in the description suggests headers may not always carry high-value credentials, reducing practical impact in deployments where sensitive data is not transmitted via headers. There is no evidence of exploitation against non-WebSocket WebFlux endpoints.

The NVD CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) scores 7.5 and implies unauthenticated network exploitation with high confidentiality impact - technically accurate if the exposed headers include bearer tokens or session cookies. However, the EPSS score of 0.14% at the 4th percentile is a strong counter-signal: despite wide Spring Framework deployment, automated exploitation is not observed in practice. This gap is consistent with the nature of the flaw: exploitation requires identifying a WebFlux application specifically using WebSocket support (a non-default sub-feature), then crafting a request that triggers a header-including exception path - adding real-world complexity not reflected in AC:L. There is no CISA KEV listing, no known POC, and no vendor indication of active exploitation. The realistic priority is: medium-urgency patching for internet-facing WebFlux applications with WebSocket endpoints; lower urgency for internally-facing or non-WebSocket WebFlux deployments.

An attacker who discovers a publicly accessible Spring WebFlux application with a WebSocket endpoint sends a crafted WebSocket upgrade request designed to trigger a server-side exception - for example, by providing an invalid subprotocol or malformed frame sequence. The framework constructs an exception reason message that includes the original request headers verbatim and returns this reason in the WebSocket close frame or error response. The attacker reads the Authorization or Cookie header values from that message, recovering session tokens or API credentials without requiring any prior authentication. No public POC is known at time of analysis.