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.
Other sources
inets, httpd: HTTP Request Smuggling via Transfer-Encoding and Content-Length
— Microsoft
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 26.2.5.21-6 - Upgrade
Upgrade
debian/erlangto a version that resolves this vulnerability.Fixed in 1:29.0.6+dfsg-1Fixed in 1:29.1.1+dfsg-1 - Upgrade
Upgrade
OTP/inetsto a version that resolves this vulnerability.Fixed in 27.3.4.17 - Upgrade
Upgrade
OTP/inetsto a version that resolves this vulnerability.Fixed in 28.5.0.6 - Upgrade
Upgrade
OTP/inetsto a version that resolves this vulnerability.Fixed in 29.0.6
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.