요약
- CVE-2026-69204은(는) org.http4s:http4s-ember-core_2.12, org.http4s:http4s-ember-core_2.13, org.http4s:http4s-ember-core_3에 영향을 주는 심각 (CVSS 9.2) 취약점입니다.
- 향후 30일 내 악용 확률(EPSS): 0.57%, 전체 취약점의 47.4%보다 높음.
- 조치: 0.23.35, 1.0.0-M47 이상으로 업데이트하세요.
Description
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 reject; many forward) and frames by
Content-Length
- Malicious or compromised upstream (client)
Workarounds
- Intermediary strictly rejects requests carrying both
Transfer-Encoding
and Content-Length
- Intermediary buffers and re-encodes request bodies
- Disable backend keep-alive between the intermediary and Ember
NVD description
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.
org.http4s:http4s-ember-core_2.12의 다른 취약점
모두 보기 →Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free