CVE-2026-55951

Erlang/OTP's httpc HTTP client (inets) does not bound the total size of HTTP response headers: the max_header_size option defaults to nolimit and httpc_response:parse_headers/6 accumulates every header into a list before the length check runs, which only happens after the terminating CRLF CRLF is received. No authentication or user interaction is required; any server the client connects to, including a malicious, compromised, redirect-targeted, or man-in-the-middle server, can trigger the flaw by sending an arbitrarily large number of headers or headers with very large values. The result is unbounded memory growth in the client process until the host runs out of memory or the BEAM VM crashes, giving the attacker denial of service; a proof-of-concept server sending 100,000 headers of roughly 4,000 bytes each forced over 13 GB of allocation in under 30 seconds. Any application calling httpc:request/4,5 against untrusted servers is affected on OTP 17.0 up to (excluding) 27.3.4.17, OTP 28.0 up to (excluding) 28.5.0.6, and OTP 29.0 up to (excluding) 29.0.6, matching inets 5.10-9.3.2.7, 9.4-9.6.2.3, and 9.7-9.7.2 (status of releases before OTP 17.0/inets 5.10 is unknown). Exploitation has not been observed: no public proof of concept is known, the flaw is not in CISA KEV, and EPSS estimates only a 0.4% (32nd-percentile) probability of exploitation within 30 days.

What to do: Upgrade Erlang/OTP to 27.3.4.17, 28.5.0.6, or 29.0.6 (equivalently inets 9.3.2.7, 9.6.2.3, or 9.7.2). Until patched, review every code path where httpc:request/4,5 fetches from attacker-reachable or untrusted URLs (including redirect targets) and set an explicit finite max_header_size as a partial mitigation, noting that because the length check runs late, upgrading is the only complete fix.