CVE-2026-69217: Http4s HTTP/1.1 Parser Auth Bypass Flaw

CVE-2026-69217 Overview

CVE-2026-69217 is an HTTP request smuggling vulnerability in http4s, a Scala interface for HTTP services. The Ember HTTP/1.1 parser accepts messages containing differing duplicate Content-Length headers and uses the last value instead of rejecting the request. When an Ember server sits behind a keep-alive intermediary that selects a different Content-Length occurrence, an unauthenticated attacker can construct CL.CL request smuggling attacks. The shared client parser also misframes responses from a malicious or compromised upstream when the client acts as a proxy for multiple downstream consumers. This flaw is tracked as CWE-444 and is fixed in versions 0.23.35 and 1.0.0-M47.

Critical Impact

Unauthenticated attackers can bypass front-end security controls, capture headers from later user requests, or poison shared caches in deployments using Ember behind keep-alive proxies.

Affected Products

• http4s Ember server versions prior to 0.23.35
• http4s Ember server versions prior to 1.0.0-M47
• http4s Ember client acting as a proxy for multiple downstream consumers

Discovery Timeline

• 2026-09-15 - CVE-2026-69217 published to NVD
• 2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-69217

Vulnerability Analysis

The defect lives in the Ember HTTP/1.1 message parser inside ember-core. When a request or response contains multiple Content-Length headers with differing values, the parser accepts the message and uses the last observed value. RFC 7230 requires servers to reject such messages or reduce them to a single validated value.

If a front-end intermediary picks the first Content-Length value while Ember picks the last, the two nodes disagree on where one HTTP message ends and the next begins. On a shared keep-alive connection, this framing disagreement lets an attacker inject a second, smuggled request that the back-end treats as a distinct message.

On the client side, the same shared parser misframes responses from an upstream that emits conflicting Content-Length headers. When an http4s client fans out responses to multiple downstream consumers, one consumer can receive body bytes intended for another.

Root Cause

The parser did not validate the Content-Length header against the strict grammar 1*DIGIT and did not reject requests carrying conflicting duplicate Content-Length headers. Instead of returning a 400 Bad Request, Ember silently reconciled the discrepancy by selecting the last value.

Attack Vector

Exploitation requires a network-reachable Ember server deployed behind a keep-alive intermediary that resolves duplicate Content-Length headers differently than Ember does. An unauthenticated attacker sends a crafted HTTP/1.1 request containing two Content-Length headers with different values. The intermediary and Ember disagree on message boundaries, letting the attacker smuggle a request. The smuggled request can bypass front-end authentication and authorization, poison a shared cache, or capture headers from the next legitimate user on the same upstream connection.

// Security patch excerpt: ember-core/shared/src/main/scala/org/http4s/ember/core/Parser.scala
 import cats.syntax.all._
 import fs2._
 import org.http4s._
+import org.http4s.internal.CharPredicate
 import org.typelevel.ci.CIString
 import scodec.bits.ByteVector

Source: http4s commit 24e8d34. The fix introduces CharPredicate to validate Content-Length as 1*DIGIT and rejects conflicting duplicates rather than accepting the last value.

Detection Methods for CVE-2026-69217

Indicators of Compromise

• HTTP/1.1 requests containing two or more Content-Length headers with differing values reaching Ember-based services.
• Access logs showing back-end requests with methods, paths, or hosts that were never emitted by the front-end proxy.
• Cache entries whose bodies do not correspond to the cached URL, indicating cache poisoning.
• Downstream consumers of an http4s client proxy receiving response bodies of unexpected length or content type.

Detection Strategies

• Inspect front-end proxy and Ember access logs for requests that contain duplicate Content-Length headers or a Content-Length header combined with Transfer-Encoding: chunked.
• Deploy inline traffic inspection that compares request boundaries computed at the proxy against those observed at the origin.
• Run active smuggling test suites (for example CL.CL and CL.TE probes) against staging environments running Ember to confirm parser behavior.

Monitoring Recommendations

• Alert when HTTP request parsers emit 400 responses for header validation on Ember versions 0.23.35 or 1.0.0-M47 and later, indicating attempted smuggling.
• Monitor keep-alive connection reuse patterns and flag connections where response-to-request correlation breaks.
• Track dependency inventories for org.http4s:http4s-ember-server and org.http4s:http4s-ember-client versions across build pipelines.

How to Mitigate CVE-2026-69217

Immediate Actions Required

• Upgrade http4s to 0.23.35 on the 0.23.x line or 1.0.0-M47 on the 1.0 milestone line.
• Rebuild and redeploy every service that transitively depends on http4s-ember-server or http4s-ember-client.
• Audit intermediary configurations (reverse proxies, load balancers, CDNs) to ensure they reject or normalize duplicate Content-Length headers.

Patch Information

The fix is delivered in http4s v0.23.35 and http4s v1.0.0-M47. Technical details are described in GitHub Security Advisory GHSA-p83c-4wj9-p6w9. The parser change is committed in 24e8d34e3ea89f8f23e0053ec9944f6467e8086d and validates Content-Length against the 1*DIGIT grammar while rejecting conflicting duplicates.

Workarounds

• Configure the upstream proxy or web application firewall to drop any HTTP/1.1 message that contains multiple Content-Length headers or both Content-Length and Transfer-Encoding.
• Disable HTTP keep-alive between the front-end intermediary and Ember origins until the upgrade is complete, accepting the performance cost.
• Restrict the shared http4s client from proxying responses to multiple downstream consumers on the same connection.

# Example sbt dependency pinning for the fixed release
libraryDependencies ++= Seq(
  "org.http4s" %% "http4s-ember-server" % "0.23.35",
  "org.http4s" %% "http4s-ember-client" % "0.23.35"
)