CVE-2026-73812

Erlang/OTP's inets httpd server fails to reject requests carrying both a Transfer-Encoding header and a Content-Length header, and its body handler (handle_body/3) frames the body using chunked encoding while silently discarding the Content-Length value, even though check_header/3 already rejects duplicate Content-Length headers (per CVE-2026-23941). When such requests pass through a front-end proxy, load balancer, or WAF that prefers Content-Length, the front-end and httpd disagree on where the request body ends, producing a classic CL.TE front-end/back-end desync (CWE-444). An attacker who triggers this desync can smuggle requests past the front-end, potentially bypassing access controls, poisoning caches, or hijacking other users' requests on the connection, which is reflected in the CVSS 4.0 score of 8.3 with high integrity impact (VI:H) and no privileges or user interaction required. Affected users are deployments running inets httpd within Erlang/OTP 17.0 and later in the specified ranges, particularly as a back-end behind a CL-preferring front-end. No public proof-of-concept, in-the-wild exploitation, or CISA KEV listing is known, and EPSS currently assigns a 0.3% probability of exploitation within 30 days.

What to do: Upgrade Erlang/OTP to at least OTP 27.3.4.17, OTP 28.5.0.6, or OTP 29.0.6 (inets 9.3.2.7, 9.6.2.3, and 9.7.2 respectively), matching your release line. Until patched, mitigate by having front-end proxies, load balancers, or WAFs reject or normalize requests containing both Transfer-Encoding and Content-Length headers. Audit whether inets httpd is used as a back-end behind CL-preferring proxies, caches, or access-control front-ends, since desync there could allow smuggled requests to bypass controls or poison caches.