CVE-2026-69204 in Http4s
Summary
by MITRE • 09/15/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
Http4s serves as a prominent functional HTTP library for the Scala programming language, providing robust interfaces for building web services and clients. Within this ecosystem, Ember acts as the primary HTTP server and client implementation, designed with performance and correctness in mind. However, prior to versions 0.23.35 and 1.0.0-M47, a critical protocol compliance flaw existed within the Ember HTTP/1.1 parser that violated fundamental rules of message framing defined by RFC 9112. Specifically, the implementation failed to reject incoming messages that contained both Transfer-Encoding and Content-Length headers simultaneously. This oversight creates an ambiguity in how the body length is determined, as these two fields represent conflicting methods for defining payload boundaries. According to standard HTTP specifications, if a message contains a Transfer-Encoding header field, it overrides any Content-Length header present, but many implementations strictly prohibit their coexistence to prevent parsing ambiguities that can be exploited by attackers.
The operational impact of this vulnerability is severe when Ember operates behind an intermediary proxy or load balancer that maintains persistent connections via HTTP keep-alive mechanisms. In such architectures, the intermediary may forward requests and responses based on Content-Length headers while ignoring Transfer-Encoding directives, whereas the downstream Ember server might interpret the message differently due to its flawed parsing logic. This discrepancy allows for HTTP request smuggling attacks, where an unauthenticated attacker can inject a second malicious request into the same connection stream. By carefully crafting a payload that includes both conflicting headers, the attacker tricks the intermediary and the backend server into disagreeing on where one request ends and another begins. This desynchronization enables the attacker to bypass access controls, as the intermediary may process the smuggled request while Ember processes it differently or ignores it entirely.
Beyond direct service disruption, this vulnerability facilitates cache poisoning attacks in environments utilizing shared HTTP caches. If an intermediary forwards a response based on Content-Length but the backend server interprets headers differently due to the presence of Transfer-Encoding, the cached content can be manipulated by an attacker. This leads to users receiving malicious or corrupted responses that were intended for other requests. Furthermore, when Ember-client is involved, a malicious or compromised upstream server sending both headers can cause connection desynchronization in the shared response parser. This state confusion allows attackers to hijack subsequent legitimate requests sent over the same persistent connection, potentially leading to data exfiltration or unauthorized actions performed under the victim's authentication context.
From a classification perspective, this vulnerability aligns with CWE-436, which denotes Interpretation Conflict, as well as CWE-707, improper enforcement of message integrity during transmission. In terms of offensive security tactics, it maps directly to MITRE ATT&CK technique T1105, specifically the HTTP Request Smuggling sub-tactic, and potentially T1078 for bypassing access controls through protocol manipulation. The root cause lies in a failure to strictly enforce RFC compliance regarding header precedence and mutual exclusivity of framing mechanisms. To mitigate this risk, organizations must upgrade Http4s to version 0.23.35 or later, including the 1.0.0-M47 milestone release where these parsing rules were corrected to explicitly reject messages containing both headers. Additionally, security teams should review intermediary configurations to ensure they do not forward conflicting headers and consider implementing strict input validation at the network edge to drop malformed HTTP requests before they reach application servers.