## Summary
CVE-2026-69217 affects http4s Ember’s HTTP/1.1 parser: when duplicate Content-Length headers with differing values are present, Ember accepts the last value instead of rejecting the request. In deployments behind a keep-alive intermediary that frames on a different Content-Length occurrence, this enables unauthenticated HTTP request smuggling (CL.CL desync) that can bypass front-end controls, hijack cross-user requests, or poison caches.
## Technical Details
- Root issue: Ember’s HTTP/1.1 parsing behavior for Content-Length is not strict when multiple headers are present.
- RFC requirement: RFC 9112 §6.3 states differing Content-Length values are an unrecoverable framing error; recipients should respond 400 and close the connection.
- Exploit condition (server side):
- Ember server is behind an intermediary that keeps persistent connections.
- The intermediary forwards at least two differing Content-Length headers without rejecting.
- The intermediary frames on a different occurrence than Ember (“anything other than last-wins”).
- Resulting attacks:
- Front-end security bypass: smuggled request reaches paths blocked by the intermediary.
- Cross-user request hijack: dangling smuggled prefix concatenates with the next victim’s request on the shared backend socket, capturing sensitive headers (e.g., Cookie/Authorization).
- Cache poisoning: smuggled response is associated with the next request key in a caching proxy.
- Client-side note: the same parser can misframe responses when the client is a proxy shared across multiple downstream consumers; upstream must be malicious/compromised.
Patch evidence:
- The fix adds validation that Content-Length must be digits-only and rejects invalid/duplicate values (e.g., DuplicateContentLength, InvalidContentLength) in private[ember] object Parser.
## Affected
- http4s Ember Server versions prior to 0.23.35 and 1.0.0-M47.
- Any EmberServerBuilder HTTP/1.1 configuration deployed behind an intermediary that does not reject differing duplicate Content-Length.
## Impact
- Unauthenticated request smuggling (CL.CL desync) enabling:
- front-end security bypass
- cross-user request hijack
- cache poisoning
- Client-side impact is narrower: requires a malicious/compromised upstream and a shared pooled proxy client across downstream consumers.
## Mitigation
1. Upgrade http4s to 0.23.35 or 1.0.0-M47 (patch is addressed in http4s-0.23.35).
2. If upgrading is not immediately possible, ensure the intermediary is strictly RFC-compliant and rejects differing duplicate Content-Length with 400.
3. Review deployments using keep-alive intermediaries and pooled/shared proxy clients, especially where front-end controls rely on intermediary filtering.
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N
CWE-444