https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 30 Sep 2026 11:03:24 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-73493 <p>Http4s (http4s-blaze-server) is a minimal, idiomatic Scala interface for HTTP services. Prior to 0.23.18 and 1.0.0-M42, http4s-blaze-server aggregates fragments of an incoming WebSocket message with no limit on total size or fragment count. A client that completes a WebSocket handshake can send an unterminated fragmented message and drive unbounded heap growth in the server JVM, resulting in denial of service through OutOfMemoryError. Any http4s application serving WebSocket routes over BlazeServerBuilder is affected, no non-default configuration is required, and maxWebSocketBufferSize does not bound the aggregate because it bounds only individual frames. A single connection sending continuation frames that never set FIN forces the server to buffer every fragment until the heap is exhausted, terminating the JVM with OutOfMemoryError on the blaze selector thread. Small fragments amplify the cost through per-frame object overhead, so a modest volume of wire bytes is sufficient. This issue is fixed in versions 0.23.18 and 1.0.0-M42.</p> <p>Http4s (http4s-blaze-server) is a minimal, idiomatic Scala interface for HTTP services. Prior to 0.23.18 and 1.0.0-M42, http4s-blaze-server aggregates fragments of an incoming WebSocket message with no limit on total size or fragment count. A client that completes a WebSocket handshake can send an unterminated fragmented message and drive unbounded heap growth in the server JVM, resulting in denial of service through OutOfMemoryError. Any http4s application serving WebSocket routes over BlazeServerBuilder is affected, no non-default configuration is required, and maxWebSocketBufferSize does not bound the aggregate because it bounds only individual frames. A single connection sending continuation frames that never set FIN forces the server to buffer every fragment until the heap is exhausted, terminating the JVM with OutOfMemoryError on the blaze selector thread. Small fragments amplify the cost through per-frame object overhead, so a modest volume of wire bytes is sufficient. This issue is fixed in versions 0.23.18 and 1.0.0-M42.</p> https://db.gcve.eu/vuln/fkie_cve-2026-73493 https://db.gcve.eu/vuln/ghsa-7ppr-r889-mcf2 <p><strong>Affected:</strong> Maven: org.http4s:http4s-blaze-server_2.13, Maven: org.http4s:http4s-blaze-server_2.12, Maven: org.http4s:http4s-blaze-server_3</p> <p>## Summary</p> <p>`http4s-blaze-server` aggregates the fragments of an incoming WebSocket message with no limit on total size or fragment count. A client that completes a WebSocket handshake can send an unterminated fragmented message and drive unbounded heap growth in the server JVM, resulting in denial of service via `OutOfMemoryError`.</p> <p>## Impact</p> <p>Any http4s application serving WebSocket routes over `BlazeServerBuilder` is affected; no non-default configuration is required, and `maxWebSocketBufferSize` does not bound the aggregate (it bounds only individual frames). A single connection sending continuation frames that never set FIN forces the server to buffer every fragment until the heap is exhausted, terminating the JVM with `OutOfMemoryError` on the blaze selector thread. Small fragments amplify the cost through per-frame object overhead, so a modest volume of wire bytes is sufficient. Where the WebSocket endpoint is reachable without authentication the attacker is unauthenticated and remote; where the handshake requires a principal, any authenticated client can still trigger it.</p> <p>## Workarounds</p> <p>- No blaze-server configuration bounds the aggregate; `maxWebSocketBufferSize` is not a mitigation. - Terminate/limit WebSocket traffic at a fronting layer that enforces message-size and fragment limits, or disable WebSocket routes. - Longer term: blaze is EOL upstream; plan migration to a maintained backend (e.g. ember).</p> <p><strong>Affected:</strong> Maven: org.http4s:http4s-blaze-server_2.13, Maven: org.http4s:http4s-blaze-server_2.12, Maven: org.http4s:http4s-blaze-server_3</p> <p>## Summary</p> <p>`http4s-blaze-server` aggregates the fragments of an incoming WebSocket message with no limit on total size or fragment count. A client that completes a WebSocket handshake can send an unterminated fragmented message and drive unbounded heap growth in the server JVM, resulting in denial of service via `OutOfMemoryError`.</p> <p>## Impact</p> <p>Any http4s application serving WebSocket routes over `BlazeServerBuilder` is affected; no non-default configuration is required, and `maxWebSocketBufferSize` does not bound the aggregate (it bounds only individual frames). A single connection sending continuation frames that never set FIN forces the server to buffer every fragment until the heap is exhausted, terminating the JVM with `OutOfMemoryError` on the blaze selector thread. Small fragments amplify the cost through per-frame object overhead, so a modest volume of wire bytes is sufficient. Where the WebSocket endpoint is reachable without authentication the attacker is unauthenticated and remote; where the handshake requires a principal, any authenticated client can still trigger it.</p> <p>## Workarounds</p> <p>- No blaze-server configuration bounds the aggregate; `maxWebSocketBufferSize` is not a mitigation. - Terminate/limit WebSocket traffic at a fronting layer that enforces message-size and fragment limits, or disable WebSocket routes. - Longer term: blaze is EOL upstream; plan migration to a maintained backend (e.g. ember).</p> https://db.gcve.eu/vuln/ghsa-7ppr-r889-mcf2