An unauthenticated peer can make Ember's HTTP/2 read loop hold 16 MiB of a single frame in memory on a connection where Ember advertised a 16 KiB limit. The declared length is readable from the frame's first 9 bytes, but it is not compared against SETTINGS_MAX_FRAME_SIZE until the whole payload has been read into a contiguous buffer. That is 1024x amplification per connection, bounded by the protocol's 24-bit length field …
Ember's chunk decoder parses the size token leniently: it strips leading and trailing whitespace and accepts a leading + or - sign. RFC9112 §7.1 defines chunk-size = 1*HEXDIG. An intermediary that parses the chunk boundary differently (or rejects it) will disagree with Ember on request framing, enabling HTTP request smuggling (TE.TE).
The DigestAuth replay defence stores lastNc + 1 rather than the nonce-count (nc) value it just accepted. When a legitimate client sends non-contiguous nc values (parallel or retried requests, as browsers do), the server's counter lags behind the highest nc seen, and a captured Authorization header can be replayed multiple times.
Ember's HTTP/1.1 header parser matches the Transfer-Encoding header value with a case-sensitive substring test (hValue.contains("chunked")). RFC 9112 §7 requires transfer-coding names to be compared case-insensitively. A request carrying Transfer-Encoding: Chunked (capital C) is therefore not recognised as chunked, and Ember falls back to framing by Content-Length (or zero if absent) while a compliant intermediary frames the same bytes by chunked encoding. The two parsers then disagree on where the request …
Ember's HTTP/2 stack replenishes the inbound flow-control window based on bytes received off the wire, not bytes consumed by the application. Received DATA is buffered in an unbounded per-stream channel. Flow control therefore provides no backpressure: a peer can stream a large or unbounded body faster than the application drains it and the connection retains every payload in heap. This is the read-path mirror of the outbound queue issue. This …
When Ember receives an HTTP/2 HEADERS or PUSH_PROMISE frame without the END_HEADERS flag, it buffers the header block fragment and waits for subsequent CONTINUATION frames. These accumulate unbounded until the connection closes.
Ember's HTTP/2 connection serializes all outgoing frames through a single unbounded queue drained by one writer fiber (writeLoop). When the write side stalls, any frames the connection keeps producing accumulate in that queue without limit. The peer can drive this cheaply because the connection emits a control frame in response to inbound frames it does not flow-control: one PING ACK per PING, one SETTINGS ACK per SETTINGS, and a WINDOW_UPDATE …
An ember server with HTTP/2 enabled (.withHttp2) does not enforce SETTINGS_MAX_CONCURRENT_STREAMS on streams opened by the peer. A single unauthenticated connection can open an unbounded number of concurrent streams, each of which allocates per-stream server state that is never released, exhausting the heap.
Ember's HTTP/1.1 request parser does not reject a message that carries both a Transfer-Encoding and a Content-Length header. RFC 9112 §6.1 requires a server to treat such a message as a framing error and close the connection. An intermediary that follows the RFC's CL-strip-and-forward path (or that prioritises Content-Length) will frame the body differently from Ember, enabling HTTP request smuggling (CL.TE).
http4s 0.23.x and 1.0 servers running ember with http2 enabled are vulnerable to a denial of service attack using a HPACK bomb vulnerability recently disclosed as affecting other http2 servers.