http4s Ember EUVD-2026-79025

Server-side exploitation requires ALL of: (1) ember-server (http4s-ember-core <= 0.23.34, or >= 1.0.0-M1 and <= 1.0.0-M46) acting as the origin; (2) a keep-alive intermediary/reverse proxy in front of it; (3) that intermediary forwarding a request carrying BOTH Transfer-Encoding and Content-Length headers rather than rejecting it (RFC 9112 permits rejection but many proxies forward); and (4) the intermediary framing the body by Content-Length while Ember frames by chunked (the CL.TE mismatch). Client-side desync additionally requires a malicious or compromised upstream server sending both headers to ember-client over a pooled connection. LIMITING FACTORS: a standalone Ember server with no fronting proxy is not exploitable; intermediaries that strictly reject dual-framed requests, buffer-and-re-encode bodies, or disable backend keep-alive fully mitigate (these are the documented workarounds). This deployment-topology dependency is exactly what the CVSS 4.0 AT:P (attack requirements) metric encodes.

This is a genuine but conditionally-exploitable HTTP request smuggling flaw (CWE-444) in http4s Ember. The vendor CVSS 4.0 score of 9.2 (VC:H/VI:H) reflects worst-case impact - front-end ACL bypass, cross-user request hijack, and cache poisoning - but the vector's AT:P (attack requirements present) is the critical qualifier: exploitation is NOT possible against a standalone Ember deployment. It requires ember-server to sit behind a keep-alive intermediary that itself forwards messages carrying both Transfer-Encoding and Content-Length AND frames the body by Content-Length while Ember frames by chunked (CL.TE desync). SSVC data corroborates the nuance: Exploitation=none (no observed exploitation), Automatable=no (each target's proxy chain must be probed), but Technical Impact=total. No EPSS score, no KEV listing, and no public exploit code are present in the input, so this is not confirmed actively exploited - it is a high-impact-if-preconditions-met issue rather than a mass-exploited emergency. The PR:N is legitimate (unauthenticated on the server path), but the AT:P requirement and 'no/none' SSVC signals mean real-world priority is moderate-to-high for organizations running Ember behind a permissive proxy, and low for those not matching that topology.

An unauthenticated attacker sends a single crafted HTTP/1.1 request containing both a Transfer-Encoding: chunked and a Content-Length header to a front-end proxy that forwards it over a keep-alive backend connection to ember-server. The proxy frames the body by Content-Length and treats part of the payload as one request, while Ember frames it as chunked, leaving a smuggled request prefix on the shared socket that concatenates with the next victim's request - bypassing the proxy's ACLs, capturing victim headers, or poisoning a downstream cache. No public exploit code is identified in the provided data, though request smuggling of this class is well-understood and straightforward to reproduce once the proxy/Ember framing mismatch is confirmed.