Quick answers
- Is CVE-2026-69204 exploited in the wild?
- No. Junglewise Threat Intelligence has no report of CVE-2026-69204 being exploited in the wild.
- How severe is CVE-2026-69204?
- Critical severity, with a CVSS score of 4, published 15 September 2026.
- Which products and versions are affected?
- Http4s-Ember-Core <= 0.23.34; org.http4s:http4s-ember-core_2.12 (Maven) ECOSYSTEM:introduced=0,fixed=0.23.35; org.http4s:http4s-ember-core_2.13 (Maven) ECOSYSTEM:introduced=0,fixed=0.23.35; org.http4s:http4s-ember-core_3 (Maven) ECOSYSTEM:introduced=0,fixed=0.23.35.
- Is there a fix for CVE-2026-69204?
- Yes. org.http4s:http4s-ember-core_2.12 (Maven): upgrade to 0.23.35 or later; org.http4s:http4s-ember-core_2.13 (Maven): upgrade to 0.23.35 or later; org.http4s:http4s-ember-core_3 (Maven): upgrade to 0.23.35 or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
- How is CVE-2026-69204 attacked?
- It is attacked over the network, in a software library.
- Am I affected by CVE-2026-69204?
- Check whether you run Http4s-Ember-Core, org.http4s:http4s-ember-core_2.12 (Maven), org.http4s:http4s-ember-core_2.13 (Maven) or one of the others listed at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.
How to fix
- org.http4s:http4s-ember-core_2.12 (Maven): upgrade to 0.23.35 or later
# set org.http4s:http4s-ember-core_2.12 to 0.23.35 in your pom.xml or build.gradle - org.http4s:http4s-ember-core_2.13 (Maven): upgrade to 0.23.35 or later
# set org.http4s:http4s-ember-core_2.13 to 0.23.35 in your pom.xml or build.gradle - org.http4s:http4s-ember-core_3 (Maven): upgrade to 0.23.35 or later
# set org.http4s:http4s-ember-core_3 to 0.23.35 in your pom.xml or build.gradle
Technical details
The vulnerability is an inconsistent HTTP request interpretation (CWE-444) in Http4s Ember's HTTP/1.1 parser. RFC 9112 §6.1 requires servers to reject—and close the connection on—any message carrying both a Transfer-Encoding and Content-Length header. Ember's parser fails to enforce this requirement, accepting both headers. When Ember is deployed behind a reverse proxy or HTTP intermediary that follows RFC guidance by stripping Transfer-Encoding and framing the message body according to Content-Length, the two systems interpret message boundaries differently. An attacker can send a crafted request with both headers to an intermediary; the intermediary frames the body by Content-Length (short), while Ember frames by chunked encoding (long), leaving extra attacker-controlled bytes in the connection buffer. On a keep-alive connection, this buffer overflow contaminates the next request, enabling request smuggling. Attack requires network access to the intermediary (unauthenticated) and a backend keep-alive connection to Ember. Patched versions (0.23.35, 1.0.0-M47, and later) reject messages with both headers. No patches for 0.23.34 or 1.0.0-M1–M46 are available; users must upgrade.
Affected products
- http4s http4s-ember-core_2.12 <= 0.23.34
- http4s http4s-ember-core_2.13 <= 0.23.34, >= 1.0.0-M1 to <= 1.0.0-M46
- http4s http4s-ember-core_3 <= 0.23.34, >= 1.0.0-M1 to <= 1.0.0-M46
Identifiers
- CVE-2026-69204
- GHSA-8h4c-x2wg-6xp8
Timeline
- 2026-07-06: disclosed: Published to GitHub Advisory Database
- 2026-09-15: advisory: Reviewed and published to GitHub Advisory Database
- 2026-07-06: patched: Patched versions released: 0.23.35, 1.0.0-M47