fkie_cve-2026-69204

Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, Ember HTTP/1.1 does not reject messages containing both Transfer-Encoding and Content-Length, so an intermediary and Ember can select different body framing rules. When ember-server is behind a keep-alive intermediary that forwards both headers and frames by Content-Length, an unauthenticated attacker can smuggle a second request, bypass intermediary access controls, poison caches, or cause a victim request to be joined to an attacker-controlled prefix. The shared response parser can also desynchronize an ember-client connection when a malicious or compromised upstream sends both headers. This issue is fixed in versions 0.23.35 and 1.0.0-M47.

GHSA-8h4c-x2wg-6xp8 — Http4s Ember accepts Transfer-Encoding combined with Content-Length (CL.TE request smuggling)

Affected: Maven: org.http4s:http4s-ember-core_2.12, Maven: org.http4s:http4s-ember-core_2.13, Maven: org.http4s:http4s-ember-core_3

## Summary

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 with the next request key in a caching proxy.

### Client

ember-client shares the same parser on the response path. An upstream that sends both headers can desync a pooled client connection. This requires a malicious or compromised upstream.

## Preconditions

- Unauthenticated remote attacker (server) - ember-server as origin behind a keep-alive intermediary - Intermediary forwards a request carrying both `Transfer-Encoding` and `Content-Length` (RFC says it MAY…

Most recent entries from all

fkie_cve-2026-69204

GHSA-8h4c-x2wg-6xp8 — Http4s Ember accepts Transfer-Encoding combined with Content-Length (CL.TE request smuggling)