Erlang OTP inets CVE-2026-73276

Exploitation requires two simultaneous conditions: the target must run a vulnerable Erlang/OTP inets HTTP server (OTP 22.2 through 29.0 before patched versions), AND the inets server must be deployed behind a front-end proxy or load balancer whose HTTP header parsing behavior differs from inets' behavior of silently discarding headers with whitespace before the colon. The root misbehavior - treating RFC-violating headers as ignorable rather than request-terminating - is what creates the desynchronization opportunity exploited by the attacker. Exploitation is not possible against inets servers directly accessible to clients with no proxy intermediary, because there is no second system to disagree on request boundaries and create the smuggling channel. No authentication is required (PR:N) and no user interaction is needed (UI:N), but the proxy topology dependency reflected as AT:P in the CVSS 4.0 vector is the decisive limiting factor for real-world exploitability.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:H/VA:N) scores 8.3, reflecting network-accessible, unauthenticated exploitation with high integrity impact. The critical modifier is AT:P - attack requirements present - which formally encodes that exploitation requires a proxy or load balancer in front of inets whose header-parsing behavior diverges from inets' lenient approach. No EPSS data or CISA KEV listing was provided in the input, so exploitation probability cannot be quantified beyond the CVSS signal; the absence of both signals is consistent with no public exploit currently existing. Organizations running inets-backed services directly exposed to clients with no proxy intermediary face the underlying parsing flaw but not the smuggling risk, as the attack depends entirely on the ambiguity introduced between two systems with inconsistent interpretations. The high integrity score (VI:H) accurately reflects the potential impact when the proxy-topology condition is met - request smuggling can enable security control bypass, session hijacking, and cache poisoning - making this a high-priority patch for any operator using inets behind a reverse proxy or WAF.

An attacker targeting a web application backed by a vulnerable inets HTTP server sends a crafted HTTP request through a front-end reverse proxy, where a header such as 'Content-Length : 8' with a space before the colon is interpreted differently by the proxy and the origin server. The proxy may strip or reject the header while inets silently ignores it, creating an ambiguous request boundary that desynchronizes the two systems' view of where the request ends. The attacker exploits this desynchronization to smuggle a malicious prefix into a subsequent legitimate user's request, potentially hijacking their session or bypassing access controls. No public exploit code has been identified at time of analysis.