CVE-2026-73812: inets, httpd: HTTP Request Smuggling via Transfer-Encoding and Content-Length
httpd function checkheader/3 rejects duplicate Content-Length (per CVE-2026-23941) but never checks for the TE+CL co-presence that RFC 9112 §6.3 identifies as a probable smuggling attempt. handlebody/3 frames by chunked and silently discards Content-Length. A CL-preferring front-end paired with chunked-preferring inets creates a classic CL.TE front-end/back-end desync.
This issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.
Affected Software
Event History
Frequently Asked Questions
Which deployments are realistically exposed to this issue?
Deployments using the affected inets httpd as a back end behind a front end or proxy that prefers Content-Length framing are exposed to a CL.TE request desynchronization condition. The issue depends on this parsing mismatch; the provided data does not establish exposure for standalone httpd deployments or front ends that handle framing the same way.
What does an attacker need to send to exploit the condition?
An attacker needs to send an HTTP request containing both Transfer-Encoding and Content-Length headers. The front end must frame the request using Content-Length while inets httpd frames it as chunked and discards Content-Length.
Are default configurations known to be affected?
The provided information does not state whether a default deployment includes a CL-preferring front end in front of inets httpd. Exposure is configuration-dependent because the vulnerable desynchronization requires differing front-end and back-end request-framing behavior.
How can I determine whether my deployment needs remediation?
Identify the OTP or inets version running your httpd service and compare it with the affected ranges: OTP 17.0 through before 27.3.4.17, OTP 28.0 through before 28.5.0.6, or OTP 29.0 through before 29.0.6; corresponding inets ranges are 5.10 through before 9.3.2.7, 9.4 through before 9.6.2.3, and 9.7 through before 9.7.2. Also determine whether a reverse proxy or other front end accepts requests for this backend and prefers Content-Length when both headers are present.
What can be done if upgrading is not immediately possible?
Ensure the front end rejects HTTP requests that contain both Transfer-Encoding and Content-Length before forwarding them to inets httpd. This removes the TE+CL ambiguity required for the described CL.TE desynchronization.