http4s-blaze-server EUVD-2026-57631

The application must be using BlazeServerBuilder and must expose at least one WebSocket route - no non-default configuration is required beyond this. The attacker must successfully complete a WebSocket handshake (HTTP Upgrade). Where the WebSocket endpoint requires no authentication (PR:N surface), exploitation is fully unauthenticated and remote. Where the handshake requires a valid session or principal, any authenticated client - including low-privilege users - can trigger the condition (PR:L surface). The existing maxWebSocketBufferSize setting does not limit exploitation. Factors limiting real-world impact: the target must be running the Scala/JVM stack with http4s-blaze-server specifically; the attack tears down the entire JVM process rather than a single connection, making it immediately observable; and blaze's EOL status means patching is the only sustainable remediation path.

The official CVSS 3.1 score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) accurately reflects the worst-case scenario where a WebSocket endpoint is publicly reachable without authentication. The GHSA advisory clarifies that where authentication is required, any valid principal can still trigger the crash - so PR:N applies to the unauthenticated surface and PR:L applies to authenticated deployments; this nuance does not change the score but matters for exposure assessment. No KEV listing and no confirmed public exploit code exist at time of analysis, so real-world exploitation is not confirmed. There is no EPSS data provided; given the niche deployment footprint of blaze-based Scala services, opportunistic mass exploitation is unlikely but targeted exploitation against a known blaze deployment would be straightforward. The availability impact is severe - OOM on the blaze selector thread terminates the JVM, taking down the entire service, not just the affected connection. Since blaze is EOL, no further mitigations will emerge outside of the single released patch. The CVSS signals are internally consistent and do not conflict with the description.

An attacker targeting a publicly exposed blaze-based Scala API performs the WebSocket handshake against any WebSocket endpoint and then sends a stream of small continuation frames - for example, 64-byte frames - that never include the FIN bit, preventing the server from delivering a complete message. Because each frame is buffered and also incurs per-object JVM heap overhead, the server heap grows monotonically; depending on heap configuration, a few thousand to tens of thousands of such frames suffice to trigger OutOfMemoryError on the selector thread and crash the JVM process. No exploit code has been publicly identified, but the technique requires only standard WebSocket framing knowledge.