CVE-2026-73812: Erlang inets HTTP request smuggling via Transfer-Encoding and Content-Length

CVE-2026-73812 · Severity: info · CVSS 8.3 · Published 2026-09-01

Erlang's inets HTTP server fails to detect simultaneous Transfer-Encoding and Content-Length headers in the same request, a condition that RFC 9112 flags as a probable smuggling attack. When a reverse proxy or load balancer (favoring Content-Length) sits in front of an inets server (favoring Transfer-Encoding chunked encoding), an attacker can craft malicious requests that are parsed differently at each layer, potentially smuggling injected requests past security controls or poisoning HTTP caches to serve malicious content to other users.

Technologies: Erlang Inets, Erlang OTP. Vendors: Erlang.

Quick answers

Is CVE-2026-73812 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-73812 being exploited in the wild.
How severe is CVE-2026-73812?
Informational severity, with a CVSS score of 8.3, published 1 September 2026.
Which products and versions are affected?
Erlang Inets 5.10 to 9.3.2.6, 9.4 to 9.6.2.2, 9.7 to 9.7.1; Erlang OTP 17.0 to 27.3.4.16, 28.0 to 28.5.0.5, 29.0 to 29.0.5.
Is there a fix for CVE-2026-73812?
A patch was published on 2026-09-01: Patches released for OTP 27.3.4.17, 28.5.0.6, and 29.0.6 Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-73812 attacked?
It is attacked over the network.
Am I affected by CVE-2026-73812?
Check whether you run Erlang Inets or Erlang OTP at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

Technical details

The vulnerability is an HTTP request smuggling flaw (CWE-444) in Erlang's inets httpd module. The root cause is that the check_header/3 function rejects only duplicate Content-Length headers (a fix for CVE-2026-23941) but does not validate the RFC 9112 §6.3 requirement that Transfer-Encoding and Content-Length must not both be present. The handle_body/3 function frames requests by Transfer-Encoding: chunked and silently discards the Content-Length header. When a CL-preferring front-end (e.g., a reverse proxy) is paired with a TE-preferring inets backend, an attacker can send a crafted request with both headers; the front-end interprets the Content-Length boundary while the backend uses the chunked encoding, desynchronizing the parsing and allowing the attacker to inject a second request that only the backend processes. The vulnerability is fixed in OTP 27.3.4.17, 28.5.0.6, and 29.0.6 (inets 9.3.2.7, 9.6.2.3, and 9.7.2 respectively).

Affected products

  • Erlang OTP 17.0 to 27.3.4.16, 28.0 to 28.5.0.5, 29.0 to 29.0.5
  • Erlang inets 5.10 to 9.3.2.6, 9.4 to 9.6.2.2, 9.7 to 9.7.1

Timeline

  • 2026-09-01: disclosed
  • 2026-09-01: patched: Patches released for OTP 27.3.4.17, 28.5.0.6, and 29.0.6

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.