{"id":"CVE-2026-69664","aliases":["AZL-98466","DEBIAN-CVE-2026-69664","EEF-CVE-2026-69664","EUVD-2026-69381","GHSA-mr35-8h7w-w3gq","OESA-2026-4131","OESA-2026-4132","OESA-2026-4133","RHSA-2026:62531","UBUNTU-CVE-2026-69664","USN-8827-1"],"status":"published","title":"httpd parks a request worker indefinitely on a malformed chunk size sent after the headers","description":"Missing Release of Resource after Effective Lifetime vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by sending a request with a chunked body whose chunk-size line is not a hexadecimal number. The worker serving the connection is never released and no timeout reclaims it, so repeating the request across connections occupies every available worker and denies service to legitimate clients. No authentication is required and the default configuration is affected.\n\nThe chunk-size line must arrive in a write separate from the headers. When the body accompanies the headers, httpd_request_handler:handle_body/3 calls http_chunk:decode/3 inside a try ... catch throw:Error, so the {error, {chunk_size, _}} thrown by http_chunk:decode_size/4 is answered with 400 Bad Request. When the chunk size arrives later, the decoder is resumed through a bare catch in httpd_request_handler:handle_info/2, which converts the throw into a return value rather than raising it; the resulting error tuple is then treated as the next decoder continuation, the socket is re-armed, and the worker waits for data that never comes. The request timeout has already been cancelled at the point the headers were accepted, and the periodic byte-rate check is only armed when minimum_bytes_per_second is configured, which it is not by default.\n\nThis issue affects OTP from OTP 18.1.4 before OTP 27.3.4.17, OTP 28.5.0.6, and OTP 29.0.6, corresponding to inets from 6.0.3 before 9.3.2.7, 9.6.2.3, and 9.7.2.","severity":{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00949,"percentile":0.61469,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-772"],"published":"2026-09-01T14:59:03Z","modified":"2026-11-05T05:40:51Z","fixes":[{"ecosystem":"Azure Linux:3","package":"erlang","fixed_in":["26.2.5.21-6"],"sources":["osv"]},{"ecosystem":"Debian:13","package":"erlang","fixed_in":["1:27.3.4.1+dfsg-1+deb13u4"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"erlang","fixed_in":["1:29.0.6+dfsg-1"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:14.04:LTS","package":"erlang","fixed_in":["1:16.b.3-dfsg-1ubuntu2.2+esm2"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:16.04:LTS","package":"erlang","fixed_in":["1:18.3-dfsg-1ubuntu3.1+esm3"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:18.04:LTS","package":"erlang","fixed_in":["1:20.2.2+dfsg-1ubuntu2+esm3"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:20.04:LTS","package":"erlang","fixed_in":["1:22.2.7+dfsg-1ubuntu0.5+esm2"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"erlang","fixed_in":["1:24.2.1+dfsg-1ubuntu0.7"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"erlang","fixed_in":["1:25.3.2.8+dfsg-1ubuntu4.7"],"sources":["osv"]},{"ecosystem":"Ubuntu:26.04:LTS","package":"erlang","fixed_in":["1:27.3.4.6+dfsg-1ubuntu0.1"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Azure Linux:3","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"26.2.5.21-6"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1:25.2.3+dfsg-1","1:25.2.3+dfsg-1+deb12u1","1:25.2.3+dfsg-1+deb12u2","1:25.2.3+dfsg-1+deb12u3","1:25.2.3+dfsg-1+deb12u4","1:25.3.2.10+dfsg-1","1:25.3.2.10+dfsg-2","1:25.3.2.11+dfsg-1","1:25.3.2.12+dfsg-1","1:25.3.2.12+dfsg-2","1:25.3.2.12+dfsg-3","1:25.3.2.8+dfsg-1","1:26.0+dfsg-1","1:26.0.1+dfsg-1","1:26.0.2+dfsg-1","1:26.0~rc2+dfsg-1","1:26.0~rc3+dfsg-1","1:26.1.2+dfsg-1","1:26.2.1+dfsg-1","1:26.2.4+dfsg-1","1:27.0+dfsg-1","1:27.0.1+dfsg-1","1:27.0.1+dfsg-2","1:27.0.1+dfsg-3","1:27.0~rc3+dfsg-1","1:27.0~rc3+dfsg-2","1:27.0~rc3+dfsg-3","1:27.0~rc3+dfsg-4","1:27.1.2+dfsg-1","1:27.2+dfsg-1","1:27.2+dfsg-2","1:27.2+dfsg-3~exp1","1:27.2.1+dfsg-1","1:27.2.1+dfsg-2","1:27.2.2+dfsg-1","1:27.2.3+dfsg-1","1:27.2.4+dfsg-1","1:27.3+dfsg-1","1:27.3.1+dfsg-1","1:27.3.2+dfsg-1","1:27.3.3+dfsg-1","1:27.3.4+dfsg-1","1:27.3.4.1+dfsg-1","1:27.3.4.10+dfsg-1","1:27.3.4.11+dfsg-1","1:27.3.4.11+dfsg-2","1:27.3.4.11+dfsg-3","1:27.3.4.11+dfsg-4","1:27.3.4.11+dfsg-5","1:27.3.4.11+dfsg-6","1:27.3.4.11+dfsg-7","1:27.3.4.12+dfsg-1","1:27.3.4.3+dfsg-1","1:27.3.4.4+dfsg-1","1:27.3.4.6+dfsg-1","1:27.3.4.8+dfsg-1","1:27.3.4.9+dfsg-1","1:28.0+dfsg-1","1:28.0.1+dfsg-1","1:28.0.2+dfsg-1","1:28.0.4+dfsg-1","1:28.1.1+dfsg-1","1:28.2+dfsg-1","1:28.3+dfsg-1","1:28.3.1+dfsg-1","1:29.0+dfsg-1","1:29.0+dfsg-2","1:29.0.1+dfsg-1","1:29.0.2+dfsg-1","1:29.0.3+dfsg-1","1:29.0.4+dfsg-1","1:29.0.6+dfsg-1","1:29.0~rc1+dfsg-1","1:29.0~rc1+dfsg-2","1:29.0~rc2+dfsg-1","1:29.0~rc3+dfsg-1","1:29.0~rc3+dfsg-2","1:29.0~rc3+dfsg-3","1:29.0~rc3+dfsg-4","1:29.1.1+dfsg-1"]},{"source":"osv","ecosystem":"Debian:13","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:27.3.4.1+dfsg-1+deb13u4"}]}],"versions":["1:27.3.4.1+dfsg-1","1:27.3.4.1+dfsg-1+deb13u1","1:27.3.4.1+dfsg-1+deb13u2","1:27.3.4.1+dfsg-1+deb13u3"]},{"source":"osv","ecosystem":"Debian:14","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:29.0.6+dfsg-1"}]}],"versions":["1:27.3.4.1+dfsg-1","1:27.3.4.10+dfsg-1","1:27.3.4.11+dfsg-1","1:27.3.4.11+dfsg-2","1:27.3.4.11+dfsg-3","1:27.3.4.11+dfsg-4","1:27.3.4.11+dfsg-5","1:27.3.4.11+dfsg-6","1:27.3.4.11+dfsg-7","1:27.3.4.12+dfsg-1","1:27.3.4.3+dfsg-1","1:27.3.4.4+dfsg-1","1:27.3.4.6+dfsg-1","1:27.3.4.8+dfsg-1","1:27.3.4.9+dfsg-1","1:28.0+dfsg-1","1:28.0.1+dfsg-1","1:28.0.2+dfsg-1","1:28.0.4+dfsg-1","1:28.1.1+dfsg-1","1:28.2+dfsg-1","1:28.3+dfsg-1","1:28.3.1+dfsg-1","1:29.0+dfsg-1","1:29.0+dfsg-2","1:29.0.1+dfsg-1","1:29.0.2+dfsg-1","1:29.0.3+dfsg-1","1:29.0.4+dfsg-1","1:29.0~rc1+dfsg-1","1:29.0~rc1+dfsg-2","1:29.0~rc2+dfsg-1","1:29.0~rc3+dfsg-1","1:29.0~rc3+dfsg-2","1:29.0~rc3+dfsg-3","1:29.0~rc3+dfsg-4"]},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP1","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"25.3.2.6-20.oe2403sp1"}]}],"bundled":15},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP3","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"25.3.2.6-20.oe2403sp3"}]}],"bundled":15},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP4","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"25.3.2.6-20.oe2403sp4"}]}],"bundled":15},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-asn1","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-common_test","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-compiler","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-crypto","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-debugger","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-dialyzer","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-diameter","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-edoc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-eldap","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-erl_interface","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-erts","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-et","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-eunit","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-examples","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-ftp","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-gdb-tools","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-inets","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-jinterface","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-kernel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-megaco","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-mnesia","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-observer","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-odbc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-os_mon","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-parsetools","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-public_key","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-reltool","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-runtime_tools","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-sasl","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-snmp","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-ssh","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-ssl","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-stdlib","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-syntax_tools","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-tftp","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-tools","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-wx","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"erlang27-xmerl","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:27.3.4.17-0.1.hum1"}]}],"bundled":8},{"source":"osv","ecosystem":"Ubuntu:Pro:14.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:16.b.3-dfsg-1ubuntu2.2+esm2"}]}],"versions":["1:16.b.1-dfsg-4ubuntu1","1:16.b.2-dfsg-1ubuntu1","1:16.b.2-dfsg-2ubuntu1","1:16.b.3-dfsg-1ubuntu1","1:16.b.3-dfsg-1ubuntu2","1:16.b.3-dfsg-1ubuntu2.1","1:16.b.3-dfsg-1ubuntu2.2","1:16.b.3-dfsg-1ubuntu2.2+esm1"]},{"source":"osv","ecosystem":"Ubuntu:Pro:16.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:18.3-dfsg-1ubuntu3.1+esm3"}]}],"versions":["1:18.0-dfsg-1ubuntu1","1:18.0-dfsg-1ubuntu2","1:18.2-dfsg-2ubuntu1","1:18.3-dfsg-1ubuntu1","1:18.3-dfsg-1ubuntu2","1:18.3-dfsg-1ubuntu3","1:18.3-dfsg-1ubuntu3.1","1:18.3-dfsg-1ubuntu3.1+esm1","1:18.3-dfsg-1ubuntu3.1+esm2"]},{"source":"osv","ecosystem":"Ubuntu:Pro:18.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:20.2.2+dfsg-1ubuntu2+esm3"}]}],"versions":["1:20.0.4+dfsg-1ubuntu1","1:20.1.2+dfsg-1ubuntu1","1:20.1.3+dfsg-1ubuntu1","1:20.1.4+dfsg-1ubuntu1","1:20.1.5+dfsg-1ubuntu1","1:20.1.6+dfsg-1ubuntu1","1:20.1.7+dfsg-1ubuntu1","1:20.2.1+dfsg-1ubuntu1","1:20.2.2+dfsg-1ubuntu1","1:20.2.2+dfsg-1ubuntu2","1:20.2.2+dfsg-1ubuntu2+esm1","1:20.2.2+dfsg-1ubuntu2+esm2"]},{"source":"osv","ecosystem":"Ubuntu:Pro:20.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:22.2.7+dfsg-1ubuntu0.5+esm2"}]}],"versions":["1:22.0.7+dfsg-1build1","1:22.2+dfsg-1","1:22.2.1+dfsg-1","1:22.2.2+dfsg-1","1:22.2.3+dfsg-1","1:22.2.3+dfsg-2","1:22.2.4+dfsg-1","1:22.2.7+dfsg-1","1:22.2.7+dfsg-1ubuntu0.2","1:22.2.7+dfsg-1ubuntu0.3","1:22.2.7+dfsg-1ubuntu0.4","1:22.2.7+dfsg-1ubuntu0.5","1:22.2.7+dfsg-1ubuntu0.5+esm1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:24.2.1+dfsg-1ubuntu0.7"}]}],"versions":["1:23.2.6+dfsg-1build1","1:24.1.1+dfsg-1","1:24.1.4+dfsg-1","1:24.1.5+dfsg-1","1:24.1.5+dfsg-1ubuntu1","1:24.2+dfsg-1","1:24.2.1+dfsg-1","1:24.2.1+dfsg-1ubuntu0.1","1:24.2.1+dfsg-1ubuntu0.2","1:24.2.1+dfsg-1ubuntu0.3","1:24.2.1+dfsg-1ubuntu0.4","1:24.2.1+dfsg-1ubuntu0.5","1:24.2.1+dfsg-1ubuntu0.6"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:25.3.2.8+dfsg-1ubuntu4.7"}]}],"versions":["1:25.2.3+dfsg-1","1:25.3.2.8+dfsg-1","1:25.3.2.8+dfsg-1ubuntu1","1:25.3.2.8+dfsg-1ubuntu3","1:25.3.2.8+dfsg-1ubuntu4","1:25.3.2.8+dfsg-1ubuntu4.1","1:25.3.2.8+dfsg-1ubuntu4.2","1:25.3.2.8+dfsg-1ubuntu4.3","1:25.3.2.8+dfsg-1ubuntu4.4","1:25.3.2.8+dfsg-1ubuntu4.5","1:25.3.2.8+dfsg-1ubuntu4.6"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:27.3.4.6+dfsg-1ubuntu0.1"}]}],"versions":["1:27.3.4.1+dfsg-1build1","1:27.3.4.3+dfsg-1","1:27.3.4.4+dfsg-1","1:27.3.4.6+dfsg-1"]},{"source":"osv","ecosystem":"Ubuntu:Pro:14.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:16.b.3-dfsg-1ubuntu2.2+esm2"}]}],"versions":["1:16.b.1-dfsg-4ubuntu1","1:16.b.2-dfsg-1ubuntu1","1:16.b.2-dfsg-2ubuntu1","1:16.b.3-dfsg-1ubuntu1","1:16.b.3-dfsg-1ubuntu2","1:16.b.3-dfsg-1ubuntu2.1","1:16.b.3-dfsg-1ubuntu2.2","1:16.b.3-dfsg-1ubuntu2.2+esm1"],"bundled":19},{"source":"osv","ecosystem":"Ubuntu:Pro:16.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:18.3-dfsg-1ubuntu3.1+esm3"}]}],"versions":["1:18.0-dfsg-1ubuntu1","1:18.0-dfsg-1ubuntu2","1:18.2-dfsg-2ubuntu1","1:18.3-dfsg-1ubuntu1","1:18.3-dfsg-1ubuntu2","1:18.3-dfsg-1ubuntu3","1:18.3-dfsg-1ubuntu3.1","1:18.3-dfsg-1ubuntu3.1+esm1","1:18.3-dfsg-1ubuntu3.1+esm2"],"bundled":19},{"source":"osv","ecosystem":"Ubuntu:Pro:18.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:20.2.2+dfsg-1ubuntu2+esm3"}]}],"versions":["1:20.0.4+dfsg-1ubuntu1","1:20.1.2+dfsg-1ubuntu1","1:20.1.3+dfsg-1ubuntu1","1:20.1.4+dfsg-1ubuntu1","1:20.1.5+dfsg-1ubuntu1","1:20.1.6+dfsg-1ubuntu1","1:20.1.7+dfsg-1ubuntu1","1:20.2.1+dfsg-1ubuntu1","1:20.2.2+dfsg-1ubuntu1","1:20.2.2+dfsg-1ubuntu2","1:20.2.2+dfsg-1ubuntu2+esm1","1:20.2.2+dfsg-1ubuntu2+esm2"],"bundled":19},{"source":"osv","ecosystem":"Ubuntu:Pro:20.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:22.2.7+dfsg-1ubuntu0.5+esm2"}]}],"versions":["1:22.0.7+dfsg-1build1","1:22.2+dfsg-1","1:22.2.1+dfsg-1","1:22.2.2+dfsg-1","1:22.2.3+dfsg-1","1:22.2.3+dfsg-2","1:22.2.4+dfsg-1","1:22.2.7+dfsg-1","1:22.2.7+dfsg-1ubuntu0.2","1:22.2.7+dfsg-1ubuntu0.3","1:22.2.7+dfsg-1ubuntu0.4","1:22.2.7+dfsg-1ubuntu0.5","1:22.2.7+dfsg-1ubuntu0.5+esm1"],"bundled":19},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:24.2.1+dfsg-1ubuntu0.7"}]}],"versions":["1:23.2.6+dfsg-1build1","1:24.1.1+dfsg-1","1:24.1.4+dfsg-1","1:24.1.5+dfsg-1","1:24.1.5+dfsg-1ubuntu1","1:24.2+dfsg-1","1:24.2.1+dfsg-1","1:24.2.1+dfsg-1ubuntu0.1","1:24.2.1+dfsg-1ubuntu0.2","1:24.2.1+dfsg-1ubuntu0.3","1:24.2.1+dfsg-1ubuntu0.4","1:24.2.1+dfsg-1ubuntu0.5","1:24.2.1+dfsg-1ubuntu0.6"],"bundled":19},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:25.3.2.8+dfsg-1ubuntu4.7"}]}],"versions":["1:25.2.3+dfsg-1","1:25.3.2.8+dfsg-1","1:25.3.2.8+dfsg-1ubuntu1","1:25.3.2.8+dfsg-1ubuntu3","1:25.3.2.8+dfsg-1ubuntu4","1:25.3.2.8+dfsg-1ubuntu4.1","1:25.3.2.8+dfsg-1ubuntu4.2","1:25.3.2.8+dfsg-1ubuntu4.3","1:25.3.2.8+dfsg-1ubuntu4.4","1:25.3.2.8+dfsg-1ubuntu4.5","1:25.3.2.8+dfsg-1ubuntu4.6"],"bundled":19},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:27.3.4.6+dfsg-1ubuntu0.1"}]}],"versions":["1:27.3.4.1+dfsg-1build1","1:27.3.4.3+dfsg-1","1:27.3.4.4+dfsg-1","1:27.3.4.6+dfsg-1"],"bundled":19}],"products":[{"vendor":"erlang","product":"otp"}],"references":[{"url":"https://github.com/erlang/otp/security/advisories/GHSA-mr35-8h7w-w3gq","tags":["related","vendor-advisory","exploit","advisory","article","report"]},{"url":"https://cna.erlef.org/cves/CVE-2026-69664.html","tags":["related","web","article","report"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-69664","tags":["related","web","article","report"]},{"url":"https://www.erlang.org/doc/system/versions.html#order-of-versions","tags":["x_version-scheme","web","article","report"]},{"url":"https://github.com/erlang/otp/commit/77acb473d8f056f6f534395f131c6e45693797f0","tags":["related","fix","web"]},{"url":"https://github.com/erlang/otp/commit/a3adf63078438c86527d704e23282b7721d8ca12","tags":["patch","fix","article","report"]},{"url":"https://github.com/erlang/otp/commit/df1a9ca4666e2fdfc44886bfaae76de086d803f6","tags":["patch","fix","article","report"]},{"url":"https://github.com/erlang/otp/commit/bd4e74348c6be8a49f060da6fd48d43f3a960292","tags":["patch","fix","article","report"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-69664","tags":["web","advisory"]},{"url":"https://github.com","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/69xxx/CVE-2026-69664.json","tags":["advisory"]},{"url":"https://github.com/erlang/otp","tags":["package"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-69664","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4131","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-55951","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-59696","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-66357","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-66835","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-70399","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-70405","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-70409","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-71380","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-71562","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-73270","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-73276","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74835","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74994","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-75538","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4132","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4133","tags":["advisory"]},{"url":"https://access.redhat.com/errata/RHSA-2026:62531","tags":["advisory"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-74835","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-70399","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-66835","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-74994","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-70409","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-73270","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-73812","tags":["report"]},{"url":"https://images.redhat.com/","tags":["article"]},{"url":"https://access.redhat.com/security/updates/classification/","tags":["article"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-69664","tags":["report"]},{"url":"https://security.access.redhat.com/data/csaf/v2/advisories/2026/rhsa-2026_62531.json","tags":["advisory"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2526849","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-66835","tags":["advisory"]},{"url":"https://cna.erlef.org/cves/CVE-2026-66835.html","tags":["article"]},{"url":"https://github.com/erlang/otp/commit/9641944a2efbf55bea760f8ff7ba777fe3a0961c","tags":["article"]},{"url":"https://github.com/erlang/otp/commit/bac19eb3dbd96cc49b6d8cabc1c04248bf8c79f6","tags":["article"]},{"url":"https://github.com/erlang/otp/commit/d8878dec0ececc2eab18e47bb18b472f224ca633","tags":["article"]},{"url":"https://github.com/erlang/otp/security/advisories/GHSA-r4vv-vc2c-2fw6","tags":["article"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-66835","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2526864","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-69664","tags":["advisory","report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2526832","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-70399","tags":["advisory"]},{"url":"https://cna.erlef.org/cves/CVE-2026-70399.html","tags":["article"]},{"url":"https://github.com/erlang/otp/commit/6746dc4e1df5257ad8ac91cbbd167cb8b0274ce7","tags":["article"]},{"url":"https://github.com/erlang/otp/commit/d94a94c96eb4cccbd6f7d7da5975f0c035b69612","tags":["article"]},{"url":"https://github.com/erlang/otp/commit/e0050fc00c500a4fa9ba1f594603c787ff6d20b2","tags":["article"]},{"url":"https://github.com/erlang/otp/security/advisories/GHSA-pwvh-c689-f8q5","tags":["article"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-70399","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2526853","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-70409","tags":["advisory"]},{"url":"https://cna.erlef.org/cves/CVE-2026-70409.html","tags":["article"]},{"url":"https://github.com/erlang/otp/commit/aba0fe8c2d700bf4ac94607cf7f00e53bbe4042d","tags":["article"]},{"url":"https://github.com/erlang/otp/commit/e3be1cfe9f6cedd0cd20d9905e05601dfb31c8aa","tags":["article"]},{"url":"https://github.com/erlang/otp/security/advisories/GHSA-9vgh-c8cm-m9p4","tags":["article"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-70409","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2526846","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-73270","tags":["advisory"]},{"url":"https://cna.erlef.org/cves/CVE-2026-73270.html","tags":["article"]},{"url":"https://github.com/erlang/otp/security/advisories/GHSA-mh78-93cr-jx8f","tags":["article"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-73270","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2526827","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-73812","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-73812","tags":["advisory"]},{"url":"https://cna.erlef.org/cves/CVE-2026-73812.html","tags":["article"]},{"url":"https://github.com/erlang/otp/commit/591dc00dc99dc2a426167a3b5257c0c94bd45e91","tags":["article"]},{"url":"https://github.com/erlang/otp/security/advisories/GHSA-7j6m-4ffg-hg46","tags":["article"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-73812","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2526842","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-74835","tags":["advisory"]},{"url":"https://cna.erlef.org/cves/CVE-2026-74835.html","tags":["article"]},{"url":"https://github.com/erlang/otp/commit/0bceff0c2987cae83d9d4a77c5ecacd6d01b8b86","tags":["article"]},{"url":"https://github.com/erlang/otp/commit/7f9c460d1818c2afb78fbd01f8d8b81343bbb011","tags":["article"]},{"url":"https://github.com/erlang/otp/commit/8e1ca42b64df6c41306affbe8dc129bdbd4042c7","tags":["article"]},{"url":"https://github.com/erlang/otp/security/advisories/GHSA-8qrh-x566-5xv5","tags":["article"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-74835","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2526857","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-74994","tags":["advisory"]},{"url":"https://cna.erlef.org/cves/CVE-2026-74994.html","tags":["article"]},{"url":"https://github.com/erlang/otp/commit/6101cb74ff2870718c622ba7af0c100f7f2524e3","tags":["article"]},{"url":"https://github.com/erlang/otp/commit/6982e381137ede21a4e1faf5fa2dd82321691176","tags":["article"]},{"url":"https://github.com/erlang/otp/commit/c5ccec8ed25c70ec6557fd81277e4b2f52285c19","tags":["article"]},{"url":"https://github.com/erlang/otp/security/advisories/GHSA-c3cq-q8x6-547g","tags":["article"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-74994","tags":["article"]},{"url":"https://ubuntu.com/security/CVE-2026-69664","tags":["report"]},{"url":"https://ubuntu.com/security/notices/USN-8827-1","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2026-23941","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-42792","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-54890","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-55737","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-55951","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-55953","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-58227","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-59250","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-59251","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-66357","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-66835","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-70399","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-71380","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-73270","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-73276","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-73812","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-74835","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-75538","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2026-69664","title":"httpd parks a request worker indefinitely on a malformed chunk size sent after the headers","description":"Missing Release of Resource after Effective Lifetime vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by sending a request with a chunked body whose chunk-size line is not a hexadecimal number. The worker serving the connection is never released and no timeout reclaims it, so repeating the request across connections occupies every available worker and denies service to legitimate clients. No authentication is required and the default configuration is affected.\n\nThe chunk-size line must arrive in a write separate from the headers. When the body accompanies the headers, httpd_request_handler:handle_body/3 calls http_chunk:decode/3 inside a try ... catch throw:Error, so the {error, {chunk_size, _}} thrown by http_chunk:decode_size/4 is answered with 400 Bad Request. When the chunk size arrives later, the decoder is resumed through a bare catch in httpd_request_handler:handle_info/2, which converts the throw into a return value rather than raising it; the resulting error tuple is then treated as the next decoder continuation, the socket is re-armed, and the worker waits for data that never comes. The request timeout has already been cancelled at the point the headers were accepted, and the periodic byte-rate check is only armed when minimum_bytes_per_second is configured, which it is not by default.\n\nThis issue affects OTP from OTP 18.1.4 before OTP 27.3.4.17, OTP 28.5.0.6, and OTP 29.0.6, corresponding to inets from 6.0.3 before 9.3.2.7, 9.6.2.3, and 9.7.2.","status":"published","published":"2026-09-01T14:59:03.512Z","modified":"2026-09-22T09:10:07.55Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high","assessor":"cna"}],"cwes":["CWE-772"],"updated_at":"2026-11-02T13:50:27.582139Z"}],"euvd":[{"id":"EUVD-2026-69381","description":"Missing Release of Resource after Effective Lifetime vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by sending a request with a chunked body whose chunk-size line is not a hexadecimal number. The worker serving the connection is never released and no timeout reclaims it, so repeating the request across connections occupies every available worker and denies service to legitimate clients. No authentication is required and the default configuration is affected.\n\nThe chunk-size line must arrive in a write separate from the headers. When the body accompanies the headers, httpd_request_handler:handle_body/3 calls http_chunk:decode/3 inside a try ... catch throw:Error, so the {error, {chunk_size, _}} thrown by http_chunk:decode_size/4 is answered with 400 Bad Request. When the chunk size arrives later, the decoder is resumed through a bare catch in httpd_request_handler:handle_info/2, which converts the throw into a return value rather than raising it; the resulting error tuple is then treated as the next decoder continuation, the socket is re-armed, and the worker waits for data that never comes. The request timeout has already been cancelled at the point the headers were accepted, and the periodic byte-rate check is only armed when minimum_bytes_per_second is configured, which it is not by default.\n\nThis issue affects OTP from OTP 18.1.4 before OTP 27.3.4.17, OTP 28.5.0.6, and OTP 29.0.6, corresponding to inets from 6.0.3 before 9.3.2.7, 9.6.2.3, and 9.7.2.","status":"published","published":"2026-09-01T14:59:03Z","modified":"2026-09-22T09:10:07Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"updated_at":"2026-11-02T17:28:03.79222Z"}],"nvd":[{"id":"CVE-2026-69664","description":"Missing Release of Resource after Effective Lifetime vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by sending a request with a chunked body whose chunk-size line is not a hexadecimal number. The worker serving the connection is never released and no timeout reclaims it, so repeating the request across connections occupies every available worker and denies service to legitimate clients. No authentication is required and the default configuration is affected.\n\nThe chunk-size line must arrive in a write separate from the headers. When the body accompanies the headers, httpd_request_handler:handle_body/3 calls http_chunk:decode/3 inside a try ... catch throw:Error, so the {error, {chunk_size, _}} thrown by http_chunk:decode_size/4 is answered with 400 Bad Request. When the chunk size arrives later, the decoder is resumed through a bare catch in httpd_request_handler:handle_info/2, which converts the throw into a return value rather than raising it; the resulting error tuple is then treated as the next decoder continuation, the socket is re-armed, and the worker waits for data that never comes. The request timeout has already been cancelled at the point the headers were accepted, and the periodic byte-rate check is only armed when minimum_bytes_per_second is configured, which it is not by default.\n\nThis issue affects OTP from OTP 18.1.4 before OTP 27.3.4.17, OTP 28.5.0.6, and OTP 29.0.6, corresponding to inets from 6.0.3 before 9.3.2.7, 9.6.2.3, and 9.7.2.","status":"published","published":"2026-09-01T15:17:23.677Z","modified":"2026-09-22T10:17:09.61Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"}],"cwes":["CWE-772"],"updated_at":"2026-11-02T14:12:43.04945Z"}],"osv":[{"id":"CVE-2026-69664","title":"httpd parks a request worker indefinitely on a malformed chunk size sent after the headers","description":"Missing Release of Resource after Effective Lifetime vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by sending a request with a chunked body whose chunk-size line is not a hexadecimal number. The worker serving the connection is never released and no timeout reclaims it, so repeating the request across connections occupies every available worker and denies service to legitimate clients. No authentication is required and the default configuration is affected.\n\nThe chunk-size line must arrive in a write separate from the headers. When the body accompanies the headers, httpd_request_handler:handle_body/3 calls http_chunk:decode/3 inside a try ... catch throw:Error, so the {error, {chunk_size, _}} thrown by http_chunk:decode_size/4 is answered with 400 Bad Request. When the chunk size arrives later, the decoder is resumed through a bare catch in httpd_request_handler:handle_info/2, which converts the throw into a return value rather than raising it; the resulting error tuple is then treated as the next decoder continuation, the socket is re-armed, and the worker waits for data that never comes. The request timeout has already been cancelled at the point the headers were accepted, and the periodic byte-rate check is only armed when minimum_bytes_per_second is configured, which it is not by default.\n\nThis issue affects OTP from OTP 18.1.4 before OTP 27.3.4.17, OTP 28.5.0.6, and OTP 29.0.6, corresponding to inets from 6.0.3 before 9.3.2.7, 9.6.2.3, and 9.7.2.","status":"published","published":"2026-09-01T14:59:03.512Z","modified":"2026-10-28T02:30:57.871667747Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-772"],"updated_at":"2026-11-02T15:45:15.164658Z"},{"id":"DEBIAN-CVE-2026-69664","description":"Missing Release of Resource after Effective Lifetime vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by sending a request with a chunked body whose chunk-size line is not a hexadecimal number. The worker serving the connection is never released and no timeout reclaims it, so repeating the request across connections occupies every available worker and denies service to legitimate clients. No authentication is required and the default configuration is affected.  The chunk-size line must arrive in a write separate from the headers. When the body accompanies the headers, httpd_request_handler:handle_body/3 calls http_chunk:decode/3 inside a try ... catch throw:Error, so the {error, {chunk_size, _}} thrown by http_chunk:decode_size/4 is answered with 400 Bad Request. When the chunk size arrives later, the decoder is resumed through a bare catch in httpd_request_handler:handle_info/2, which converts the throw into a return value rather than raising it; the resulting error tuple is then treated as the next decoder continuation, the socket is re-armed, and the worker waits for data that never comes. The request timeout has already been cancelled at the point the headers were accepted, and the periodic byte-rate check is only armed when minimum_bytes_per_second is configured, which it is not by default.  This issue affects OTP from OTP 18.1.4 before OTP 27.3.4.17, OTP 28.5.0.6, and OTP 29.0.6, corresponding to inets from 6.0.3 before 9.3.2.7, 9.6.2.3, and 9.7.2.","status":"published","published":"2026-09-01T15:17:23.677Z","modified":"2026-10-23T06:01:10.700218937Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high"}],"updated_at":"2026-11-02T15:46:02.094661Z"},{"id":"EEF-CVE-2026-69664","title":"httpd parks a request worker indefinitely on a malformed chunk size sent after the headers","description":"## Summary\n\nMissing Release of Resource after Effective Lifetime vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by sending a request with a chunked body whose chunk-size line is not a hexadecimal number. The worker serving the connection is never released and no timeout reclaims it, so repeating the request across connections occupies every available worker and denies service to legitimate clients. No authentication is required and the default configuration is affected.\n\nThe chunk-size line must arrive in a write separate from the headers. When the body accompanies the headers, `httpd_request_handler:handle_body/3` calls `http_chunk:decode/3` inside a `try ... catch throw:Error`, so the `{error, {chunk_size, _}}` thrown by `http_chunk:decode_size/4` is answered with `400 Bad Request`. When the chunk size arrives later, the decoder is resumed through a bare `catch` in `httpd_request_handler:handle_info/2`, which converts the throw into a return value rather than raising it; the resulting error tuple is then treated as the next decoder continuation, the socket is re-armed, and the worker waits for data that never comes. The request timeout has already been cancelled at the point the headers were accepted, and the periodic byte-rate check is only armed when `minimum_bytes_per_second` is configured, which it is not by default.\n\nThis issue affects OTP from OTP 18.1.4 before OTP 27.3.4.17, OTP 28.5.0.6, and OTP 29.0.6, corresponding to inets from 6.0.3 before 9.3.2.7, 9.6.2.3, and 9.7.2.\n\n## Workarounds\n\n* Set `minimum_bytes_per_second` in the httpd configuration, for example `{minimum_bytes_per_second, 200}`. This arms a periodic byte-rate check that terminates a connection which has stopped delivering data, reclaiming the parked worker within a few seconds. The check is disabled by default, and any positive value suffices because an affected connection delivers no further data at all.\n* Place a reverse proxy in front of httpd that validates chunked transfer encoding and rejects malformed chunk framing before it reaches httpd.\n* Restrict access to the server to trusted clients where the deployment allows it.","status":"published","published":"2026-09-01T14:59:03.512Z","modified":"2026-09-22T09:15:03.032764305Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-772"],"updated_at":"2026-11-02T15:46:33.520522Z"},{"id":"OESA-2026-4131","title":"erlang security update","description":"Erlang is a general-purpose programming language and runtime environment. Erlang has built-in support for concurrency, distribution and fault tolerance. Erlang is used in several large telecommunication systems from Ericsson.\r\n\r\nSecurity Fix(es):\n\nThe Erlang/OTP httpc HTTP client does not enforce a limit on the total size of response headers received from a server. 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 fires after the terminating CRLF CRLF is received).\n\nA malicious or compromised HTTP server can send an arbitrarily large number of headers, or headers with very large values, causing the client process to allocate unbounded memory until the system runs out of memory or the BEAM VM crashes. A proof-of-concept server sending 100,000 headers of roughly 4000 bytes each caused the client VM to allocate over 13 GB of memory in under 30 seconds.\n\nAny application using httpc:request/4,5 to connect to untrusted servers is affected. No authentication is required: any server the client connects to (including via a redirect or man-in-the-middle) can trigger the exhaustion.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-55951)\n\nImproper Validation of Specified Quantity in Input vulnerability in Erlang/OTP stdlib allows a remote attacker to degrade availability by supplying a URI whose port component is a very long run of digits.\n\nuri_string:get_port/1 passes the port substring to binary_to_integer/1 with no length bound, catching only error:badarg, so a syntactically valid port of up to roughly 1.26 million digits converts successfully and costs the calling process hundreds of milliseconds of arbitrary-precision arithmetic. The conversion is reached from every authority-parsing path in uri_string:parse/1, including the host, registered-name, and IPv4 and IPv6 forms. parse/1 is the documented interface for parsing URIs, so any application that parses an attacker-supplied URI is exposed without further configuration. The conversion function is documented to accept integers of any size, so bounding the input is the caller\u0026apos;s responsibility.\n\nThis issue affects OTP from OTP 21.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to stdlib from 3.5 before 6.2.2.5, from 7.0 before 7.3.0.2, and from 8.0 before 8.0.4.(CVE-2026-59696)\n\nhttpd has never implemented obs-fold (RFC 2616 §2.2 / RFC 7230 §3.2.4 header continuation lines). Every CRLF followed by a non-CRLF octet unconditionally starts a new header. This missing feature became a security concern as the understanding of HTTP request smuggling attacks evolved.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-66357)\n\nPath Equivalence vulnerability in Erlang/OTP inets httpd allows a remote unauthenticated attacker to read files inside a mod_auth protected directory by prefixing the request path with an extra slash.\n\nhttpd_request:validate_uri/1 normalises the request URI with uri_string:normalize/1, which performs RFC 3986 dot-segment removal but does not collapse empty path segments, so a doubled slash survives. mod_alias:real_name/3 concatenates the document root with that URI, and mod_auth:secret_path/3 then decides whether the result lies inside a protected directory block by running the configured directory path as an unanchored regular expression against it. The doubled slash breaks the contiguous substring the regex needs, so the request is treated as unprotected and no authentication challenge is issued, while mod_get opens the same path and the operating system collapses the doubled slash and returns the protected file. The same path mismatch also evades the per-path accounting in mod_security.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-66835)\n\nMissing Release of Resource after Effective Lifetime vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by sending a request with a chunked body whose chunk-size line is not a hexadecimal number. The worker serving the connection is never released and no timeout reclaims it, so repeating the request across connections occupies every available worker and denies service to legitimate clients. No authentication is required and the default configuration is affected.(CVE-2026-69664)\n\nAllocation of Resources Without Limits or Throttling vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by opening and holding open a large number of connections. The max_clients option is documented to default to 150, and the inets hardening guide presents that limit as the first layer of denial-of-service defence, but a server that does not set it explicitly accepts an unlimited number of simultaneous connections. Establishing the connections is sufficient; no valid request and no authentication are required.\n\nThe accept gate in httpd_manager:handle_new_connection/4 reads the option with httpd_util:lookup/2, which returns undefined when the key is absent, rather than the three-argument form carrying the 150 default that the neighbouring get_ustate/2 uses. Erlang term ordering places every integer before every atom, so the Count =\u0026lt; Max guard holds for any connection count and the server never returns {reject, busy}. Each accepted connection occupies a worker process and a socket for as long as it is held, driving the node towards process, memory and file descriptor exhaustion. Servers that set max_clients explicitly are unaffected, because a configured value is applied as intended.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2.(CVE-2026-70399)\n\nImproper Validation of Specified Quantity in Input vulnerability in Erlang/OTP snmp allows a remote attacker to degrade availability by sending an SNMP message containing a BER INTEGER whose length field is arbitrarily large.\n\nsnmp_pdus:dec_integer_notag/1 defaults its size limit to infinity, and do_dec_integer_notag/2 then accumulates the value across every declared byte with a recursive shift and bitwise or. Work grows superlinearly in the declared length because each operation acts on a progressively larger bignum. The size-limited variant dec_integer_notag/2 exists but is reached from only one call site, dec_snmp_version/1, which bounds the version field to ten bytes; the request identifier, error status and index, generic and specific trap fields, engine boots and time, and every varbind value decoded by dec_value/1 all use the unbounded form. The decode runs before the PDU is processed, so no valid request is required beyond what the deployment demands to accept the message at all.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to snmp from 4.25.1 before 5.18.2.1, from 5.19 before 5.20.2.2, and from 5.20.3 before 5.20.5. Whether OTP before OTP 17.0, corresponding to snmp before 4.25.1, is affected is unknown.(CVE-2026-70405)\n\nImproper Validation of Specified Quantity in Input vulnerability in Erlang/OTP eldap allows a malicious or compromised LDAP server to degrade availability by returning a referral URL whose port component is a very long run of digits.\n\neldap:parse_port/2 passes the port substring straight to list_to_integer/1 with no length bound. The surrounding try ... catch only rejects a value that fails to parse, so a syntactically valid port of up to roughly 1.26 million digits converts successfully and costs the caller hundreds of milliseconds of arbitrary-precision arithmetic per referral. The conversion function itself is documented to accept integers of any size, so bounding the input is the caller\u0026apos;s responsibility. Reaching the flaw requires the application to pass a server-supplied referral to eldap:parse_ldap_url/1, which eldap never calls itself: referral strings are returned to the caller unparsed.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to eldap from 1.0.3 before 1.2.14.2, from 1.2.15 before 1.2.16.1, and from 1.3 before 1.3.1.(CVE-2026-70409)\n\nMissing Release of Resource after Effective Lifetime vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by sending valid request headers with a large Content-Length and then stalling before the body is complete.\n\nhttpd_request_handler:handle_info/2 cancels the request timeout as soon as a parse step succeeds, which includes the headers, and the clause that handles a decoder asking for more data re-arms the socket with {active, once} without setting any further timer. httpd_request:whole_body/2 returns such a continuation whenever the bytes received are fewer than the announced Content-Length, so a well-formed request that stops mid-body leaves the worker waiting indefinitely. The periodic byte-rate check that would reclaim it is armed only when minimum_bytes_per_second is configured, which it is not by default. Repeating this across connections occupies every worker permitted by max_clients and denies service to legitimate clients at negligible bandwidth cost.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-71380)\n\nImproper Validation of Specified Quantity in Input vulnerability in Erlang/OTP inets httpc allows a malicious or compromised HTTP server to degrade availability by returning a numeric header whose value is a very long run of digits.\n\nhttpc_handler.erl converts the server-supplied Content-Length with list_to_integer/1 before comparing it against max_body_size, so the size check cannot protect the conversion, and the option defaults to nolimit in any case. The same unbounded conversion appears in httpc_response:format_response/1 for Content-Length and in httpc_response:get_ms_from_retry_after/1 for Retry-After, which is guarded only by a check that the first character is a digit. A value of up to roughly 1.26 million digits converts successfully and costs the requesting process hundreds of milliseconds of arbitrary-precision arithmetic per response. The conversion function is documented to accept integers of any size, so bounding the input is the caller\u0026apos;s responsibility.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-71562)\n\nImproper Handling of Case Sensitivity vulnerability in Erlang/OTP inets httpd allows a remote unauthenticated attacker to read files inside a mod_auth protected directory by requesting them with different casing, on deployments whose filesystem is case-insensitive.\n\nmod_auth:secret_path/3 decides whether a resolved filesystem path lies inside a protected directory block by running the configured directory path through re:run/3 without the caseless option. A request for /secret/file against a directory configured as /Secret therefore does not match, so the request is treated as unprotected and no authentication challenge is issued, while the filesystem resolves the differently cased path to the same file and mod_get serves it. Deployments on case-sensitive filesystems are unaffected, because there the filesystem itself rejects the mismatched casing.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-73270)\n\nGracefulness code ignored cases that should be rejected, resulting in possible HTTP Request Smuggling opportunities.\n\nThis issue affects OTP from OTP 22.2 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 7.1.2 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2.(CVE-2026-73276)\n\nThe inets application HTTP server httpd fails to enforce a configured body-size limit on chunked request.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-74835)\n\nThe mod_auth module in OTP\u0026apos;s inets httpd server, when configured with dets or mnesia authentication backends and multiple directory configuration blocks, collapses all directory blocks into a single shared user/group namespace. A user added to one protected directory is accepted as valid for all other protected directories on the same server instance.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-74994)\n\nAn attacker that connects to an open Erlang TCP port that uses the inet driver with {packet,4} mode can use a signed overflow in an incorrect packet length calculation to overflow the receive buffer into the VM allocator area and beyond up to about 2 GB.\\n\\nThis would easily trash the allocated block\u0026apos;s allocator metadata footer, and the next block, if any, and most likely cause the BEAM VM to crash. Utilizing this with precision enough to achieve Remote Code Execution would be extremely unfeasible.\\n\\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to erts from 6.0 before 15.2.7.13, from 16.0 before 16.4.0.6, and from 17.0 before 17.0.6. Whether OTP before OTP 17.0, corresponding to erts before 6.0, is affected is unknown.(CVE-2026-75538)","status":"published","published":"2026-09-30T13:46:54Z","modified":"2026-10-01T02:00:04.268244811Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"updated_at":"2026-11-02T15:52:47.643553Z"},{"id":"OESA-2026-4132","title":"erlang security update","description":"Erlang is a general-purpose programming language and runtime environment. Erlang has built-in support for concurrency, distribution and fault tolerance. Erlang is used in several large telecommunication systems from Ericsson.\r\n\r\nSecurity Fix(es):\n\nThe Erlang/OTP httpc HTTP client does not enforce a limit on the total size of response headers received from a server. 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 fires after the terminating CRLF CRLF is received).\n\nA malicious or compromised HTTP server can send an arbitrarily large number of headers, or headers with very large values, causing the client process to allocate unbounded memory until the system runs out of memory or the BEAM VM crashes. A proof-of-concept server sending 100,000 headers of roughly 4000 bytes each caused the client VM to allocate over 13 GB of memory in under 30 seconds.\n\nAny application using httpc:request/4,5 to connect to untrusted servers is affected. No authentication is required: any server the client connects to (including via a redirect or man-in-the-middle) can trigger the exhaustion.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-55951)\n\nImproper Validation of Specified Quantity in Input vulnerability in Erlang/OTP stdlib allows a remote attacker to degrade availability by supplying a URI whose port component is a very long run of digits.\n\nuri_string:get_port/1 passes the port substring to binary_to_integer/1 with no length bound, catching only error:badarg, so a syntactically valid port of up to roughly 1.26 million digits converts successfully and costs the calling process hundreds of milliseconds of arbitrary-precision arithmetic. The conversion is reached from every authority-parsing path in uri_string:parse/1, including the host, registered-name, and IPv4 and IPv6 forms. parse/1 is the documented interface for parsing URIs, so any application that parses an attacker-supplied URI is exposed without further configuration. The conversion function is documented to accept integers of any size, so bounding the input is the caller\u0026apos;s responsibility.\n\nThis issue affects OTP from OTP 21.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to stdlib from 3.5 before 6.2.2.5, from 7.0 before 7.3.0.2, and from 8.0 before 8.0.4.(CVE-2026-59696)\n\nhttpd has never implemented obs-fold (RFC 2616 §2.2 / RFC 7230 §3.2.4 header continuation lines). Every CRLF followed by a non-CRLF octet unconditionally starts a new header. This missing feature became a security concern as the understanding of HTTP request smuggling attacks evolved.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-66357)\n\nPath Equivalence vulnerability in Erlang/OTP inets httpd allows a remote unauthenticated attacker to read files inside a mod_auth protected directory by prefixing the request path with an extra slash.\n\nhttpd_request:validate_uri/1 normalises the request URI with uri_string:normalize/1, which performs RFC 3986 dot-segment removal but does not collapse empty path segments, so a doubled slash survives. mod_alias:real_name/3 concatenates the document root with that URI, and mod_auth:secret_path/3 then decides whether the result lies inside a protected directory block by running the configured directory path as an unanchored regular expression against it. The doubled slash breaks the contiguous substring the regex needs, so the request is treated as unprotected and no authentication challenge is issued, while mod_get opens the same path and the operating system collapses the doubled slash and returns the protected file. The same path mismatch also evades the per-path accounting in mod_security.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-66835)\n\nMissing Release of Resource after Effective Lifetime vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by sending a request with a chunked body whose chunk-size line is not a hexadecimal number. The worker serving the connection is never released and no timeout reclaims it, so repeating the request across connections occupies every available worker and denies service to legitimate clients. No authentication is required and the default configuration is affected.(CVE-2026-69664)\n\nAllocation of Resources Without Limits or Throttling vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by opening and holding open a large number of connections. The max_clients option is documented to default to 150, and the inets hardening guide presents that limit as the first layer of denial-of-service defence, but a server that does not set it explicitly accepts an unlimited number of simultaneous connections. Establishing the connections is sufficient; no valid request and no authentication are required.\n\nThe accept gate in httpd_manager:handle_new_connection/4 reads the option with httpd_util:lookup/2, which returns undefined when the key is absent, rather than the three-argument form carrying the 150 default that the neighbouring get_ustate/2 uses. Erlang term ordering places every integer before every atom, so the Count =\u0026lt; Max guard holds for any connection count and the server never returns {reject, busy}. Each accepted connection occupies a worker process and a socket for as long as it is held, driving the node towards process, memory and file descriptor exhaustion. Servers that set max_clients explicitly are unaffected, because a configured value is applied as intended.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2.(CVE-2026-70399)\n\nImproper Validation of Specified Quantity in Input vulnerability in Erlang/OTP snmp allows a remote attacker to degrade availability by sending an SNMP message containing a BER INTEGER whose length field is arbitrarily large.\n\nsnmp_pdus:dec_integer_notag/1 defaults its size limit to infinity, and do_dec_integer_notag/2 then accumulates the value across every declared byte with a recursive shift and bitwise or. Work grows superlinearly in the declared length because each operation acts on a progressively larger bignum. The size-limited variant dec_integer_notag/2 exists but is reached from only one call site, dec_snmp_version/1, which bounds the version field to ten bytes; the request identifier, error status and index, generic and specific trap fields, engine boots and time, and every varbind value decoded by dec_value/1 all use the unbounded form. The decode runs before the PDU is processed, so no valid request is required beyond what the deployment demands to accept the message at all.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to snmp from 4.25.1 before 5.18.2.1, from 5.19 before 5.20.2.2, and from 5.20.3 before 5.20.5. Whether OTP before OTP 17.0, corresponding to snmp before 4.25.1, is affected is unknown.(CVE-2026-70405)\n\nImproper Validation of Specified Quantity in Input vulnerability in Erlang/OTP eldap allows a malicious or compromised LDAP server to degrade availability by returning a referral URL whose port component is a very long run of digits.\n\neldap:parse_port/2 passes the port substring straight to list_to_integer/1 with no length bound. The surrounding try ... catch only rejects a value that fails to parse, so a syntactically valid port of up to roughly 1.26 million digits converts successfully and costs the caller hundreds of milliseconds of arbitrary-precision arithmetic per referral. The conversion function itself is documented to accept integers of any size, so bounding the input is the caller\u0026apos;s responsibility. Reaching the flaw requires the application to pass a server-supplied referral to eldap:parse_ldap_url/1, which eldap never calls itself: referral strings are returned to the caller unparsed.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to eldap from 1.0.3 before 1.2.14.2, from 1.2.15 before 1.2.16.1, and from 1.3 before 1.3.1.(CVE-2026-70409)\n\nMissing Release of Resource after Effective Lifetime vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by sending valid request headers with a large Content-Length and then stalling before the body is complete.\n\nhttpd_request_handler:handle_info/2 cancels the request timeout as soon as a parse step succeeds, which includes the headers, and the clause that handles a decoder asking for more data re-arms the socket with {active, once} without setting any further timer. httpd_request:whole_body/2 returns such a continuation whenever the bytes received are fewer than the announced Content-Length, so a well-formed request that stops mid-body leaves the worker waiting indefinitely. The periodic byte-rate check that would reclaim it is armed only when minimum_bytes_per_second is configured, which it is not by default. Repeating this across connections occupies every worker permitted by max_clients and denies service to legitimate clients at negligible bandwidth cost.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-71380)\n\nImproper Validation of Specified Quantity in Input vulnerability in Erlang/OTP inets httpc allows a malicious or compromised HTTP server to degrade availability by returning a numeric header whose value is a very long run of digits.\n\nhttpc_handler.erl converts the server-supplied Content-Length with list_to_integer/1 before comparing it against max_body_size, so the size check cannot protect the conversion, and the option defaults to nolimit in any case. The same unbounded conversion appears in httpc_response:format_response/1 for Content-Length and in httpc_response:get_ms_from_retry_after/1 for Retry-After, which is guarded only by a check that the first character is a digit. A value of up to roughly 1.26 million digits converts successfully and costs the requesting process hundreds of milliseconds of arbitrary-precision arithmetic per response. The conversion function is documented to accept integers of any size, so bounding the input is the caller\u0026apos;s responsibility.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-71562)\n\nImproper Handling of Case Sensitivity vulnerability in Erlang/OTP inets httpd allows a remote unauthenticated attacker to read files inside a mod_auth protected directory by requesting them with different casing, on deployments whose filesystem is case-insensitive.\n\nmod_auth:secret_path/3 decides whether a resolved filesystem path lies inside a protected directory block by running the configured directory path through re:run/3 without the caseless option. A request for /secret/file against a directory configured as /Secret therefore does not match, so the request is treated as unprotected and no authentication challenge is issued, while the filesystem resolves the differently cased path to the same file and mod_get serves it. Deployments on case-sensitive filesystems are unaffected, because there the filesystem itself rejects the mismatched casing.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-73270)\n\nGracefulness code ignored cases that should be rejected, resulting in possible HTTP Request Smuggling opportunities.\n\nThis issue affects OTP from OTP 22.2 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 7.1.2 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2.(CVE-2026-73276)\n\nThe inets application HTTP server httpd fails to enforce a configured body-size limit on chunked request.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-74835)\n\nThe mod_auth module in OTP\u0026apos;s inets httpd server, when configured with dets or mnesia authentication backends and multiple directory configuration blocks, collapses all directory blocks into a single shared user/group namespace. A user added to one protected directory is accepted as valid for all other protected directories on the same server instance.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-74994)\n\nAn attacker that connects to an open Erlang TCP port that uses the inet driver with {packet,4} mode can use a signed overflow in an incorrect packet length calculation to overflow the receive buffer into the VM allocator area and beyond up to about 2 GB.\\n\\nThis would easily trash the allocated block\u0026apos;s allocator metadata footer, and the next block, if any, and most likely cause the BEAM VM to crash. Utilizing this with precision enough to achieve Remote Code Execution would be extremely unfeasible.\\n\\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to erts from 6.0 before 15.2.7.13, from 16.0 before 16.4.0.6, and from 17.0 before 17.0.6. Whether OTP before OTP 17.0, corresponding to erts before 6.0, is affected is unknown.(CVE-2026-75538)","status":"published","published":"2026-09-30T13:46:55Z","modified":"2026-10-01T02:00:04.273719843Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"updated_at":"2026-11-02T15:52:47.643553Z"},{"id":"OESA-2026-4133","title":"erlang security update","description":"Erlang is a general-purpose programming language and runtime environment. Erlang has built-in support for concurrency, distribution and fault tolerance. Erlang is used in several large telecommunication systems from Ericsson.\r\n\r\nSecurity Fix(es):\n\nThe Erlang/OTP httpc HTTP client does not enforce a limit on the total size of response headers received from a server. 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 fires after the terminating CRLF CRLF is received).\n\nA malicious or compromised HTTP server can send an arbitrarily large number of headers, or headers with very large values, causing the client process to allocate unbounded memory until the system runs out of memory or the BEAM VM crashes. A proof-of-concept server sending 100,000 headers of roughly 4000 bytes each caused the client VM to allocate over 13 GB of memory in under 30 seconds.\n\nAny application using httpc:request/4,5 to connect to untrusted servers is affected. No authentication is required: any server the client connects to (including via a redirect or man-in-the-middle) can trigger the exhaustion.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-55951)\n\nImproper Validation of Specified Quantity in Input vulnerability in Erlang/OTP stdlib allows a remote attacker to degrade availability by supplying a URI whose port component is a very long run of digits.\n\nuri_string:get_port/1 passes the port substring to binary_to_integer/1 with no length bound, catching only error:badarg, so a syntactically valid port of up to roughly 1.26 million digits converts successfully and costs the calling process hundreds of milliseconds of arbitrary-precision arithmetic. The conversion is reached from every authority-parsing path in uri_string:parse/1, including the host, registered-name, and IPv4 and IPv6 forms. parse/1 is the documented interface for parsing URIs, so any application that parses an attacker-supplied URI is exposed without further configuration. The conversion function is documented to accept integers of any size, so bounding the input is the caller\u0026apos;s responsibility.\n\nThis issue affects OTP from OTP 21.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to stdlib from 3.5 before 6.2.2.5, from 7.0 before 7.3.0.2, and from 8.0 before 8.0.4.(CVE-2026-59696)\n\nhttpd has never implemented obs-fold (RFC 2616 §2.2 / RFC 7230 §3.2.4 header continuation lines). Every CRLF followed by a non-CRLF octet unconditionally starts a new header. This missing feature became a security concern as the understanding of HTTP request smuggling attacks evolved.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-66357)\n\nPath Equivalence vulnerability in Erlang/OTP inets httpd allows a remote unauthenticated attacker to read files inside a mod_auth protected directory by prefixing the request path with an extra slash.\n\nhttpd_request:validate_uri/1 normalises the request URI with uri_string:normalize/1, which performs RFC 3986 dot-segment removal but does not collapse empty path segments, so a doubled slash survives. mod_alias:real_name/3 concatenates the document root with that URI, and mod_auth:secret_path/3 then decides whether the result lies inside a protected directory block by running the configured directory path as an unanchored regular expression against it. The doubled slash breaks the contiguous substring the regex needs, so the request is treated as unprotected and no authentication challenge is issued, while mod_get opens the same path and the operating system collapses the doubled slash and returns the protected file. The same path mismatch also evades the per-path accounting in mod_security.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-66835)\n\nMissing Release of Resource after Effective Lifetime vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by sending a request with a chunked body whose chunk-size line is not a hexadecimal number. The worker serving the connection is never released and no timeout reclaims it, so repeating the request across connections occupies every available worker and denies service to legitimate clients. No authentication is required and the default configuration is affected.(CVE-2026-69664)\n\nAllocation of Resources Without Limits or Throttling vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by opening and holding open a large number of connections. The max_clients option is documented to default to 150, and the inets hardening guide presents that limit as the first layer of denial-of-service defence, but a server that does not set it explicitly accepts an unlimited number of simultaneous connections. Establishing the connections is sufficient; no valid request and no authentication are required.\n\nThe accept gate in httpd_manager:handle_new_connection/4 reads the option with httpd_util:lookup/2, which returns undefined when the key is absent, rather than the three-argument form carrying the 150 default that the neighbouring get_ustate/2 uses. Erlang term ordering places every integer before every atom, so the Count =\u0026lt; Max guard holds for any connection count and the server never returns {reject, busy}. Each accepted connection occupies a worker process and a socket for as long as it is held, driving the node towards process, memory and file descriptor exhaustion. Servers that set max_clients explicitly are unaffected, because a configured value is applied as intended.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2.(CVE-2026-70399)\n\nImproper Validation of Specified Quantity in Input vulnerability in Erlang/OTP snmp allows a remote attacker to degrade availability by sending an SNMP message containing a BER INTEGER whose length field is arbitrarily large.\n\nsnmp_pdus:dec_integer_notag/1 defaults its size limit to infinity, and do_dec_integer_notag/2 then accumulates the value across every declared byte with a recursive shift and bitwise or. Work grows superlinearly in the declared length because each operation acts on a progressively larger bignum. The size-limited variant dec_integer_notag/2 exists but is reached from only one call site, dec_snmp_version/1, which bounds the version field to ten bytes; the request identifier, error status and index, generic and specific trap fields, engine boots and time, and every varbind value decoded by dec_value/1 all use the unbounded form. The decode runs before the PDU is processed, so no valid request is required beyond what the deployment demands to accept the message at all.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to snmp from 4.25.1 before 5.18.2.1, from 5.19 before 5.20.2.2, and from 5.20.3 before 5.20.5. Whether OTP before OTP 17.0, corresponding to snmp before 4.25.1, is affected is unknown.(CVE-2026-70405)\n\nImproper Validation of Specified Quantity in Input vulnerability in Erlang/OTP eldap allows a malicious or compromised LDAP server to degrade availability by returning a referral URL whose port component is a very long run of digits.\n\neldap:parse_port/2 passes the port substring straight to list_to_integer/1 with no length bound. The surrounding try ... catch only rejects a value that fails to parse, so a syntactically valid port of up to roughly 1.26 million digits converts successfully and costs the caller hundreds of milliseconds of arbitrary-precision arithmetic per referral. The conversion function itself is documented to accept integers of any size, so bounding the input is the caller\u0026apos;s responsibility. Reaching the flaw requires the application to pass a server-supplied referral to eldap:parse_ldap_url/1, which eldap never calls itself: referral strings are returned to the caller unparsed.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to eldap from 1.0.3 before 1.2.14.2, from 1.2.15 before 1.2.16.1, and from 1.3 before 1.3.1.(CVE-2026-70409)\n\nMissing Release of Resource after Effective Lifetime vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by sending valid request headers with a large Content-Length and then stalling before the body is complete.\n\nhttpd_request_handler:handle_info/2 cancels the request timeout as soon as a parse step succeeds, which includes the headers, and the clause that handles a decoder asking for more data re-arms the socket with {active, once} without setting any further timer. httpd_request:whole_body/2 returns such a continuation whenever the bytes received are fewer than the announced Content-Length, so a well-formed request that stops mid-body leaves the worker waiting indefinitely. The periodic byte-rate check that would reclaim it is armed only when minimum_bytes_per_second is configured, which it is not by default. Repeating this across connections occupies every worker permitted by max_clients and denies service to legitimate clients at negligible bandwidth cost.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-71380)\n\nImproper Validation of Specified Quantity in Input vulnerability in Erlang/OTP inets httpc allows a malicious or compromised HTTP server to degrade availability by returning a numeric header whose value is a very long run of digits.\n\nhttpc_handler.erl converts the server-supplied Content-Length with list_to_integer/1 before comparing it against max_body_size, so the size check cannot protect the conversion, and the option defaults to nolimit in any case. The same unbounded conversion appears in httpc_response:format_response/1 for Content-Length and in httpc_response:get_ms_from_retry_after/1 for Retry-After, which is guarded only by a check that the first character is a digit. A value of up to roughly 1.26 million digits converts successfully and costs the requesting process hundreds of milliseconds of arbitrary-precision arithmetic per response. The conversion function is documented to accept integers of any size, so bounding the input is the caller\u0026apos;s responsibility.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-71562)\n\nImproper Handling of Case Sensitivity vulnerability in Erlang/OTP inets httpd allows a remote unauthenticated attacker to read files inside a mod_auth protected directory by requesting them with different casing, on deployments whose filesystem is case-insensitive.\n\nmod_auth:secret_path/3 decides whether a resolved filesystem path lies inside a protected directory block by running the configured directory path through re:run/3 without the caseless option. A request for /secret/file against a directory configured as /Secret therefore does not match, so the request is treated as unprotected and no authentication challenge is issued, while the filesystem resolves the differently cased path to the same file and mod_get serves it. Deployments on case-sensitive filesystems are unaffected, because there the filesystem itself rejects the mismatched casing.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-73270)\n\nGracefulness code ignored cases that should be rejected, resulting in possible HTTP Request Smuggling opportunities.\n\nThis issue affects OTP from OTP 22.2 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 7.1.2 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2.(CVE-2026-73276)\n\nThe inets application HTTP server httpd fails to enforce a configured body-size limit on chunked request.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-74835)\n\nThe mod_auth module in OTP\u0026apos;s inets httpd server, when configured with dets or mnesia authentication backends and multiple directory configuration blocks, collapses all directory blocks into a single shared user/group namespace. A user added to one protected directory is accepted as valid for all other protected directories on the same server instance.\n\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.(CVE-2026-74994)\n\nAn attacker that connects to an open Erlang TCP port that uses the inet driver with {packet,4} mode can use a signed overflow in an incorrect packet length calculation to overflow the receive buffer into the VM allocator area and beyond up to about 2 GB.\\n\\nThis would easily trash the allocated block\u0026apos;s allocator metadata footer, and the next block, if any, and most likely cause the BEAM VM to crash. Utilizing this with precision enough to achieve Remote Code Execution would be extremely unfeasible.\\n\\nThis issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to erts from 6.0 before 15.2.7.13, from 16.0 before 16.4.0.6, and from 17.0 before 17.0.6. Whether OTP before OTP 17.0, corresponding to erts before 6.0, is affected is unknown.(CVE-2026-75538)","status":"published","published":"2026-09-30T13:46:55Z","modified":"2026-10-01T02:00:04.725189823Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"updated_at":"2026-11-02T15:52:47.643553Z"},{"id":"RHSA-2026:62531","title":"Red Hat Security Advisory: Red Hat Hardened Images RPMs bug fix and enhancement update","status":"published","published":"2026-09-03T10:14:26Z","modified":"2026-10-02T10:42:33.771891492Z","cvss":[{"version":"3.1","score":8.2,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N","level":"high"}],"updated_at":"2026-11-02T15:53:21.91255Z"},{"id":"UBUNTU-CVE-2026-69664","description":"Missing Release of Resource after Effective Lifetime vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by sending a request with a chunked body whose chunk-size line is not a hexadecimal number. The worker serving the connection is never released and no timeout reclaims it, so repeating the request across connections occupies every available worker and denies service to legitimate clients. No authentication is required and the default configuration is affected. The chunk-size line must arrive in a write separate from the headers. When the body accompanies the headers, httpd_request_handler:handle_body/3 calls http_chunk:decode/3 inside a try ... catch throw:Error, so the {error, {chunk_size, _}} thrown by http_chunk:decode_size/4 is answered with 400 Bad Request. When the chunk size arrives later, the decoder is resumed through a bare catch in httpd_request_handler:handle_info/2, which converts the throw into a return value rather than raising it; the resulting error tuple is then treated as the next decoder continuation, the socket is re-armed, and the worker waits for data that never comes. The request timeout has already been cancelled at the point the headers were accepted, and the periodic byte-rate check is only armed when minimum_bytes_per_second is configured, which it is not by default. This issue affects OTP from OTP 18.1.4 before OTP 27.3.4.17, OTP 28.5.0.6, and OTP 29.0.6, corresponding to inets from 6.0.3 before 9.3.2.7, 9.6.2.3, and 9.7.2.","status":"published","published":"2026-09-01T15:17:00Z","modified":"2026-09-28T22:45:13.888593924Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"updated_at":"2026-11-02T16:56:57.159276Z"},{"id":"AZL-98466","title":"CVE-2026-69664 affecting package erlang for versions less than 26.2.5.21-6","description":"Missing Release of Resource after Effective Lifetime vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by sending a request with a chunked body whose chunk-size line is not a hexadecimal number. The worker serving the connection is never released and no timeout reclaims it, so repeating the request across connections occupies every available worker and denies service to legitimate clients. No authentication is required and the default configuration is affected.\n\nThe chunk-size line must arrive in a write separate from the headers. When the body accompanies the headers, httpd_request_handler:handle_body/3 calls http_chunk:decode/3 inside a try ... catch throw:Error, so the {error, {chunk_size, _}} thrown by http_chunk:decode_size/4 is answered with 400 Bad Request. When the chunk size arrives later, the decoder is resumed through a bare catch in httpd_request_handler:handle_info/2, which converts the throw into a return value rather than raising it; the resulting error tuple is then treated as the next decoder continuation, the socket is re-armed, and the worker waits for data that never comes. The request timeout has already been cancelled at the point the headers were accepted, and the periodic byte-rate check is only armed when minimum_bytes_per_second is configured, which it is not by default.\n\nThis issue affects OTP from OTP 18.1.4 before OTP 27.3.4.17, OTP 28.5.0.6, and OTP 29.0.6, corresponding to inets from 6.0.3 before 9.3.2.7, 9.6.2.3, and 9.7.2.","status":"published","published":"2026-09-01T15:17:23Z","modified":"2026-11-05T05:40:51Z","updated_at":"2026-11-05T16:41:26.280152Z"},{"id":"USN-8827-1","title":"erlang vulnerabilities","description":"It was discovered that the Erlang Port Mapper Daemon did not properly\nhandle slow connections. A remote attacker could possibly use this issue\nto cause a denial of service. (CVE-2026-42792)\n\nIt was discovered that Erlang incorrectly handled certain external term\nformat data, leading to heap corruption. An attacker could possibly use\nthis issue to cause Erlang to crash, resulting in a denial of service.\nThis issue only affected Ubuntu 24.04 LTS and Ubuntu 26.04 LTS.\n(CVE-2026-55737)\n\nIt was discovered that Erlang incorrectly handled invalid external term\nformat data. An attacker could possibly use this issue to cause Erlang to\ncrash, resulting in a denial of service. This issue only affected Ubuntu\n26.04 LTS. (CVE-2026-54890)\n\nIt was discovered that Erlang incorrectly handled certain packet lengths,\nleading to a buffer overflow. A remote attacker could possibly use this\nissue to cause Erlang to crash or execute arbitrary code. (CVE-2026-75538)\n\nIt was discovered that the Erlang Megaco flex scanner incorrectly handled\ncertain input, leading to a buffer overflow. A remote attacker could\npossibly use this issue to cause Erlang to crash or execute arbitrary code.\n(CVE-2026-59250)\n\nIt was discovered that Erlang TLS clients incorrectly accepted cipher\nsuites that they had not offered. A remote attacker could possibly use\nthis issue to intercept and modify TLS communications. (CVE-2026-55953)\n\nIt was discovered that Erlang incorrectly handled certain certificate\nchains. A remote attacker could possibly use this issue to cause Erlang to\nuse excessive resources, leading to a denial of service. This issue only\naffected Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS.\n(CVE-2026-58227)\n\nIt was discovered that Erlang incorrectly handled certain certificate\npolicies. A remote attacker could possibly use this issue to cause Erlang\nto use excessive resources, leading to a denial of service. This issue only\naffected Ubuntu 26.04 LTS. (CVE-2026-59251)\n\nIt was discovered that the Erlang HTTP server incorrectly handled certain\nconflicting HTTP framing headers. A remote attacker could possibly use this\nissue to smuggle HTTP requests. (CVE-2026-23941, CVE-2026-73812)\n\nIt was discovered that the Erlang HTTP server incorrectly handled certain\nmalformed chunk sizes. A remote attacker could possibly use this issue to\ncause Erlang to crash, resulting in a denial of service. (CVE-2026-69664)\n\nIt was discovered that the Erlang HTTP server did not properly limit the\nsize of chunked request bodies. A remote attacker could possibly use this\nissue to cause Erlang to use excessive resources, leading to a denial of\nservice. (CVE-2026-74835)\n\nIt was discovered that the Erlang HTTP server incorrectly handled certain\nequivalent request paths and differences in character case. A remote\nattacker could possibly use this issue to bypass authentication and gain\nunauthorized access. (CVE-2026-66835, CVE-2026-73270)\n\nIt was discovered that the Erlang HTTP server did not properly limit\nsimultaneous connections. A remote attacker could possibly use this issue\nto cause Erlang to use excessive resources, leading to a denial of service.\nThis issue only affected Ubuntu 16.04 LTS, Ubuntu 18.04 LTS,\nUbuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS.\n(CVE-2026-70399)\n\nIt was discovered that the Erlang HTTP server incorrectly handled header\ncontinuation lines. A remote attacker could possibly use this issue to\nsmuggle HTTP requests. (CVE-2026-66357)\n\nIt was discovered that the Erlang HTTP server incorrectly handled certain\nmalformed header names. A remote attacker could possibly use this issue to\nsmuggle HTTP requests. This issue only affected Ubuntu 20.04 LTS,\nUbuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS.\n(CVE-2026-73276)\n\nIt was discovered that the Erlang HTTP server incorrectly handled\nincomplete request bodies. A remote attacker could possibly use this issue\nto cause Erlang to use excessive resources, leading to a denial of service.\n(CVE-2026-71380)\n\nIt was discovered that the Erlang HTTP client did not properly limit the\nsize of HTTP response headers. A malicious HTTP server could possibly use\nthis issue to cause Erlang to use excessive resources, leading to a denial\nof service. (CVE-2026-55951)\n\nIt was discovered that Erlang did not properly limit the length of port\nnumbers when parsing URIs. A remote attacker could possibly use this issue\nto cause Erlang to use excessive resources, leading to a denial of service.\nThis issue only affected Ubuntu 20.04 LTS, Ubuntu 22.04 LTS,\nUbuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-59696)\n\nIt was discovered that the Erlang SNMP application did not properly limit\nthe size of certain integer values. A remote attacker could possibly use\nthis issue to cause Erlang to use excessive resources, leading to a denial\nof service. (CVE-2026-70405)\n\nIt was discovered that the Erlang LDAP client did not properly limit the\nlength of port numbers in referral URLs. A malicious LDAP server could\npossibly use this issue to cause Erlang to use excessive resources, leading\nto a denial of service. (CVE-2026-70409)","status":"published","published":"2026-09-28T13:21:58Z","modified":"2026-09-28T22:57:44.139860303Z","updated_at":"2026-11-02T16:58:26.907654Z"}]}}