Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
11 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 SETTINGSMAXFRAMESIZE 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 rather than by any setting, and at the default maxConnections of 1024 it puts about 16 GiB of heap in reach. Details H2Frame.RawFrame.fromByteVector (ember-core/.../h2/H2Frame.scala:66-69) reads the length, then refuses to produce a frame until 9 + length bytes are present: readNextFrame in H2Connection.readLoop (H2Connection.scala:246-266) reads that None as "need more" and concatenates further socket reads into one accumulator until it is satisfied. The only check of an inbound frame against the connection's own SETTINGSMAXFRAMESIZE is in processFrame at…
Recommended action: Upgrade to 1.0.0-M48 (pre-release) or 0.23.37 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When Ember receives an HTTP/2 HEADERS or PUSHPROMISE frame without the ENDHEADERS flag, it buffers the header block fragment and waits for subsequent CONTINUATION frames. These accumulate unbounded until the connection closes. Impact A remote, unauthenticated peer can exhaust the heap on any Ember endpoint that has HTTP/2 enabled: - ember-server with .withHttp2: any HTTP/2 client can trigger this against any reachable path (including paths that return 404). No authentication is required because the attack completes before the request is decoded. - ember-client with .withHttp2: a malicious or compromised origin server can trigger this via the response header block. A single in-flight request is sufficient. Memory consumption is bounded only by the attacker's upload bandwidth and the connection lifetime. Prerequisites - EmberServerBuilder configured with .withHttp2. - For the server: the attacker can establish an HTTP/2 connection - For the client: the application makes a request to an…
Recommended action: Upgrade to 1.0.0-M47 (pre-release) or 0.23.35 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 = 1HEXDIG. An intermediary that parses the chunk boundary differently (or rejects it) will disagree with Ember on request framing, enabling HTTP request smuggling (TE.TE). Impact Server Request smuggling (TE.TE) when ember-server is an origin behind an intermediary that forwards the body verbatim but interprets the malformed chunk sizes differently - Front-end security bypass: the smuggled request reaches paths the intermediary might have blocked, with attacker-chosen method and headers. - Cache poisoning: the smuggled response is associated with the next request key in a caching proxy. - Request queue hijack: Client ember-client has the same leniencies on the response path, which enables response smuggling when http4s is used as a gateway. This is less severe, as it requires a malicious or compromised upstream…
Recommended action: Upgrade to 1.0.0-M47 (pre-release) or 0.23.35 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 WINDOWUPDATE per inbound DATA. A single unauthenticated connection can therefore exhaust heap and OOM the process. This affects an ember server (malicious client) and an ember client (malicious/compromised server that floods the client and stops reading its ACKs). Impact Unauthenticated remote denial of service (OOM) against any ember server built .withHttp2, from a single connection, at negligible attacker cost (tiny control frames). Also affects an ember client talking to a hostile HTTP/2 server. Preconditions - Ember server or client built .withHttp2,…
Recommended action: Upgrade to 1.0.0-M47 (pre-release) or 0.23.35 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Impact A passive observer can turn one captured Digest-authenticated request into several replayed authenticated (state-changing) requests, defeating the core replay protection Digest provides over Basic. Preconditions - Application uses DigestAuth. - Attacker can passively observe at least one legitimate digest request. - Legitimate client emits an nc more than one greater than the last, for instance from a parallel or retried request. Workarounds - Deploy over TLS so requests cannot be captured.
Recommended action: Upgrade to 1.0.0-M47 (pre-release) or 0.23.35 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 body ends, enabling HTTP request smuggling (TE.CL / TE.0). The same line of code admits two further variants: - The substring test misfires on Transfer-Encoding: notchunked (an inverse desync — Ember treats it as chunked while a compliant intermediary rejects the unknown coding). - Header field bytes are decoded with the platform-default charset. Under UTF-8 the wire bytes E2 84 AA decode to U+212A KELVIN SIGN, which String.equalsIgnoreCase Unicode-case-folds to k, so…
Recommended action: Upgrade to 1.0.0-M47 (pre-release) or 0.23.35 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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). Impact Server Request smuggling when ember-server is an origin behind an intermediary that forwards both headers over a keep-alive backend connection and frames by Content-Length while Ember frames by chunked: - Front-end security bypass: the smuggled request reaches paths the intermediary's ACL/auth layer would have blocked, with attacker-chosen method and headers. - Cross-user request hijack: a dangling smuggled prefix concatenates with the next victim's request on the shared backend socket, capturing its headers. - Cache poisoning: the smuggled response is associated…
Recommended action: Upgrade to 1.0.0-M47 (pre-release) or 0.23.35 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An ember server with HTTP/2 enabled (.withHttp2) does not enforce SETTINGSMAXCONCURRENTSTREAMS 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. Impact Unauthenticated remote denial of service (memory exhaustion) against any Ember server built .withHttp2. This is the resource-exhaustion class of the HTTP/2 "Rapid Reset" family (CVE-2023-44487). The same unchecked allocation path is reachable on the client via server-initiated PUSHPROMISE frames, so a malicious or compromised server can exhaust an ember-client's heap the same way. Preconditions - Server: with .withHttp2 enabled. - Client: makes HTTP/2 requests to malicious or compromised sites. enablePush is not enforced. Workarounds - Disable HTTP/2 on EmberServerBuilder or EmberClientBuilder (default) - Client only: avoid HTTP/2 to untrusted servers until patched.
Recommended action: Upgrade to 1.0.0-M47 (pre-release) or 0.23.35 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 affects an Ember receiving a request body and an Ember client receiving a response body from a hostile server. Impact Unauthenticated remote denial of service (OOM) against any Ember server built .withHttp2 for a non-draining or slow-draining route, and against an Ember client consuming from a hostile or compromised server. Workarounds - Disable HTTP/2 to remove the vector entirely. - Apply an aggregate request-entity size limit (e.g. EntityLimiter middleware) on routes that consume the body. - Ensure handlers fully drain request bodies with…
Recommended action: Upgrade to 1.0.0-M47 (pre-release) or 0.23.35 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Impact Denial of Service: - Affects any http4s server running the ember backend with HTTP/2 enabled that is exposed to untrusted traffic. - Affects any http4s client running the ember backend with HTTP/2 enabled that can be directed to an untrusted server. Details The issue occurs in the Hpack wrapper. Ember concatenates the header and continuation frames before decoding all headers at once. When the code decodes the attack payload, the relatively small packets decode to a significantly larger amount of data which is returned as a single List which is then held in memory for further processing. With enough concurrent…
Recommended action: Upgrade to 1.0.0-M47 (pre-release) or 0.23.35 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
http4s is vulnerable to HTTP Request Smuggling due to improper handling of HTTP trailer section. This vulnerability could enable attackers to: - Bypass front-end servers security controls - Launch targeted attacks against active users - Poison web caches Pre-requisites for the exploitation: the web appication has to be deployed behind a reverse-proxy that forwards trailer headers. Details The HTTP chunked message parser, after parsing the last body chunk, calls parseTrailers (ember-core/shared/src/main/scala/org/http4s/ember/core/ChunkedEncoding.scala#L122-142). This method parses the trailer section using Parser.parse, where the issue originates. parse has a bug that allows to terminate the parsing before finding the double CRLF condition: when it finds an header line that does not include the colon character, it continues parsing with state=false looking for the header name till reaching the condition else if (current == lf && (idx 0 && message(idx - 1) == cr)) that sets…
Recommended action: Upgrade to 1.0.0-M45 (pre-release) or 0.23.31 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.