CVE-2026-70399

Erlang/OTP's inets httpd web server fails to enforce its documented max_clients connection limit, allowing an unauthenticated remote attacker to exhaust server resources by opening and holding open a very large number of connections. The flaw is in the accept gate (httpd_manager:handle_new_connection/4), which looks up max_clients with the two-argument httpd_util:lookup/2; when the option is not explicitly configured this returns the atom undefined rather than the documented default of 150, and because Erlang term ordering places every integer before every atom, the Count =< Max guard always passes and no connection is ever rejected. Merely establishing the connections is sufficient - no valid HTTP request, authentication, or user interaction is required - and each held connection occupies a worker process and a socket, driving the node toward process, memory, and file descriptor exhaustion (availability impact only). Any deployment running inets httpd on the affected OTP versions that does not set max_clients explicitly is exposed, while servers that configure the option explicitly enforce it correctly and are unaffected. No public proof-of-concept, KEV listing, or known exploitation has been reported; EPSS estimates roughly a 0.5% probability of exploitation within 30 days.

What to do: Upgrade to OTP 27.3.4.17, 28.5.0.6, or 29.0.6 as applicable to your branch (corresponding to inets 9.3.2.7, 9.6.2.3, or 9.7.2). As an interim mitigation, explicitly set max_clients in the httpd server configuration, since a configured value is enforced correctly, and consider placing connection rate limits or a reverse proxy/firewall in front of exposed httpd instances. Audit which deployments actually start inets httpd and whether they are internet-reachable, as exposure requires the httpd service to be running.