CVE-2026-73493: 
Java vulnerability analysis and mitigation

CVE-2026-73493 is an unbounded WebSocket message aggregation vulnerability in http4s-blaze-server (the Blaze backend for the http4s Scala HTTP library) that allows any client that completes a WebSocket handshake to cause denial of service via JVM OutOfMemoryError. The flaw affects all versions of http4s-blaze-server prior to 0.23.18 and all 1.0.0 milestone releases from 1.0.0-M1 through 1.0.0-M41. It was disclosed on July 23, 2026 via GitHub Security Advisory GHSA-7ppr-r889-mcf2 and assigned CVE-2026-73493 on August 12, 2026. The vulnerability carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Feedly).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling) in the WSFrameAggregator pipeline stage of blaze-server. Per RFC 6455 §5.4, WebSocket messages may be split into an unlimited number of continuation frames; blaze's aggregator accumulated every fragment into a heap buffer with no cap on total size or fragment count. The existing maxWebSocketBufferSize configuration only bounded individual frame sizes, not the aggregate of a multi-fragment message. An attacker performs a standard WebSocket handshake and then streams continuation frames with the FIN bit never set, forcing the server to buffer each fragment indefinitely; because small fragments also incur per-object JVM heap overhead (queue node, frame object, ByteVector wrapper), a modest wire-byte volume is sufficient to exhaust heap and crash the blaze selector thread with OutOfMemoryError (GitHub Advisory, Fix Commit).

Successful exploitation terminates the server JVM with an OutOfMemoryError on the blaze selector thread, causing a complete denial of service for all users of the affected application. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue. Where WebSocket endpoints are publicly accessible without authentication, any remote unauthenticated client can trigger the crash; where authentication is required, any authenticated user can still exploit it (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the disclosure date. The EPSS score is 0.0, indicating very low current probability of exploitation in the wild, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (Feedly). The attack requires no privileges (for unauthenticated WebSocket endpoints), no user interaction, and low complexity — only a completed WebSocket handshake followed by a stream of continuation frames with FIN never set (GitHub Advisory).

1. Reconnaissance: Identify services running http4s-blaze-server with WebSocket endpoints exposed (e.g., via HTTP upgrade headers in responses, or by inspecting Maven/SBT dependency manifests if source is available). Confirm the server version is below 0.23.18 or between 1.0.0-M1 and 1.0.0-M41.
2. WebSocket Handshake: Send a valid HTTP Upgrade request to a WebSocket endpoint on the target server to complete the handshake (e.g., using a standard WebSocket client library or wscat).
3. Send Fragmented Message: Begin a fragmented WebSocket message by sending a text or binary frame with the FIN bit set to 0 (indicating more fragments follow).
4. Stream Continuation Frames: Continuously send WebSocket continuation frames (opcode 0x0) with FIN=0 and small payloads (e.g., 1–100 bytes each). Each frame is buffered by the server's WSFrameAggregator with no size limit, and per-object JVM overhead amplifies heap consumption.
5. Exhaust Heap: Continue sending frames until the server JVM heap is exhausted, triggering an OutOfMemoryError on the blaze selector thread and crashing the server process, resulting in denial of service for all connected clients (GitHub Advisory, Fix Commit).

• Logs: JVM crash logs or application logs containing java.lang.OutOfMemoryError originating from the blaze selector thread; log entries such as Exception in thread "blaze-selector-*" java.lang.OutOfMemoryError: Java heap space.
• Logs: Absence of a WebSocket Close(1009) frame being sent to the client (patched versions send this; unpatched versions crash instead).
• Network: A single long-lived WebSocket connection sending a high volume of small frames (continuation frames with FIN=0) without ever completing a message; unusually high frame counts from a single source IP on WebSocket endpoints.
• Process: Sudden JVM process termination (exit code indicating OOM kill) of the http4s-blaze-server process; OS-level OOM killer logs (oom_kill_process) on Linux hosts.
• File System: JVM heap dump files (.hprof) generated at crash time if -XX:+HeapDumpOnOutOfMemoryError is configured, containing large numbers of WebSocketFrame or ByteVector objects in the heap (GitHub Advisory).

Upgrade to http4s-blaze-server version 0.23.18 (stable) or 1.0.0-M42 (milestone) immediately, as these releases cap aggregate WebSocket message size at 4 MiB by default in WSFrameAggregator and send a Close(1009) frame on breach (Release v0.23.18, Release v1.0.0-M42). If upgrading is not immediately possible, terminate or rate-limit WebSocket traffic at a fronting layer (e.g., a reverse proxy such as nginx or HAProxy) that enforces message-size and fragment-count limits. Disabling WebSocket routes entirely is also an effective workaround. Note that maxWebSocketBufferSize is not a mitigation in unpatched versions, as it only bounds individual frames. The advisory also recommends planning migration away from blaze (which is EOL upstream) to a maintained backend such as Ember (GitHub Advisory).

The advisory was published by Ross A. Baker (rossabaker), the primary maintainer of the http4s/blaze project, who also noted that blaze is EOL upstream and recommended migration to a maintained backend as a longer-term measure (GitHub Advisory). The release notes for both v0.23.18 and v1.0.0-M42 characterize them as "security hardening releases" and urge immediate upgrade for any deployment exposing WebSocket endpoints (Release v0.23.18). No significant broader media coverage or notable external researcher commentary has been identified beyond standard CVE aggregator coverage.