CVE-2026-66357: Erlang/OTP httpd Request Smuggling Vulnerability

CVE-2026-66357 Overview

CVE-2026-66357 is an HTTP request smuggling vulnerability in the Erlang/OTP inetshttpd HTTP server. The server never implemented obs-fold header continuation lines defined in RFC 2616 §2.2 and RFC 7230 §3.2.4. Every CRLF followed by a non-CRLF octet unconditionally starts a new header. When httpd sits behind a proxy that interprets obs-fold differently, an attacker can craft requests that the two components parse inconsistently, enabling request smuggling [CWE-444].

Critical Impact
Attackers can smuggle HTTP requests past front-end proxies, bypassing security controls, poisoning caches, and hijacking user sessions on httpd-backed applications.

Affected Products

Erlang/OTP from OTP 17.0 before OTP 27.3.4.17 (inets 5.10 before 9.3.2.7)
Erlang/OTP from OTP 28.0 before OTP 28.5.0.6 (inets 9.4 before 9.6.2.3)
Erlang/OTP from OTP 29.0 before OTP 29.0.6 (inets 9.7 before 9.7.2)

Discovery Timeline

2026-09-01 - CVE-2026-66357 published to NVD
2026-09-01 - Last updated in NVD database

Technical Details for CVE-2026-66357

Vulnerability Analysis

The Erlang/OTP inetshttpd module parses HTTP headers by treating every CRLF sequence as a hard header boundary. RFC 7230 §3.2.4 deprecated obs-fold, which allowed a header value to continue on the next line when that line began with a space or horizontal tab. Modern guidance requires servers to reject or normalize obs-fold, not silently split it.

Because httpd did neither, a folded header value from a compliant proxy would be interpreted as a new header by httpd. An attacker who controls request content sent through a differentially-parsing intermediary can therefore desynchronize the request stream between proxy and backend. This is the classic pattern behind HTTP request smuggling attacks.

Root Cause

The root cause is a missing branch in the header parser at lib/inets/src/http_server/httpd_request.erl. The parse_headers/7 function had no clause matching a CRLF followed by SP or TAB. Any such continuation line was consumed as the start of a new header name, producing a header structure that disagrees with the front-end proxy's view of the same request.

Attack Vector

Exploitation requires the target httpd instance to be reachable through an HTTP intermediary such as a reverse proxy, load balancer, or CDN that tolerates or normalizes obs-fold. The attacker sends a single crafted request whose folded header is interpreted one way by the proxy and another way by httpd. The resulting desynchronization can smuggle a second request, poison the shared connection, or bypass proxy-enforced authentication and WAF rules.

erlang

     %% If ?CR is is missing RFC2616 section-19.3 
     parse_headers(<<?CR,?LF, Octet, Rest/binary>>, Header, Headers, Current, Max,
 		  Options, Result); 
+parse_headers(<<?CR, ?LF, Obs:8, _/binary>>, _, _, _, _, _, Result) when
+          Obs =:= ?SP;
+          Obs =:= ?TAB ->
+        HttpVersion = lists:nth(3, lists:reverse(Result)),
+        {error, {bad_request, 400, "obs-fold not supported"}, HttpVersion};
 parse_headers(<<?CR,?LF, Octet, Rest/binary>>, Header, Headers, Current, Max,
 	      Options, Result) ->
     case http_request:key_value(lists:reverse(Header)) of

Source: GitHub OTP Commit 220d618. The patch adds a guarded clause that returns HTTP 400 when the parser sees CRLF followed by space or tab, aligning httpd with RFC 9112.

Detection Methods for CVE-2026-66357

Indicators of Compromise

HTTP requests containing header values that continue on the next line starting with a space or horizontal tab.
httpd access logs showing pairs of requests where the second request URI appears embedded in the first request's header block.
Unexpected 400 Bad Request responses referencing obs-fold not supported after patching, indicating attempted or legacy folded traffic.
Cache entries or session responses served to clients whose requests never legitimately reached the smuggled resource.

Detection Strategies

Inspect raw request captures for \r\n[\\x20\\x09] sequences inside header sections before the terminating \r\n\r\n.
Correlate front-end proxy request logs with httpd request logs and alert on divergent request counts or method/path mismatches on the same connection.
Deploy WAF or reverse-proxy signatures that reject requests containing obs-fold continuations at the edge.

Monitoring Recommendations

Track the Erlang/OTP and inets versions running on all HTTP-facing hosts and flag versions below 27.3.4.17, 28.5.0.6, and 29.0.6.
Monitor for spikes in 400 responses from httpd following deployment of the fix, which can surface upstream clients still emitting folded headers.
Alert on cache poisoning symptoms such as identical anomalous responses served to multiple client IPs from a shared upstream.

How to Mitigate CVE-2026-66357

Immediate Actions Required

Upgrade Erlang/OTP to 27.3.4.17, 28.5.0.6, or 29.0.6 depending on your current major version.
If upgrading is not immediately possible, place httpd behind a proxy configured to strip or reject obs-fold header continuations.
Audit all applications built on inetshttpd for exposure through shared proxies, CDNs, or load balancers.

Patch Information

The Erlang Ecosystem Foundation published fixes across three release lines. The corrective commits are 220d618, 273d895, and e640d599. Full details are in GitHub Security Advisory GHSA-qh2f-33hj-37qf and the CNA advisory.

Workarounds

Configure the upstream reverse proxy (for example, nginx or HAProxy) to reject requests containing \r\n followed by whitespace inside the header block.
Terminate TLS and normalize HTTP at a compliant intermediary that enforces RFC 9112 header parsing before forwarding to httpd.
Disable public exposure of inetshttpd endpoints that do not require internet reachability until the patch is applied.

bash

# nginx example: drop requests with obs-fold header continuations before they reach httpd
http {
    map $http_upgrade $obs_fold_block {
        default 0;
    }
    server {
        listen 443 ssl;
        if ($request ~ "\r\n[ \t]") { return 400; }
        location / {
            proxy_http_version 1.1;
            proxy_pass http://erlang_httpd_backend;
        }
    }
}