{"id":"CVE-2026-54887","aliases":["AZL-95660","DEBIAN-CVE-2026-54887","EEF-CVE-2026-54887","EUVD-2026-41411","GHSA-p2m2-3c2w-8jp8","OESA-2026-3041","OESA-2026-3042","OESA-2026-3043","OESA-2026-3044","SUSE-SU-2026:3579-1","SUSE-SU-2026:3645-1","UBUNTU-CVE-2026-54887","USN-8901-1","openSUSE-SU-2026:11559-1","openSUSE-SU-2026:11560-1"],"status":"published","title":"DTLS server cookie bypass during startup window due to empty initial cookie secret","description":"Use of Default Cryptographic Key vulnerability in Erlang/OTP ssl (DTLS server) allows predictable DTLS cookie computation during the startup window, enabling source address verification bypass.\n\nOn DTLS server startup, dtls_server_connection:initial_hello/3 initializes previous_cookie_secret to the empty binary (\u003c\u003c\u003e\u003e) instead of a random value. Because HMAC with an empty key is deterministic, anyone who observes the plaintext ClientHello can compute dtls_handshake:cookie(\u003c\u003c\u003e\u003e, IP, Port, Hello) and forge a valid DTLS cookie before the first rotation of the cookie secret. The DTLS cookie (RFC 6347 §4.2.1) is a denial-of-service mitigation that prevents spoofed source IPs from forcing the server to allocate state and perform expensive cryptographic operations; it is not an authentication mechanism. During the window from server startup until the first secret rotation (0 to 15 seconds), an attacker who can observe the plaintext ClientHello can bypass the source address verification, enabling DTLS handshake amplification with spoofed source addresses.\n\nThis vulnerability is associated with program file lib/ssl/src/dtls_server_connection.erl and program routine dtls_server_connection:initial_hello/3.\n\nThis issue affects OTP from OTP 20.0 before OTP 29.0.3, OTP 28.5.0.3 and OTP 27.3.4.14, corresponding to ssl from 8.2 before 11.7.3, 11.6.0.3 and 11.2.12.10.","severity":{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00243,"percentile":0.1559,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-1394"],"published":"2026-07-02T16:06:04Z","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+deb13u3"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"erlang","fixed_in":["1:29.0.3+dfsg-1"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:18.04:LTS","package":"erlang","fixed_in":["1:20.2.2+dfsg-1ubuntu2+esm4"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:20.04:LTS","package":"erlang","fixed_in":["1:22.2.7+dfsg-1ubuntu0.5+esm3"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"erlang","fixed_in":["1:24.2.1+dfsg-1ubuntu0.8"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"erlang","fixed_in":["1:25.3.2.8+dfsg-1ubuntu4.8"],"sources":["osv"]},{"ecosystem":"Ubuntu:26.04:LTS","package":"erlang","fixed_in":["1:27.3.4.6+dfsg-1ubuntu0.2"],"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","1:29.1.2+dfsg-1"]},{"source":"osv","ecosystem":"Debian:13","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:27.3.4.1+dfsg-1+deb13u3"}]}],"versions":["1:27.3.4.1+dfsg-1","1:27.3.4.1+dfsg-1+deb13u1","1:27.3.4.1+dfsg-1+deb13u2"]},{"source":"osv","ecosystem":"Debian:14","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:29.0.3+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~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-SP3","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"25.3.2.6-18.oe2403sp3"}]}],"bundled":11},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP4","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"25.3.2.6-18.oe2403sp4"}]}],"bundled":12},{"source":"osv","ecosystem":"openEuler:22.03-LTS-SP4","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"23.3.4.9-11.oe2203sp4"}]}],"bundled":10},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP1","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"25.3.2.6-18.oe2403sp1"}]}],"bundled":11},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Server Applications 15 SP7","package":"erlang26","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"26.2.1-150300.7.28.1"}]}],"bundled":22},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP6-LTSS","package":"erlang26","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"26.2.1-150300.7.28.1"}]}],"bundled":22},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP6","package":"erlang26","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"26.2.1-150300.7.28.1"}]}],"bundled":22},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Server Applications 15 SP7","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"23.3.4.19-150300.3.39.1"}]}],"bundled":19},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP4-ESPOS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"23.3.4.19-150300.3.39.1"}]}],"bundled":19},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP4-LTSS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"23.3.4.19-150300.3.39.1"}]}],"bundled":19},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP5-ESPOS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"23.3.4.19-150300.3.39.1"}]}],"bundled":19},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP5-LTSS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"23.3.4.19-150300.3.39.1"}]}],"bundled":19},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP4-LTSS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"23.3.4.19-150300.3.39.1"}]}],"bundled":19},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP5-LTSS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"23.3.4.19-150300.3.39.1"}]}],"bundled":19},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP6-LTSS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"23.3.4.19-150300.3.39.1"}]}],"bundled":19},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP4","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"23.3.4.19-150300.3.39.1"}]}],"bundled":19},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP5","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"23.3.4.19-150300.3.39.1"}]}],"bundled":19},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP6","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"23.3.4.19-150300.3.39.1"}]}],"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+esm4"}]}],"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","1:20.2.2+dfsg-1ubuntu2+esm3"]},{"source":"osv","ecosystem":"Ubuntu:Pro:20.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:22.2.7+dfsg-1ubuntu0.5+esm3"}]}],"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","1:22.2.7+dfsg-1ubuntu0.5+esm2"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:24.2.1+dfsg-1ubuntu0.8"}]}],"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","1:24.2.1+dfsg-1ubuntu0.7"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:25.3.2.8+dfsg-1ubuntu4.8"}]}],"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","1:25.3.2.8+dfsg-1ubuntu4.7"]},{"source":"osv","ecosystem":"Ubuntu:25.10","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1:27.3+dfsg-1ubuntu1","1:27.3+dfsg-1ubuntu1.1","1:27.3.4.1+dfsg-1","1:27.3.4.1+dfsg-1build1","1:27.3.4.1+dfsg-1ubuntu0.1"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:27.3.4.6+dfsg-1ubuntu0.2"}]}],"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","1:27.3.4.6+dfsg-1ubuntu0.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+esm3"}]}],"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","1:16.b.3-dfsg-1ubuntu2.2+esm2"],"bundled":30},{"source":"osv","ecosystem":"Ubuntu:Pro:16.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:18.3-dfsg-1ubuntu3.1+esm4"}]}],"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","1:18.3-dfsg-1ubuntu3.1+esm3"],"bundled":30},{"source":"osv","ecosystem":"Ubuntu:Pro:18.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:20.2.2+dfsg-1ubuntu2+esm4"}]}],"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","1:20.2.2+dfsg-1ubuntu2+esm3"],"bundled":30},{"source":"osv","ecosystem":"Ubuntu:Pro:20.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:22.2.7+dfsg-1ubuntu0.5+esm3"}]}],"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","1:22.2.7+dfsg-1ubuntu0.5+esm2"],"bundled":30},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:24.2.1+dfsg-1ubuntu0.8"}]}],"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","1:24.2.1+dfsg-1ubuntu0.7"],"bundled":30},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:25.3.2.8+dfsg-1ubuntu4.8"}]}],"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","1:25.3.2.8+dfsg-1ubuntu4.7"],"bundled":30},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1:27.3.4.6+dfsg-1ubuntu0.2"}]}],"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","1:27.3.4.6+dfsg-1ubuntu0.1"],"bundled":30},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"erlang","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"28.5.0.4-1.1"}]}],"bundled":24},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"erlang27","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"27.1.3-3.1"}]}],"bundled":21}],"products":[{"vendor":"erlang","product":"erlang\\/otp"},{"vendor":"erlang","product":"erlang\\/ssl"},{"vendor":"erlang","product":"otp"}],"references":[{"url":"https://github.com/erlang/otp/security/advisories/GHSA-p2m2-3c2w-8jp8","tags":["vendor-advisory","related","Vendor Advisory","advisory","report"]},{"url":"https://cna.erlef.org/cves/CVE-2026-54887.html","tags":["related","Vendor Advisory","web","report"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-54887","tags":["related","Third Party Advisory","web","report"]},{"url":"https://www.erlang.org/doc/system/versions.html#order-of-versions","tags":["x_version-scheme","Release Notes","web","report"]},{"url":"https://github.com/erlang/otp/commit/888e3bcd72d5406016b9e0de741026bc2a6f114d","tags":["patch","Patch","fix","report"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-54887","tags":["web","advisory"]},{"url":"https://github.com","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/54xxx/CVE-2026-54887.json","tags":["advisory"]},{"url":"https://github.com/erlang/otp","tags":["package"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-54887","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3041","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-48855","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-48856","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-48858","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-49759","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-49760","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53422","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-54886","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-54891","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-55950","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-55952","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3042","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-32147","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3043","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3044","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-20263579-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1261726","tags":["report"]},{"url":"https://bugzilla.suse.com/1266449","tags":["report"]},{"url":"https://bugzilla.suse.com/1266466","tags":["report"]},{"url":"https://bugzilla.suse.com/1268139","tags":["report"]},{"url":"https://bugzilla.suse.com/1268141","tags":["report"]},{"url":"https://bugzilla.suse.com/1268142","tags":["report"]},{"url":"https://bugzilla.suse.com/1268146","tags":["report"]},{"url":"https://bugzilla.suse.com/1268163","tags":["report"]},{"url":"https://bugzilla.suse.com/1268164","tags":["report"]},{"url":"https://bugzilla.suse.com/1270245","tags":["report"]},{"url":"https://bugzilla.suse.com/1270246","tags":["report"]},{"url":"https://bugzilla.suse.com/1270247","tags":["report"]},{"url":"https://bugzilla.suse.com/1270250","tags":["report"]},{"url":"https://bugzilla.suse.com/1270253","tags":["report"]},{"url":"https://bugzilla.suse.com/1270258","tags":["report"]},{"url":"https://bugzilla.suse.com/1272908","tags":["report"]},{"url":"https://bugzilla.suse.com/1272909","tags":["report"]},{"url":"https://bugzilla.suse.com/1272910","tags":["report"]},{"url":"https://bugzilla.suse.com/1272911","tags":["report"]},{"url":"https://bugzilla.suse.com/1272913","tags":["report"]},{"url":"https://bugzilla.suse.com/1272914","tags":["report"]},{"url":"https://bugzilla.suse.com/1272915","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2026-28810","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42789","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42790","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42792","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-47078","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-48855","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-48856","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-48858","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-48860","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-49759","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-49760","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-53422","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54886","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54887","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54891","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55737","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55950","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55952","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55953","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58227","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-59250","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-59251","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-20263645-1/","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2026-54887","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-54887","tags":["report"]},{"url":"https://ubuntu.com/security/notices/USN-8901-1","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2025-4748","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-26618","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-30211","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-21620","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-23942","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-23943","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-28808","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-28810","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-32144","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-32147","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-42789","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-42790","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-42791","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-47078","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-48855","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-48856","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-48858","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-48860","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-49759","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-49760","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-53422","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-54886","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-54891","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-55950","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-55952","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-65634","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-68956","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-74994","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-89422","tags":["report"]},{"url":"","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2026-28808","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42791","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54890","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-26618","tags":["web"]}],"sources":{"cve":[{"id":"CVE-2026-54887","title":"DTLS server cookie bypass during startup window due to empty initial cookie secret","description":"Use of Default Cryptographic Key vulnerability in Erlang/OTP ssl (DTLS server) allows predictable DTLS cookie computation during the startup window, enabling source address verification bypass.\n\nOn DTLS server startup, dtls_server_connection:initial_hello/3 initializes previous_cookie_secret to the empty binary (\u003c\u003c\u003e\u003e) instead of a random value. Because HMAC with an empty key is deterministic, anyone who observes the plaintext ClientHello can compute dtls_handshake:cookie(\u003c\u003c\u003e\u003e, IP, Port, Hello) and forge a valid DTLS cookie before the first rotation of the cookie secret. The DTLS cookie (RFC 6347 §4.2.1) is a denial-of-service mitigation that prevents spoofed source IPs from forcing the server to allocate state and perform expensive cryptographic operations; it is not an authentication mechanism. During the window from server startup until the first secret rotation (0 to 15 seconds), an attacker who can observe the plaintext ClientHello can bypass the source address verification, enabling DTLS handshake amplification with spoofed source addresses.\n\nThis vulnerability is associated with program file lib/ssl/src/dtls_server_connection.erl and program routine dtls_server_connection:initial_hello/3.\n\nThis issue affects OTP from OTP 20.0 before OTP 29.0.3, OTP 28.5.0.3 and OTP 27.3.4.14, corresponding to ssl from 8.2 before 11.7.3, 11.6.0.3 and 11.2.12.10.","status":"published","published":"2026-07-02T16:06:04.156Z","modified":"2026-07-24T14:15:16.337Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","level":"medium","assessor":"cna"}],"cwes":["CWE-1394"],"updated_at":"2026-11-02T13:38:09.774038Z"}],"euvd":[{"id":"EUVD-2026-41411","description":"Use of Default Cryptographic Key vulnerability in Erlang/OTP ssl (DTLS server) allows predictable DTLS cookie computation during the startup window, enabling source address verification bypass.\n\nOn DTLS server startup, dtls_server_connection:initial_hello/3 initializes previous_cookie_secret to the empty binary (\u003c\u003c\u003e\u003e) instead of a random value. Because HMAC with an empty key is deterministic, anyone who observes the plaintext ClientHello can compute dtls_handshake:cookie(\u003c\u003c\u003e\u003e, IP, Port, Hello) and forge a valid DTLS cookie before the first rotation of the cookie secret. The DTLS cookie (RFC 6347 §4.2.1) is a denial-of-service mitigation that prevents spoofed source IPs from forcing the server to allocate state and perform expensive cryptographic operations; it is not an authentication mechanism. During the window from server startup until the first secret rotation (0 to 15 seconds), an attacker who can observe the plaintext ClientHello can bypass the source address verification, enabling DTLS handshake amplification with spoofed source addresses.\n\nThis vulnerability is associated with program file lib/ssl/src/dtls_server_connection.erl and program routine dtls_server_connection:initial_hello/3.\n\nThis issue affects OTP from OTP 20.0 before OTP 29.0.3, OTP 28.5.0.3 and OTP 27.3.4.14, corresponding to ssl from 8.2 before 11.7.3, 11.6.0.3 and 11.2.12.10.","status":"published","published":"2026-07-02T16:06:04Z","modified":"2026-07-24T14:15:16Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","level":"medium"}],"updated_at":"2026-11-02T18:19:40.671085Z"}],"nvd":[{"id":"CVE-2026-54887","description":"Use of Default Cryptographic Key vulnerability in Erlang/OTP ssl (DTLS server) allows predictable DTLS cookie computation during the startup window, enabling source address verification bypass.\n\nOn DTLS server startup, dtls_server_connection:initial_hello/3 initializes previous_cookie_secret to the empty binary (\u003c\u003c\u003e\u003e) instead of a random value. Because HMAC with an empty key is deterministic, anyone who observes the plaintext ClientHello can compute dtls_handshake:cookie(\u003c\u003c\u003e\u003e, IP, Port, Hello) and forge a valid DTLS cookie before the first rotation of the cookie secret. The DTLS cookie (RFC 6347 §4.2.1) is a denial-of-service mitigation that prevents spoofed source IPs from forcing the server to allocate state and perform expensive cryptographic operations; it is not an authentication mechanism. During the window from server startup until the first secret rotation (0 to 15 seconds), an attacker who can observe the plaintext ClientHello can bypass the source address verification, enabling DTLS handshake amplification with spoofed source addresses.\n\nThis vulnerability is associated with program file lib/ssl/src/dtls_server_connection.erl and program routine dtls_server_connection:initial_hello/3.\n\nThis issue affects OTP from OTP 20.0 before OTP 29.0.3, OTP 28.5.0.3 and OTP 27.3.4.14, corresponding to ssl from 8.2 before 11.7.3, 11.6.0.3 and 11.2.12.10.","status":"published","published":"2026-07-02T17:17:02.57Z","modified":"2026-10-25T21:10:00.77Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/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":"medium","assessor":"secondary"},{"version":"3.1","score":4.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N","level":"medium","assessor":"primary"}],"cwes":["CWE-1394"],"updated_at":"2026-11-02T14:12:27.541515Z"}],"osv":[{"id":"CVE-2026-54887","title":"DTLS server cookie bypass during startup window due to empty initial cookie secret","description":"Use of Default Cryptographic Key vulnerability in Erlang/OTP ssl (DTLS server) allows predictable DTLS cookie computation during the startup window, enabling source address verification bypass.\n\nOn DTLS server startup, dtls_server_connection:initial_hello/3 initializes previous_cookie_secret to the empty binary (\u003c\u003c\u003e\u003e) instead of a random value. Because HMAC with an empty key is deterministic, anyone who observes the plaintext ClientHello can compute dtls_handshake:cookie(\u003c\u003c\u003e\u003e, IP, Port, Hello) and forge a valid DTLS cookie before the first rotation of the cookie secret. The DTLS cookie (RFC 6347 §4.2.1) is a denial-of-service mitigation that prevents spoofed source IPs from forcing the server to allocate state and perform expensive cryptographic operations; it is not an authentication mechanism. During the window from server startup until the first secret rotation (0 to 15 seconds), an attacker who can observe the plaintext ClientHello can bypass the source address verification, enabling DTLS handshake amplification with spoofed source addresses.\n\nThis vulnerability is associated with program file lib/ssl/src/dtls_server_connection.erl and program routine dtls_server_connection:initial_hello/3.\n\nThis issue affects OTP from OTP 20.0 before OTP 29.0.3, OTP 28.5.0.3 and OTP 27.3.4.14, corresponding to ssl from 8.2 before 11.7.3, 11.6.0.3 and 11.2.12.10.","status":"published","published":"2026-07-02T16:06:04.156Z","modified":"2026-10-28T03:01:04.253160548Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-1394"],"updated_at":"2026-11-02T15:45:10.818486Z"},{"id":"DEBIAN-CVE-2026-54887","description":"Use of Default Cryptographic Key vulnerability in Erlang/OTP ssl (DTLS server) allows predictable DTLS cookie computation during the startup window, enabling source address verification bypass.  On DTLS server startup, dtls_server_connection:initial_hello/3 initializes previous_cookie_secret to the empty binary (\u003c\u003c\u003e\u003e) instead of a random value. Because HMAC with an empty key is deterministic, anyone who observes the plaintext ClientHello can compute dtls_handshake:cookie(\u003c\u003c\u003e\u003e, IP, Port, Hello) and forge a valid DTLS cookie before the first rotation of the cookie secret. The DTLS cookie (RFC 6347 §4.2.1) is a denial-of-service mitigation that prevents spoofed source IPs from forcing the server to allocate state and perform expensive cryptographic operations; it is not an authentication mechanism. During the window from server startup until the first secret rotation (0 to 15 seconds), an attacker who can observe the plaintext ClientHello can bypass the source address verification, enabling DTLS handshake amplification with spoofed source addresses.  This vulnerability is associated with program file lib/ssl/src/dtls_server_connection.erl and program routine dtls_server_connection:initial_hello/3.  This issue affects OTP from OTP 20.0 before OTP 29.0.3, OTP 28.5.0.3 and OTP 27.3.4.14, corresponding to ssl from 8.2 before 11.7.3, 11.6.0.3 and 11.2.12.10.","status":"published","published":"2026-07-02T17:17:02.57Z","modified":"2026-10-26T12:02:58.271908198Z","cvss":[{"version":"3.1","score":4.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N","level":"medium"}],"updated_at":"2026-11-02T15:45:57.236551Z"},{"id":"EEF-CVE-2026-54887","title":"DTLS server cookie bypass during startup window due to empty initial cookie secret","description":"## Summary\n\nUse of Default Cryptographic Key vulnerability in Erlang/OTP ssl (DTLS server) allows predictable DTLS cookie computation during the startup window, enabling source address verification bypass.\n\nOn DTLS server startup, dtls\\_server\\_connection:initial\\_hello/3 initializes previous\\_cookie\\_secret to the empty binary (\u003c\u003c\u003e\u003e) instead of a random value. Because HMAC with an empty key is deterministic, anyone who observes the plaintext ClientHello can compute dtls\\_handshake:cookie(\u003c\u003c\u003e\u003e, IP, Port, Hello) and forge a valid DTLS cookie before the first rotation of the cookie secret. The DTLS cookie (RFC 6347 §4.2.1) is a denial-of-service mitigation that prevents spoofed source IPs from forcing the server to allocate state and perform expensive cryptographic operations; it is not an authentication mechanism. During the window from server startup until the first secret rotation (0 to 15 seconds), an attacker who can observe the plaintext ClientHello can bypass the source address verification, enabling DTLS handshake amplification with spoofed source addresses.\n\nThis vulnerability is associated with program file lib/ssl/src/dtls\\_server\\_connection.erl and program routine dtls\\_server\\_connection:initial\\_hello/3.\n\nThis issue affects OTP from OTP 20.0 before OTP 29.0.3, OTP 28.5.0.3 and OTP 27.3.4.14, corresponding to ssl from 8.2 before 11.7.3, 11.6.0.3 and 11.2.12.10.","status":"published","published":"2026-07-02T16:06:04.156Z","modified":"2026-07-30T18:22:08.644575Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-1394"],"updated_at":"2026-11-02T15:46:33.520522Z"},{"id":"OESA-2026-3041","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\nExposure of Sensitive Information to an Unauthorized Actor vulnerability in Erlang OTP ssh (ssh_sftpd module) allows File Discovery.\n\nThe SSH_FXP_READLINK handler in ssh_sftpd sends the raw result of file:read_link/2 to the client without calling chroot_filename/2 to strip the backend root prefix. An authenticated SFTP client can create a symlink inside the chroot pointing to /; ssh_sftpd resolves the target to the absolute backend root and stores it on disk. Reading the symlink back via SSH_FXP_READLINK returns that absolute path, for example /data/sftp, instead of the chrooted value /.\n\nThe information disclosed is the absolute filesystem path of the SFTP root directory and of any symlink targets within it. No file contents, credentials, or access to paths outside the root directory are obtainable through this issue alone.\n\nThis vulnerability is associated with program files lib/ssh/src/ssh_sftpd.erl.\n\nThis issue affects OTP from OTP 17.0 before 29.0.2, 28.5.0.2 and 27.3.4.13 corresponding to ssh from 3.0.1 before 6.0.1, 5.5.2.1 and 5.2.11.8.(CVE-2026-48855)\n\nSensitive Data Exposure vulnerability in Erlang OTP inets (httpc_response module) allows Retrieve Embedded Sensitive Data.\n\nThe httpc client forwards the Authorization and Proxy-Authorization request headers to redirect targets without checking whether the redirect crosses an origin boundary. httpc_response:redirect/2 constructs the redirected request by updating only the host field of the header record; all other fields (including authorization and proxy_authorization) are copied verbatim. The redirect target host is never compared against the original host.\n\nautoredirect defaults to true, so this affects all httpc callers that do not explicitly disable automatic redirects.\n\nAn attacker who controls a server that the victim contacts via httpc can issue a cross-origin 3xx redirect to a server they also control. The Authorization header (including Basic credentials derived from URL userinfo via httpc_request:handle_user_info/2) is forwarded to the redirect target, allowing credential theft. The same applies to the Proxy-Authorization header.\n\nThis vulnerability is associated with program files lib/inets/src/http_client/httpc_response.erl.\n\nThis issue affects OTP from 17.0 before 29.0.2, 28.5.0.2 and 27.3.4.13 corresponding to inets from 5.10 before 9.7.1, 9.6.2.2 and 9.3.2.6.(CVE-2026-48856)\n\nServer-Side Request Forgery (SSRF) vulnerability in Erlang/OTP ftp (ftp_internal module) allows FTP bounce attacks and SSRF via an unvalidated PASV response IP address.\n\nThe ftp_internal:handle_ctrl_result/2 PASV handler (mode=passive, ipfamily=inet, ftp_extension=false) extracts the IP address from the server\u0026apos;s 227 response and passes it directly to gen_tcp:connect/4 without validating it against the control connection peer address. The adjacent EPSV handlers correctly call peername(CSock) to derive the IP from the control connection, but the PASV handler does not. A malicious or compromised FTP server can redirect the client\u0026apos;s data connection to an arbitrary internal host and port. On read operations (ftp:ls/1,2, ftp:nlist/1,2, ftp:recv/2,3), data from the redirected target is returned to the caller. On write operations (ftp:send/2,3, ftp:append/2,3), file content is sent to the redirected target. This enables SSRF against internal hosts, cloud metadata endpoints, and FTP bounce attacks against third-party hosts.\n\nThe vulnerable path is the default configuration (mode=passive, ipfamily=inet, ftp_extension=false). RFC 2577 section 3 explicitly recommends validating the PASV response IP against the control connection peer.\n\nThe ftp application is deprecated and scheduled for removal in OTP-30.\n\nThis vulnerability is associated with program files lib/inets/src/ftp/ftp_internal.erl (inets 5.10.4 through 6.5, OTP 17.4 through 20.3) and lib/ftp/src/ftp_internal.erl (ftp 1.0 and later, OTP 21.0 and later).\n\nThis issue affects OTP from OTP 17.4 before 29.0.2, 28.5.0.2 and 27.3.4.13 corresponding to inets from 5.10.4 before 7.0 and ftp from 1.0 before 1.2.6, 1.2.4.1 and 1.2.3.1.(CVE-2026-48858)\n\nStack-based Buffer Overflow vulnerability in Erlang OTP erts (inet_drv) allows an unauthenticated remote attacker to crash the BEAM VM by sending a crafted SCTP ERROR chunk.\n\nThe sctp_parse_error_chunk function in erts/emulator/drivers/common/inet_drv.c parses SCTP ERROR chunks and writes cause codes into a fixed-size stack-allocated ErlDrvTermData spec[] array without checking bounds. A remote attacker who has established an SCTP association to a listening port can send a single crafted SCTP ERROR chunk containing enough cause codes to overflow the stack buffer, crashing the VM. The attacker can only write 16-bit values interleaved with a fixed tag, so the overflow does not provide a controlled return address, limiting exploitation to Denial of Service.\n\nA crafted SCTP ERROR chunk may also leak bits and pieces of Erlang VM memory into the received error packet observed by the Erlang process. Such data is already readable by the user running the Erlang VM, so the disclosure scope is limited.\n\nThis issue affects OTP from OTP 17.0 before 27.3.4.13, 28.5.0.2 and 29.0.2, corresponding to erts from 6.0 before 15.2.7.9, 16.4.0.2 and 17.0.2.(CVE-2026-49759)\n\nStack-based Buffer Overflow vulnerability in Erlang OTP (erl_interface) allows Stack-based Buffer Overflow.\n\nThis vulnerability is associated with program file lib/erl_interface/src/misc/ei_printterm.c and program routine ei_s_print_term.\n\nThe C function ei_s_print_term uses an internal 2000-character stack buffer to format terms. When called with an encoded Erlang term containing a very large integer (encoded representation exceeding 2000 characters), the buffer overflows. The overflow bytes are restricted to the ASCII values of 0-9 and A-F, which limits exploitation to Denial of Service.\n\nThe companion function ei_print_term, which prints directly to a FILE instead of a memory buffer, does not contain this bug.\n\nThis issue affects OTP from OTP 17.0 before 27.3.4.13, 28.5.0.2 and 29.0.2, corresponding to erl_interface from 3.7.16 before 5.5.2.1, 5.7.0.1 and 5.8.1.(CVE-2026-49760)\n\nObservable Response Discrepancy vulnerability in Erlang OTP ssh (ssh_sftpd module) allows an authenticated SFTP user to enumerate the existence of files and directories outside the configured root directory.\n\nThe SSH_FXP_REALPATH handler in ssh_sftpd calls relate_file_name/3 with Canonicalize=false, unlike every other SFTP operation handler. This allows .. components in the requested path to bypass the is_within_root/2 check without being resolved. The un-canonicalized path then enters resolve_symlinks/2, which walks up the directory tree above the configured root and issues read_link() syscalls on arbitrary filesystem paths.\n\nAn authenticated SFTP client can exploit this by sending a REALPATH request with a crafted traversal path. The server response differs depending on whether the target path exists on the host filesystem (SSH_FXP_NAME when the path resolves successfully, SSH_FX_NO_SUCH_FILE when it does not). This creates a path-existence oracle that an attacker can use to enumerate the filesystem structure outside the configured root, including the existence of sensitive files, directories, and mount points.\n\nThe vulnerability leaks only the existence of paths. No file contents, credentials, or write access are obtainable through this issue alone. The information gained may assist further attacks when combined with other vulnerabilities.\n\nThis vulnerability is associated with program files lib/ssh/src/ssh_sftpd.erl and program routine ssh_sftpd:handle_op/4.\n\nThis issue affects OTP from OTP 17.0 until OTP 29.0.3, 28.5.0.3, and 27.3.4.14 corresponding to ssh from 3.0.1 until 6.0.2, 5.5.2.2, and 5.2.11.9.(CVE-2026-53422)\n\nLoop with Unreachable Exit Condition (\u0026apos;Infinite Loop\u0026apos;) vulnerability in Erlang OTP ssh (ssh_sftpd module) allows an authenticated SFTP user to render an SFTP channel permanently unresponsive.\n\nThe handle_data/4 function in ssh_sftpd contains a catch-all clause that accepts channel data of any type. When channel data with a non-zero type code (SSH_MSG_CHANNEL_EXTENDED_DATA) arrives with an empty pending buffer and a payload at or below the SFTP packet size limit, the clause tail-calls itself with identical arguments, creating an infinite loop.\n\nThe SFTP protocol operates exclusively on normal channel data (type 0). Extended data (non-zero type) is meaningless for SFTP and is never sent by conforming clients. However, the SSH protocol permits any channel participant to send extended data on an open channel, so an authenticated SFTP client can trigger the loop by sending SSH_MSG_CHANNEL_EXTENDED_DATA with any data_type_code and any non-empty payload at or below the size limit.\n\nThe targeted ssh_sftpd process enters an infinite tail-recursive loop. It never processes another message, its message queue grows without bound, and it can only be stopped by killing the process. BEAM\u0026apos;s reduction-based scheduler preemption continues to function, so other processes on the node are not starved, but each stuck channel process consumes its full CPU time share continuously and accumulates unbounded message queue memory. Opening many channels amplifies the CPU and memory impact.\n\nErlang/OTP SSH configurations using the default max_channels setting (infinity) allow an authenticated user to open unlimited channels per connection, amplifying the attack without requiring multiple TCP connections or authentications.\n\nNo file contents, credentials, or write access are obtainable through this issue. The impact is limited to denial of service on targeted SFTP channels, with secondary CPU degradation and memory growth.\n\nThis vulnerability is associated with program file lib/ssh/src/ssh_sftpd.erl and program routine ssh_sftpd:handle_data/4.\n\nThis issue affects OTP from OTP 17.0 until OTP 29.0.3, 28.5.0.3, and 27.3.4.14 corresponding to ssh from 3.0.1 until 6.0.2, 5.5.2.2, and 5.2.11.9.(CVE-2026-54886)\n\nUse of Default Cryptographic Key vulnerability in Erlang/OTP ssl (DTLS server) allows predictable DTLS cookie computation during the startup window, enabling source address verification bypass.\n\nOn DTLS server startup, dtls_server_connection:initial_hello/3 initializes previous_cookie_secret to the empty binary (\u0026lt;\u0026lt;\u0026gt;\u0026gt;) instead of a random value. Because HMAC with an empty key is deterministic, anyone who observes the plaintext ClientHello can compute dtls_handshake:cookie(\u0026lt;\u0026lt;\u0026gt;\u0026gt;, IP, Port, Hello) and forge a valid DTLS cookie before the first rotation of the cookie secret. The DTLS cookie (RFC 6347 §4.2.1) is a denial-of-service mitigation that prevents spoofed source IPs from forcing the server to allocate state and perform expensive cryptographic operations; it is not an authentication mechanism. During the window from server startup until the first secret rotation (0 to 15 seconds), an attacker who can observe the plaintext ClientHello can bypass the source address verification, enabling DTLS handshake amplification with spoofed source addresses.\n\nThis vulnerability is associated with program file lib/ssl/src/dtls_server_connection.erl and program routine dtls_server_connection:initial_hello/3.\n\nThis issue affects OTP from OTP 20.0 before 29.0.3, 28.5.0.3 and 27.3.4.14 corresponding to ssl from 8.2 before 11.7.3, 11.6.0.3 and 11.2.12.10.(CVE-2026-54887)\n\nImproper Enforcement of Message Integrity During Transmission in a Communication Channel vulnerability in Erlang/OTP ssl (tls_gen_connection module) allows a network-positioned attacker to inject unauthenticated plaintext that the TLS client application later treats as authenticated server data.\n\nThe function tls_gen_connection:handle_protocol_record/3 rejects APPLICATION_DATA records that arrive in pre-handshake states when the TLS endpoint acts as a server, but does not apply the same check when the endpoint acts as a client. A network-positioned attacker can send plaintext APPLICATION_DATA records to the client during the handshake. The records are buffered and, once the handshake completes successfully, delivered to the application as if they were authenticated post-handshake data. The attacker cannot observe the client\u0026apos;s response or steer the connection, so the impact is limited to blind injection of unauthenticated bytes. The injection window is wider for TLS versions prior to TLS 1.3 than for TLS 1.3.\n\nThis vulnerability is associated with program file lib/ssl/src/tls_gen_connection.erl.\n\nThis issue affects OTP from OTP 17.0 before 29.0.3, 28.5.0.3 and 27.3.4.14 corresponding to ssl from 5.3.4 before 11.7.3, 11.6.0.3 and 11.2.12.10. TLS 1.3 is affected starting with OTP 22.0, when TLS 1.3 support was added.(CVE-2026-54891)\n\nTime-of-check Time-of-use (TOCTOU) race condition vulnerability in Erlang/OTP ssl (dtls_packet_demux module) allows an unauthenticated remote attacker to crash all active DTLS sessions on a listener.\n\nA DTLS server listener uses a single shared dtls_packet_demux gen_server process to route incoming UDP datagrams to the correct connection handler. When a DTLS client reconnects rapidly from the same source address and port (sending multiple ClientHello messages in quick succession), a race condition in the demux\u0026apos;s internal gb_trees key-value store causes a {key_exists, {old, Client}} crash, terminating the demux process. Because the demux is shared across all DTLS associations on that listener, its crash immediately kills every active DTLS session, not just the attacker\u0026apos;s.\n\nThe attack is pre-authentication: the attacker only needs to send UDP datagrams containing valid ClientHello messages from the same source IP and port before the intermediate DOWN monitor message is processed by the gen_server. No credentials, no completed handshake, and no special configuration are required, and the crash can be repeated indefinitely to create a persistent denial of service for all clients of that listener.\n\nThis vulnerability is associated with program file lib/ssl/src/dtls_packet_demux.erl.\n\nThis issue affects OTP from OTP 25.3 before 29.0.3, 28.5.0.3, and 27.3.4.14 corresponding to ssl from 10.9 before 11.7.3, 11.6.0.3, and 11.2.12.10.(CVE-2026-55950)\n\nThe Erlang/OTP ssl application does not validate that the PSK identity list and binder list carried in a TLS 1.3 ClientHello pre-shared key extension have equal length before passing them to the session ticket handler. In tls_handshake_1_3:handle_pre_shared_key/3, an OfferedPreSharedKeys record with a mismatched number of identities and binders is forwarded directly to tls_server_session_ticket:use/4, which crashes the session ticket handler process.\n\nAn unauthenticated remote attacker can send a single crafted ClientHello to a TLS 1.3 server with session tickets enabled (stateful or stateless mode) and permanently disrupt session ticket handling on that listener. New TLS 1.3 handshakes complete but subsequently crash when the server attempts to issue a session ticket, effectively making TLS 1.3 unusable on the affected listener until the ssl application is restarted. TLS 1.2 connections are not affected.\n\nThis issue affects OTP from 22.2 before 29.0.3, 28.5.0.3 and 27.3.4.14 corresponding to ssl from 9.5 before 11.7.3, 11.6.0.3 and 11.2.12.10.(CVE-2026-55952)","status":"published","published":"2026-07-19T11:11:56Z","modified":"2026-08-18T01:21:18.687381728Z","cvss":[{"version":"3.1","score":8.2,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:46.823443Z"},{"id":"OESA-2026-3042","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\nImproper Limitation of a Pathname to a Restricted Directory (\u0026apos;Path Traversal\u0026apos;) vulnerability in Erlang OTP ssh (ssh_sftpd module) allows an authenticated SFTP user to modify file attributes outside the configured chroot directory.\n\nThe SFTP daemon (ssh_sftpd) stores the raw, user-supplied path in file handles instead of the chroot-resolved path. When SSH_FXP_FSETSTAT is issued on such a handle, file attributes (permissions, ownership, timestamps) are modified on the real filesystem path, bypassing the root directory boundary entirely.\n\nAny authenticated SFTP user on a server configured with the root option can modify file attributes of files outside the intended chroot boundary. The prerequisite is that a target file must exist on the real filesystem at the same relative path. Note that this vulnerability only allows modification of file attributes; file contents cannot be read or altered through this attack vector.\n\nIf the SSH daemon runs as root, this enables direct privilege escalation: an attacker can set the setuid bit on any binary, change ownership of sensitive files, or make system configuration world-writable.\n\nThis vulnerability is associated with program files lib/ssh/src/ssh_sftpd.erl and program routines ssh_sftpd:do_open/4 and ssh_sftpd:handle_op/4.\n\nThis issue affects OTP from OTP 17.0 until OTP 28.4.3, 27.3.4.11, and 26.2.5.20 corresponding to ssh from 3.01 until 5.5.3, 5.2.11.7, and 5.1.4.15.(CVE-2026-32147)\n\nExposure of Sensitive Information to an Unauthorized Actor vulnerability in Erlang OTP ssh (ssh_sftpd module) allows File Discovery.\n\nThe SSH_FXP_READLINK handler in ssh_sftpd sends the raw result of file:read_link/2 to the client without calling chroot_filename/2 to strip the backend root prefix. An authenticated SFTP client can create a symlink inside the chroot pointing to /; ssh_sftpd resolves the target to the absolute backend root and stores it on disk. Reading the symlink back via SSH_FXP_READLINK returns that absolute path, for example /data/sftp, instead of the chrooted value /.\n\nThe information disclosed is the absolute filesystem path of the SFTP root directory and of any symlink targets within it. No file contents, credentials, or access to paths outside the root directory are obtainable through this issue alone.\n\nThis vulnerability is associated with program files lib/ssh/src/ssh_sftpd.erl.\n\nThis issue affects OTP from OTP 17.0 before 29.0.2, 28.5.0.2 and 27.3.4.13 corresponding to ssh from 3.0.1 before 6.0.1, 5.5.2.1 and 5.2.11.8.(CVE-2026-48855)\n\nSensitive Data Exposure vulnerability in Erlang OTP inets (httpc_response module) allows Retrieve Embedded Sensitive Data.\n\nThe httpc client forwards the Authorization and Proxy-Authorization request headers to redirect targets without checking whether the redirect crosses an origin boundary. httpc_response:redirect/2 constructs the redirected request by updating only the host field of the header record; all other fields (including authorization and proxy_authorization) are copied verbatim. The redirect target host is never compared against the original host.\n\nautoredirect defaults to true, so this affects all httpc callers that do not explicitly disable automatic redirects.\n\nAn attacker who controls a server that the victim contacts via httpc can issue a cross-origin 3xx redirect to a server they also control. The Authorization header (including Basic credentials derived from URL userinfo via httpc_request:handle_user_info/2) is forwarded to the redirect target, allowing credential theft. The same applies to the Proxy-Authorization header.\n\nThis vulnerability is associated with program files lib/inets/src/http_client/httpc_response.erl.\n\nThis issue affects OTP from 17.0 before 29.0.2, 28.5.0.2 and 27.3.4.13 corresponding to inets from 5.10 before 9.7.1, 9.6.2.2 and 9.3.2.6.(CVE-2026-48856)\n\nServer-Side Request Forgery (SSRF) vulnerability in Erlang/OTP ftp (ftp_internal module) allows FTP bounce attacks and SSRF via an unvalidated PASV response IP address.\n\nThe ftp_internal:handle_ctrl_result/2 PASV handler (mode=passive, ipfamily=inet, ftp_extension=false) extracts the IP address from the server\u0026apos;s 227 response and passes it directly to gen_tcp:connect/4 without validating it against the control connection peer address. The adjacent EPSV handlers correctly call peername(CSock) to derive the IP from the control connection, but the PASV handler does not. A malicious or compromised FTP server can redirect the client\u0026apos;s data connection to an arbitrary internal host and port. On read operations (ftp:ls/1,2, ftp:nlist/1,2, ftp:recv/2,3), data from the redirected target is returned to the caller. On write operations (ftp:send/2,3, ftp:append/2,3), file content is sent to the redirected target. This enables SSRF against internal hosts, cloud metadata endpoints, and FTP bounce attacks against third-party hosts.\n\nThe vulnerable path is the default configuration (mode=passive, ipfamily=inet, ftp_extension=false). RFC 2577 section 3 explicitly recommends validating the PASV response IP against the control connection peer.\n\nThe ftp application is deprecated and scheduled for removal in OTP-30.\n\nThis vulnerability is associated with program files lib/inets/src/ftp/ftp_internal.erl (inets 5.10.4 through 6.5, OTP 17.4 through 20.3) and lib/ftp/src/ftp_internal.erl (ftp 1.0 and later, OTP 21.0 and later).\n\nThis issue affects OTP from OTP 17.4 before 29.0.2, 28.5.0.2 and 27.3.4.13 corresponding to inets from 5.10.4 before 7.0 and ftp from 1.0 before 1.2.6, 1.2.4.1 and 1.2.3.1.(CVE-2026-48858)\n\nStack-based Buffer Overflow vulnerability in Erlang OTP erts (inet_drv) allows an unauthenticated remote attacker to crash the BEAM VM by sending a crafted SCTP ERROR chunk.\n\nThe sctp_parse_error_chunk function in erts/emulator/drivers/common/inet_drv.c parses SCTP ERROR chunks and writes cause codes into a fixed-size stack-allocated ErlDrvTermData spec[] array without checking bounds. A remote attacker who has established an SCTP association to a listening port can send a single crafted SCTP ERROR chunk containing enough cause codes to overflow the stack buffer, crashing the VM. The attacker can only write 16-bit values interleaved with a fixed tag, so the overflow does not provide a controlled return address, limiting exploitation to Denial of Service.\n\nA crafted SCTP ERROR chunk may also leak bits and pieces of Erlang VM memory into the received error packet observed by the Erlang process. Such data is already readable by the user running the Erlang VM, so the disclosure scope is limited.\n\nThis issue affects OTP from OTP 17.0 before 27.3.4.13, 28.5.0.2 and 29.0.2, corresponding to erts from 6.0 before 15.2.7.9, 16.4.0.2 and 17.0.2.(CVE-2026-49759)\n\nStack-based Buffer Overflow vulnerability in Erlang OTP (erl_interface) allows Stack-based Buffer Overflow.\n\nThis vulnerability is associated with program file lib/erl_interface/src/misc/ei_printterm.c and program routine ei_s_print_term.\n\nThe C function ei_s_print_term uses an internal 2000-character stack buffer to format terms. When called with an encoded Erlang term containing a very large integer (encoded representation exceeding 2000 characters), the buffer overflows. The overflow bytes are restricted to the ASCII values of 0-9 and A-F, which limits exploitation to Denial of Service.\n\nThe companion function ei_print_term, which prints directly to a FILE instead of a memory buffer, does not contain this bug.\n\nThis issue affects OTP from OTP 17.0 before 27.3.4.13, 28.5.0.2 and 29.0.2, corresponding to erl_interface from 3.7.16 before 5.5.2.1, 5.7.0.1 and 5.8.1.(CVE-2026-49760)\n\nObservable Response Discrepancy vulnerability in Erlang OTP ssh (ssh_sftpd module) allows an authenticated SFTP user to enumerate the existence of files and directories outside the configured root directory.\n\nThe SSH_FXP_REALPATH handler in ssh_sftpd calls relate_file_name/3 with Canonicalize=false, unlike every other SFTP operation handler. This allows .. components in the requested path to bypass the is_within_root/2 check without being resolved. The un-canonicalized path then enters resolve_symlinks/2, which walks up the directory tree above the configured root and issues read_link() syscalls on arbitrary filesystem paths.\n\nAn authenticated SFTP client can exploit this by sending a REALPATH request with a crafted traversal path. The server response differs depending on whether the target path exists on the host filesystem (SSH_FXP_NAME when the path resolves successfully, SSH_FX_NO_SUCH_FILE when it does not). This creates a path-existence oracle that an attacker can use to enumerate the filesystem structure outside the configured root, including the existence of sensitive files, directories, and mount points.\n\nThe vulnerability leaks only the existence of paths. No file contents, credentials, or write access are obtainable through this issue alone. The information gained may assist further attacks when combined with other vulnerabilities.\n\nThis vulnerability is associated with program files lib/ssh/src/ssh_sftpd.erl and program routine ssh_sftpd:handle_op/4.\n\nThis issue affects OTP from OTP 17.0 until OTP 29.0.3, 28.5.0.3, and 27.3.4.14 corresponding to ssh from 3.0.1 until 6.0.2, 5.5.2.2, and 5.2.11.9.(CVE-2026-53422)\n\nLoop with Unreachable Exit Condition (\u0026apos;Infinite Loop\u0026apos;) vulnerability in Erlang OTP ssh (ssh_sftpd module) allows an authenticated SFTP user to render an SFTP channel permanently unresponsive.\n\nThe handle_data/4 function in ssh_sftpd contains a catch-all clause that accepts channel data of any type. When channel data with a non-zero type code (SSH_MSG_CHANNEL_EXTENDED_DATA) arrives with an empty pending buffer and a payload at or below the SFTP packet size limit, the clause tail-calls itself with identical arguments, creating an infinite loop.\n\nThe SFTP protocol operates exclusively on normal channel data (type 0). Extended data (non-zero type) is meaningless for SFTP and is never sent by conforming clients. However, the SSH protocol permits any channel participant to send extended data on an open channel, so an authenticated SFTP client can trigger the loop by sending SSH_MSG_CHANNEL_EXTENDED_DATA with any data_type_code and any non-empty payload at or below the size limit.\n\nThe targeted ssh_sftpd process enters an infinite tail-recursive loop. It never processes another message, its message queue grows without bound, and it can only be stopped by killing the process. BEAM\u0026apos;s reduction-based scheduler preemption continues to function, so other processes on the node are not starved, but each stuck channel process consumes its full CPU time share continuously and accumulates unbounded message queue memory. Opening many channels amplifies the CPU and memory impact.\n\nErlang/OTP SSH configurations using the default max_channels setting (infinity) allow an authenticated user to open unlimited channels per connection, amplifying the attack without requiring multiple TCP connections or authentications.\n\nNo file contents, credentials, or write access are obtainable through this issue. The impact is limited to denial of service on targeted SFTP channels, with secondary CPU degradation and memory growth.\n\nThis vulnerability is associated with program file lib/ssh/src/ssh_sftpd.erl and program routine ssh_sftpd:handle_data/4.\n\nThis issue affects OTP from OTP 17.0 until OTP 29.0.3, 28.5.0.3, and 27.3.4.14 corresponding to ssh from 3.0.1 until 6.0.2, 5.5.2.2, and 5.2.11.9.(CVE-2026-54886)\n\nUse of Default Cryptographic Key vulnerability in Erlang/OTP ssl (DTLS server) allows predictable DTLS cookie computation during the startup window, enabling source address verification bypass.\n\nOn DTLS server startup, dtls_server_connection:initial_hello/3 initializes previous_cookie_secret to the empty binary (\u0026lt;\u0026lt;\u0026gt;\u0026gt;) instead of a random value. Because HMAC with an empty key is deterministic, anyone who observes the plaintext ClientHello can compute dtls_handshake:cookie(\u0026lt;\u0026lt;\u0026gt;\u0026gt;, IP, Port, Hello) and forge a valid DTLS cookie before the first rotation of the cookie secret. The DTLS cookie (RFC 6347 §4.2.1) is a denial-of-service mitigation that prevents spoofed source IPs from forcing the server to allocate state and perform expensive cryptographic operations; it is not an authentication mechanism. During the window from server startup until the first secret rotation (0 to 15 seconds), an attacker who can observe the plaintext ClientHello can bypass the source address verification, enabling DTLS handshake amplification with spoofed source addresses.\n\nThis vulnerability is associated with program file lib/ssl/src/dtls_server_connection.erl and program routine dtls_server_connection:initial_hello/3.\n\nThis issue affects OTP from OTP 20.0 before 29.0.3, 28.5.0.3 and 27.3.4.14 corresponding to ssl from 8.2 before 11.7.3, 11.6.0.3 and 11.2.12.10.(CVE-2026-54887)\n\nImproper Enforcement of Message Integrity During Transmission in a Communication Channel vulnerability in Erlang/OTP ssl (tls_gen_connection module) allows a network-positioned attacker to inject unauthenticated plaintext that the TLS client application later treats as authenticated server data.\n\nThe function tls_gen_connection:handle_protocol_record/3 rejects APPLICATION_DATA records that arrive in pre-handshake states when the TLS endpoint acts as a server, but does not apply the same check when the endpoint acts as a client. A network-positioned attacker can send plaintext APPLICATION_DATA records to the client during the handshake. The records are buffered and, once the handshake completes successfully, delivered to the application as if they were authenticated post-handshake data. The attacker cannot observe the client\u0026apos;s response or steer the connection, so the impact is limited to blind injection of unauthenticated bytes. The injection window is wider for TLS versions prior to TLS 1.3 than for TLS 1.3.\n\nThis vulnerability is associated with program file lib/ssl/src/tls_gen_connection.erl.\n\nThis issue affects OTP from OTP 17.0 before 29.0.3, 28.5.0.3 and 27.3.4.14 corresponding to ssl from 5.3.4 before 11.7.3, 11.6.0.3 and 11.2.12.10. TLS 1.3 is affected starting with OTP 22.0, when TLS 1.3 support was added.(CVE-2026-54891)\n\nTime-of-check Time-of-use (TOCTOU) race condition vulnerability in Erlang/OTP ssl (dtls_packet_demux module) allows an unauthenticated remote attacker to crash all active DTLS sessions on a listener.\n\nA DTLS server listener uses a single shared dtls_packet_demux gen_server process to route incoming UDP datagrams to the correct connection handler. When a DTLS client reconnects rapidly from the same source address and port (sending multiple ClientHello messages in quick succession), a race condition in the demux\u0026apos;s internal gb_trees key-value store causes a {key_exists, {old, Client}} crash, terminating the demux process. Because the demux is shared across all DTLS associations on that listener, its crash immediately kills every active DTLS session, not just the attacker\u0026apos;s.\n\nThe attack is pre-authentication: the attacker only needs to send UDP datagrams containing valid ClientHello messages from the same source IP and port before the intermediate DOWN monitor message is processed by the gen_server. No credentials, no completed handshake, and no special configuration are required, and the crash can be repeated indefinitely to create a persistent denial of service for all clients of that listener.\n\nThis vulnerability is associated with program file lib/ssl/src/dtls_packet_demux.erl.\n\nThis issue affects OTP from OTP 25.3 before 29.0.3, 28.5.0.3, and 27.3.4.14 corresponding to ssl from 10.9 before 11.7.3, 11.6.0.3, and 11.2.12.10.(CVE-2026-55950)\n\nThe Erlang/OTP ssl application does not validate that the PSK identity list and binder list carried in a TLS 1.3 ClientHello pre-shared key extension have equal length before passing them to the session ticket handler. In tls_handshake_1_3:handle_pre_shared_key/3, an OfferedPreSharedKeys record with a mismatched number of identities and binders is forwarded directly to tls_server_session_ticket:use/4, which crashes the session ticket handler process.\n\nAn unauthenticated remote attacker can send a single crafted ClientHello to a TLS 1.3 server with session tickets enabled (stateful or stateless mode) and permanently disrupt session ticket handling on that listener. New TLS 1.3 handshakes complete but subsequently crash when the server attempts to issue a session ticket, effectively making TLS 1.3 unusable on the affected listener until the ssl application is restarted. TLS 1.2 connections are not affected.\n\nThis issue affects OTP from 22.2 before 29.0.3, 28.5.0.3 and 27.3.4.14 corresponding to ssl from 9.5 before 11.7.3, 11.6.0.3 and 11.2.12.10.(CVE-2026-55952)","status":"published","published":"2026-07-19T11:11:56Z","modified":"2026-08-18T01:21:20.922949129Z","cvss":[{"version":"3.1","score":8.2,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:46.823443Z"},{"id":"OESA-2026-3043","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\nExposure of Sensitive Information to an Unauthorized Actor vulnerability in Erlang OTP ssh (ssh_sftpd module) allows File Discovery.\n\nThe SSH_FXP_READLINK handler in ssh_sftpd sends the raw result of file:read_link/2 to the client without calling chroot_filename/2 to strip the backend root prefix. An authenticated SFTP client can create a symlink inside the chroot pointing to /; ssh_sftpd resolves the target to the absolute backend root and stores it on disk. Reading the symlink back via SSH_FXP_READLINK returns that absolute path, for example /data/sftp, instead of the chrooted value /.\n\nThe information disclosed is the absolute filesystem path of the SFTP root directory and of any symlink targets within it. No file contents, credentials, or access to paths outside the root directory are obtainable through this issue alone.\n\nThis vulnerability is associated with program files lib/ssh/src/ssh_sftpd.erl.\n\nThis issue affects OTP from OTP 17.0 before 29.0.2, 28.5.0.2 and 27.3.4.13 corresponding to ssh from 3.0.1 before 6.0.1, 5.5.2.1 and 5.2.11.8.(CVE-2026-48855)\n\nSensitive Data Exposure vulnerability in Erlang OTP inets (httpc_response module) allows Retrieve Embedded Sensitive Data.\n\nThe httpc client forwards the Authorization and Proxy-Authorization request headers to redirect targets without checking whether the redirect crosses an origin boundary. httpc_response:redirect/2 constructs the redirected request by updating only the host field of the header record; all other fields (including authorization and proxy_authorization) are copied verbatim. The redirect target host is never compared against the original host.\n\nautoredirect defaults to true, so this affects all httpc callers that do not explicitly disable automatic redirects.\n\nAn attacker who controls a server that the victim contacts via httpc can issue a cross-origin 3xx redirect to a server they also control. The Authorization header (including Basic credentials derived from URL userinfo via httpc_request:handle_user_info/2) is forwarded to the redirect target, allowing credential theft. The same applies to the Proxy-Authorization header.\n\nThis vulnerability is associated with program files lib/inets/src/http_client/httpc_response.erl.\n\nThis issue affects OTP from 17.0 before 29.0.2, 28.5.0.2 and 27.3.4.13 corresponding to inets from 5.10 before 9.7.1, 9.6.2.2 and 9.3.2.6.(CVE-2026-48856)\n\nServer-Side Request Forgery (SSRF) vulnerability in Erlang/OTP ftp (ftp_internal module) allows FTP bounce attacks and SSRF via an unvalidated PASV response IP address.\n\nThe ftp_internal:handle_ctrl_result/2 PASV handler (mode=passive, ipfamily=inet, ftp_extension=false) extracts the IP address from the server\u0026apos;s 227 response and passes it directly to gen_tcp:connect/4 without validating it against the control connection peer address. The adjacent EPSV handlers correctly call peername(CSock) to derive the IP from the control connection, but the PASV handler does not. A malicious or compromised FTP server can redirect the client\u0026apos;s data connection to an arbitrary internal host and port. On read operations (ftp:ls/1,2, ftp:nlist/1,2, ftp:recv/2,3), data from the redirected target is returned to the caller. On write operations (ftp:send/2,3, ftp:append/2,3), file content is sent to the redirected target. This enables SSRF against internal hosts, cloud metadata endpoints, and FTP bounce attacks against third-party hosts.\n\nThe vulnerable path is the default configuration (mode=passive, ipfamily=inet, ftp_extension=false). RFC 2577 section 3 explicitly recommends validating the PASV response IP against the control connection peer.\n\nThe ftp application is deprecated and scheduled for removal in OTP-30.\n\nThis vulnerability is associated with program files lib/inets/src/ftp/ftp_internal.erl (inets 5.10.4 through 6.5, OTP 17.4 through 20.3) and lib/ftp/src/ftp_internal.erl (ftp 1.0 and later, OTP 21.0 and later).\n\nThis issue affects OTP from OTP 17.4 before 29.0.2, 28.5.0.2 and 27.3.4.13 corresponding to inets from 5.10.4 before 7.0 and ftp from 1.0 before 1.2.6, 1.2.4.1 and 1.2.3.1.(CVE-2026-48858)\n\nStack-based Buffer Overflow vulnerability in Erlang OTP erts (inet_drv) allows an unauthenticated remote attacker to crash the BEAM VM by sending a crafted SCTP ERROR chunk.\n\nThe sctp_parse_error_chunk function in erts/emulator/drivers/common/inet_drv.c parses SCTP ERROR chunks and writes cause codes into a fixed-size stack-allocated ErlDrvTermData spec[] array without checking bounds. A remote attacker who has established an SCTP association to a listening port can send a single crafted SCTP ERROR chunk containing enough cause codes to overflow the stack buffer, crashing the VM. The attacker can only write 16-bit values interleaved with a fixed tag, so the overflow does not provide a controlled return address, limiting exploitation to Denial of Service.\n\nA crafted SCTP ERROR chunk may also leak bits and pieces of Erlang VM memory into the received error packet observed by the Erlang process. Such data is already readable by the user running the Erlang VM, so the disclosure scope is limited.\n\nThis issue affects OTP from OTP 17.0 before 27.3.4.13, 28.5.0.2 and 29.0.2, corresponding to erts from 6.0 before 15.2.7.9, 16.4.0.2 and 17.0.2.(CVE-2026-49759)\n\nStack-based Buffer Overflow vulnerability in Erlang OTP (erl_interface) allows Stack-based Buffer Overflow.\n\nThis vulnerability is associated with program file lib/erl_interface/src/misc/ei_printterm.c and program routine ei_s_print_term.\n\nThe C function ei_s_print_term uses an internal 2000-character stack buffer to format terms. When called with an encoded Erlang term containing a very large integer (encoded representation exceeding 2000 characters), the buffer overflows. The overflow bytes are restricted to the ASCII values of 0-9 and A-F, which limits exploitation to Denial of Service.\n\nThe companion function ei_print_term, which prints directly to a FILE instead of a memory buffer, does not contain this bug.\n\nThis issue affects OTP from OTP 17.0 before 27.3.4.13, 28.5.0.2 and 29.0.2, corresponding to erl_interface from 3.7.16 before 5.5.2.1, 5.7.0.1 and 5.8.1.(CVE-2026-49760)\n\nObservable Response Discrepancy vulnerability in Erlang OTP ssh (ssh_sftpd module) allows an authenticated SFTP user to enumerate the existence of files and directories outside the configured root directory.\n\nThe SSH_FXP_REALPATH handler in ssh_sftpd calls relate_file_name/3 with Canonicalize=false, unlike every other SFTP operation handler. This allows .. components in the requested path to bypass the is_within_root/2 check without being resolved. The un-canonicalized path then enters resolve_symlinks/2, which walks up the directory tree above the configured root and issues read_link() syscalls on arbitrary filesystem paths.\n\nAn authenticated SFTP client can exploit this by sending a REALPATH request with a crafted traversal path. The server response differs depending on whether the target path exists on the host filesystem (SSH_FXP_NAME when the path resolves successfully, SSH_FX_NO_SUCH_FILE when it does not). This creates a path-existence oracle that an attacker can use to enumerate the filesystem structure outside the configured root, including the existence of sensitive files, directories, and mount points.\n\nThe vulnerability leaks only the existence of paths. No file contents, credentials, or write access are obtainable through this issue alone. The information gained may assist further attacks when combined with other vulnerabilities.\n\nThis vulnerability is associated with program files lib/ssh/src/ssh_sftpd.erl and program routine ssh_sftpd:handle_op/4.\n\nThis issue affects OTP from OTP 17.0 until OTP 29.0.3, 28.5.0.3, and 27.3.4.14 corresponding to ssh from 3.0.1 until 6.0.2, 5.5.2.2, and 5.2.11.9.(CVE-2026-53422)\n\nLoop with Unreachable Exit Condition (\u0026apos;Infinite Loop\u0026apos;) vulnerability in Erlang OTP ssh (ssh_sftpd module) allows an authenticated SFTP user to render an SFTP channel permanently unresponsive.\n\nThe handle_data/4 function in ssh_sftpd contains a catch-all clause that accepts channel data of any type. When channel data with a non-zero type code (SSH_MSG_CHANNEL_EXTENDED_DATA) arrives with an empty pending buffer and a payload at or below the SFTP packet size limit, the clause tail-calls itself with identical arguments, creating an infinite loop.\n\nThe SFTP protocol operates exclusively on normal channel data (type 0). Extended data (non-zero type) is meaningless for SFTP and is never sent by conforming clients. However, the SSH protocol permits any channel participant to send extended data on an open channel, so an authenticated SFTP client can trigger the loop by sending SSH_MSG_CHANNEL_EXTENDED_DATA with any data_type_code and any non-empty payload at or below the size limit.\n\nThe targeted ssh_sftpd process enters an infinite tail-recursive loop. It never processes another message, its message queue grows without bound, and it can only be stopped by killing the process. BEAM\u0026apos;s reduction-based scheduler preemption continues to function, so other processes on the node are not starved, but each stuck channel process consumes its full CPU time share continuously and accumulates unbounded message queue memory. Opening many channels amplifies the CPU and memory impact.\n\nErlang/OTP SSH configurations using the default max_channels setting (infinity) allow an authenticated user to open unlimited channels per connection, amplifying the attack without requiring multiple TCP connections or authentications.\n\nNo file contents, credentials, or write access are obtainable through this issue. The impact is limited to denial of service on targeted SFTP channels, with secondary CPU degradation and memory growth.\n\nThis vulnerability is associated with program file lib/ssh/src/ssh_sftpd.erl and program routine ssh_sftpd:handle_data/4.\n\nThis issue affects OTP from OTP 17.0 until OTP 29.0.3, 28.5.0.3, and 27.3.4.14 corresponding to ssh from 3.0.1 until 6.0.2, 5.5.2.2, and 5.2.11.9.(CVE-2026-54886)\n\nUse of Default Cryptographic Key vulnerability in Erlang/OTP ssl (DTLS server) allows predictable DTLS cookie computation during the startup window, enabling source address verification bypass.\n\nOn DTLS server startup, dtls_server_connection:initial_hello/3 initializes previous_cookie_secret to the empty binary (\u0026lt;\u0026lt;\u0026gt;\u0026gt;) instead of a random value. Because HMAC with an empty key is deterministic, anyone who observes the plaintext ClientHello can compute dtls_handshake:cookie(\u0026lt;\u0026lt;\u0026gt;\u0026gt;, IP, Port, Hello) and forge a valid DTLS cookie before the first rotation of the cookie secret. The DTLS cookie (RFC 6347 §4.2.1) is a denial-of-service mitigation that prevents spoofed source IPs from forcing the server to allocate state and perform expensive cryptographic operations; it is not an authentication mechanism. During the window from server startup until the first secret rotation (0 to 15 seconds), an attacker who can observe the plaintext ClientHello can bypass the source address verification, enabling DTLS handshake amplification with spoofed source addresses.\n\nThis vulnerability is associated with program file lib/ssl/src/dtls_server_connection.erl and program routine dtls_server_connection:initial_hello/3.\n\nThis issue affects OTP from OTP 20.0 before 29.0.3, 28.5.0.3 and 27.3.4.14 corresponding to ssl from 8.2 before 11.7.3, 11.6.0.3 and 11.2.12.10.(CVE-2026-54887)\n\nImproper Enforcement of Message Integrity During Transmission in a Communication Channel vulnerability in Erlang/OTP ssl (tls_gen_connection module) allows a network-positioned attacker to inject unauthenticated plaintext that the TLS client application later treats as authenticated server data.\n\nThe function tls_gen_connection:handle_protocol_record/3 rejects APPLICATION_DATA records that arrive in pre-handshake states when the TLS endpoint acts as a server, but does not apply the same check when the endpoint acts as a client. A network-positioned attacker can send plaintext APPLICATION_DATA records to the client during the handshake. The records are buffered and, once the handshake completes successfully, delivered to the application as if they were authenticated post-handshake data. The attacker cannot observe the client\u0026apos;s response or steer the connection, so the impact is limited to blind injection of unauthenticated bytes. The injection window is wider for TLS versions prior to TLS 1.3 than for TLS 1.3.\n\nThis vulnerability is associated with program file lib/ssl/src/tls_gen_connection.erl.\n\nThis issue affects OTP from OTP 17.0 before 29.0.3, 28.5.0.3 and 27.3.4.14 corresponding to ssl from 5.3.4 before 11.7.3, 11.6.0.3 and 11.2.12.10. TLS 1.3 is affected starting with OTP 22.0, when TLS 1.3 support was added.(CVE-2026-54891)\n\nThe Erlang/OTP ssl application does not validate that the PSK identity list and binder list carried in a TLS 1.3 ClientHello pre-shared key extension have equal length before passing them to the session ticket handler. In tls_handshake_1_3:handle_pre_shared_key/3, an OfferedPreSharedKeys record with a mismatched number of identities and binders is forwarded directly to tls_server_session_ticket:use/4, which crashes the session ticket handler process.\n\nAn unauthenticated remote attacker can send a single crafted ClientHello to a TLS 1.3 server with session tickets enabled (stateful or stateless mode) and permanently disrupt session ticket handling on that listener. New TLS 1.3 handshakes complete but subsequently crash when the server attempts to issue a session ticket, effectively making TLS 1.3 unusable on the affected listener until the ssl application is restarted. TLS 1.2 connections are not affected.\n\nThis issue affects OTP from 22.2 before 29.0.3, 28.5.0.3 and 27.3.4.14 corresponding to ssl from 9.5 before 11.7.3, 11.6.0.3 and 11.2.12.10.(CVE-2026-55952)","status":"published","published":"2026-07-19T11:11:56Z","modified":"2026-08-18T01:21:20.452100758Z","cvss":[{"version":"3.1","score":8.2,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:46.823443Z"},{"id":"OESA-2026-3044","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\nExposure of Sensitive Information to an Unauthorized Actor vulnerability in Erlang OTP ssh (ssh_sftpd module) allows File Discovery.\n\nThe SSH_FXP_READLINK handler in ssh_sftpd sends the raw result of file:read_link/2 to the client without calling chroot_filename/2 to strip the backend root prefix. An authenticated SFTP client can create a symlink inside the chroot pointing to /; ssh_sftpd resolves the target to the absolute backend root and stores it on disk. Reading the symlink back via SSH_FXP_READLINK returns that absolute path, for example /data/sftp, instead of the chrooted value /.\n\nThe information disclosed is the absolute filesystem path of the SFTP root directory and of any symlink targets within it. No file contents, credentials, or access to paths outside the root directory are obtainable through this issue alone.\n\nThis vulnerability is associated with program files lib/ssh/src/ssh_sftpd.erl.\n\nThis issue affects OTP from OTP 17.0 before 29.0.2, 28.5.0.2 and 27.3.4.13 corresponding to ssh from 3.0.1 before 6.0.1, 5.5.2.1 and 5.2.11.8.(CVE-2026-48855)\n\nSensitive Data Exposure vulnerability in Erlang OTP inets (httpc_response module) allows Retrieve Embedded Sensitive Data.\n\nThe httpc client forwards the Authorization and Proxy-Authorization request headers to redirect targets without checking whether the redirect crosses an origin boundary. httpc_response:redirect/2 constructs the redirected request by updating only the host field of the header record; all other fields (including authorization and proxy_authorization) are copied verbatim. The redirect target host is never compared against the original host.\n\nautoredirect defaults to true, so this affects all httpc callers that do not explicitly disable automatic redirects.\n\nAn attacker who controls a server that the victim contacts via httpc can issue a cross-origin 3xx redirect to a server they also control. The Authorization header (including Basic credentials derived from URL userinfo via httpc_request:handle_user_info/2) is forwarded to the redirect target, allowing credential theft. The same applies to the Proxy-Authorization header.\n\nThis vulnerability is associated with program files lib/inets/src/http_client/httpc_response.erl.\n\nThis issue affects OTP from 17.0 before 29.0.2, 28.5.0.2 and 27.3.4.13 corresponding to inets from 5.10 before 9.7.1, 9.6.2.2 and 9.3.2.6.(CVE-2026-48856)\n\nServer-Side Request Forgery (SSRF) vulnerability in Erlang/OTP ftp (ftp_internal module) allows FTP bounce attacks and SSRF via an unvalidated PASV response IP address.\n\nThe ftp_internal:handle_ctrl_result/2 PASV handler (mode=passive, ipfamily=inet, ftp_extension=false) extracts the IP address from the server\u0026apos;s 227 response and passes it directly to gen_tcp:connect/4 without validating it against the control connection peer address. The adjacent EPSV handlers correctly call peername(CSock) to derive the IP from the control connection, but the PASV handler does not. A malicious or compromised FTP server can redirect the client\u0026apos;s data connection to an arbitrary internal host and port. On read operations (ftp:ls/1,2, ftp:nlist/1,2, ftp:recv/2,3), data from the redirected target is returned to the caller. On write operations (ftp:send/2,3, ftp:append/2,3), file content is sent to the redirected target. This enables SSRF against internal hosts, cloud metadata endpoints, and FTP bounce attacks against third-party hosts.\n\nThe vulnerable path is the default configuration (mode=passive, ipfamily=inet, ftp_extension=false). RFC 2577 section 3 explicitly recommends validating the PASV response IP against the control connection peer.\n\nThe ftp application is deprecated and scheduled for removal in OTP-30.\n\nThis vulnerability is associated with program files lib/inets/src/ftp/ftp_internal.erl (inets 5.10.4 through 6.5, OTP 17.4 through 20.3) and lib/ftp/src/ftp_internal.erl (ftp 1.0 and later, OTP 21.0 and later).\n\nThis issue affects OTP from OTP 17.4 before 29.0.2, 28.5.0.2 and 27.3.4.13 corresponding to inets from 5.10.4 before 7.0 and ftp from 1.0 before 1.2.6, 1.2.4.1 and 1.2.3.1.(CVE-2026-48858)\n\nStack-based Buffer Overflow vulnerability in Erlang OTP erts (inet_drv) allows an unauthenticated remote attacker to crash the BEAM VM by sending a crafted SCTP ERROR chunk.\n\nThe sctp_parse_error_chunk function in erts/emulator/drivers/common/inet_drv.c parses SCTP ERROR chunks and writes cause codes into a fixed-size stack-allocated ErlDrvTermData spec[] array without checking bounds. A remote attacker who has established an SCTP association to a listening port can send a single crafted SCTP ERROR chunk containing enough cause codes to overflow the stack buffer, crashing the VM. The attacker can only write 16-bit values interleaved with a fixed tag, so the overflow does not provide a controlled return address, limiting exploitation to Denial of Service.\n\nA crafted SCTP ERROR chunk may also leak bits and pieces of Erlang VM memory into the received error packet observed by the Erlang process. Such data is already readable by the user running the Erlang VM, so the disclosure scope is limited.\n\nThis issue affects OTP from OTP 17.0 before 27.3.4.13, 28.5.0.2 and 29.0.2, corresponding to erts from 6.0 before 15.2.7.9, 16.4.0.2 and 17.0.2.(CVE-2026-49759)\n\nStack-based Buffer Overflow vulnerability in Erlang OTP (erl_interface) allows Stack-based Buffer Overflow.\n\nThis vulnerability is associated with program file lib/erl_interface/src/misc/ei_printterm.c and program routine ei_s_print_term.\n\nThe C function ei_s_print_term uses an internal 2000-character stack buffer to format terms. When called with an encoded Erlang term containing a very large integer (encoded representation exceeding 2000 characters), the buffer overflows. The overflow bytes are restricted to the ASCII values of 0-9 and A-F, which limits exploitation to Denial of Service.\n\nThe companion function ei_print_term, which prints directly to a FILE instead of a memory buffer, does not contain this bug.\n\nThis issue affects OTP from OTP 17.0 before 27.3.4.13, 28.5.0.2 and 29.0.2, corresponding to erl_interface from 3.7.16 before 5.5.2.1, 5.7.0.1 and 5.8.1.(CVE-2026-49760)\n\nObservable Response Discrepancy vulnerability in Erlang OTP ssh (ssh_sftpd module) allows an authenticated SFTP user to enumerate the existence of files and directories outside the configured root directory.\n\nThe SSH_FXP_REALPATH handler in ssh_sftpd calls relate_file_name/3 with Canonicalize=false, unlike every other SFTP operation handler. This allows .. components in the requested path to bypass the is_within_root/2 check without being resolved. The un-canonicalized path then enters resolve_symlinks/2, which walks up the directory tree above the configured root and issues read_link() syscalls on arbitrary filesystem paths.\n\nAn authenticated SFTP client can exploit this by sending a REALPATH request with a crafted traversal path. The server response differs depending on whether the target path exists on the host filesystem (SSH_FXP_NAME when the path resolves successfully, SSH_FX_NO_SUCH_FILE when it does not). This creates a path-existence oracle that an attacker can use to enumerate the filesystem structure outside the configured root, including the existence of sensitive files, directories, and mount points.\n\nThe vulnerability leaks only the existence of paths. No file contents, credentials, or write access are obtainable through this issue alone. The information gained may assist further attacks when combined with other vulnerabilities.\n\nThis vulnerability is associated with program files lib/ssh/src/ssh_sftpd.erl and program routine ssh_sftpd:handle_op/4.\n\nThis issue affects OTP from OTP 17.0 until OTP 29.0.3, 28.5.0.3, and 27.3.4.14 corresponding to ssh from 3.0.1 until 6.0.2, 5.5.2.2, and 5.2.11.9.(CVE-2026-53422)\n\nLoop with Unreachable Exit Condition (\u0026apos;Infinite Loop\u0026apos;) vulnerability in Erlang OTP ssh (ssh_sftpd module) allows an authenticated SFTP user to render an SFTP channel permanently unresponsive.\n\nThe handle_data/4 function in ssh_sftpd contains a catch-all clause that accepts channel data of any type. When channel data with a non-zero type code (SSH_MSG_CHANNEL_EXTENDED_DATA) arrives with an empty pending buffer and a payload at or below the SFTP packet size limit, the clause tail-calls itself with identical arguments, creating an infinite loop.\n\nThe SFTP protocol operates exclusively on normal channel data (type 0). Extended data (non-zero type) is meaningless for SFTP and is never sent by conforming clients. However, the SSH protocol permits any channel participant to send extended data on an open channel, so an authenticated SFTP client can trigger the loop by sending SSH_MSG_CHANNEL_EXTENDED_DATA with any data_type_code and any non-empty payload at or below the size limit.\n\nThe targeted ssh_sftpd process enters an infinite tail-recursive loop. It never processes another message, its message queue grows without bound, and it can only be stopped by killing the process. BEAM\u0026apos;s reduction-based scheduler preemption continues to function, so other processes on the node are not starved, but each stuck channel process consumes its full CPU time share continuously and accumulates unbounded message queue memory. Opening many channels amplifies the CPU and memory impact.\n\nErlang/OTP SSH configurations using the default max_channels setting (infinity) allow an authenticated user to open unlimited channels per connection, amplifying the attack without requiring multiple TCP connections or authentications.\n\nNo file contents, credentials, or write access are obtainable through this issue. The impact is limited to denial of service on targeted SFTP channels, with secondary CPU degradation and memory growth.\n\nThis vulnerability is associated with program file lib/ssh/src/ssh_sftpd.erl and program routine ssh_sftpd:handle_data/4.\n\nThis issue affects OTP from OTP 17.0 until OTP 29.0.3, 28.5.0.3, and 27.3.4.14 corresponding to ssh from 3.0.1 until 6.0.2, 5.5.2.2, and 5.2.11.9.(CVE-2026-54886)\n\nUse of Default Cryptographic Key vulnerability in Erlang/OTP ssl (DTLS server) allows predictable DTLS cookie computation during the startup window, enabling source address verification bypass.\n\nOn DTLS server startup, dtls_server_connection:initial_hello/3 initializes previous_cookie_secret to the empty binary (\u0026lt;\u0026lt;\u0026gt;\u0026gt;) instead of a random value. Because HMAC with an empty key is deterministic, anyone who observes the plaintext ClientHello can compute dtls_handshake:cookie(\u0026lt;\u0026lt;\u0026gt;\u0026gt;, IP, Port, Hello) and forge a valid DTLS cookie before the first rotation of the cookie secret. The DTLS cookie (RFC 6347 §4.2.1) is a denial-of-service mitigation that prevents spoofed source IPs from forcing the server to allocate state and perform expensive cryptographic operations; it is not an authentication mechanism. During the window from server startup until the first secret rotation (0 to 15 seconds), an attacker who can observe the plaintext ClientHello can bypass the source address verification, enabling DTLS handshake amplification with spoofed source addresses.\n\nThis vulnerability is associated with program file lib/ssl/src/dtls_server_connection.erl and program routine dtls_server_connection:initial_hello/3.\n\nThis issue affects OTP from OTP 20.0 before 29.0.3, 28.5.0.3 and 27.3.4.14 corresponding to ssl from 8.2 before 11.7.3, 11.6.0.3 and 11.2.12.10.(CVE-2026-54887)\n\nImproper Enforcement of Message Integrity During Transmission in a Communication Channel vulnerability in Erlang/OTP ssl (tls_gen_connection module) allows a network-positioned attacker to inject unauthenticated plaintext that the TLS client application later treats as authenticated server data.\n\nThe function tls_gen_connection:handle_protocol_record/3 rejects APPLICATION_DATA records that arrive in pre-handshake states when the TLS endpoint acts as a server, but does not apply the same check when the endpoint acts as a client. A network-positioned attacker can send plaintext APPLICATION_DATA records to the client during the handshake. The records are buffered and, once the handshake completes successfully, delivered to the application as if they were authenticated post-handshake data. The attacker cannot observe the client\u0026apos;s response or steer the connection, so the impact is limited to blind injection of unauthenticated bytes. The injection window is wider for TLS versions prior to TLS 1.3 than for TLS 1.3.\n\nThis vulnerability is associated with program file lib/ssl/src/tls_gen_connection.erl.\n\nThis issue affects OTP from OTP 17.0 before 29.0.3, 28.5.0.3 and 27.3.4.14 corresponding to ssl from 5.3.4 before 11.7.3, 11.6.0.3 and 11.2.12.10. TLS 1.3 is affected starting with OTP 22.0, when TLS 1.3 support was added.(CVE-2026-54891)\n\nTime-of-check Time-of-use (TOCTOU) race condition vulnerability in Erlang/OTP ssl (dtls_packet_demux module) allows an unauthenticated remote attacker to crash all active DTLS sessions on a listener.\n\nA DTLS server listener uses a single shared dtls_packet_demux gen_server process to route incoming UDP datagrams to the correct connection handler. When a DTLS client reconnects rapidly from the same source address and port (sending multiple ClientHello messages in quick succession), a race condition in the demux\u0026apos;s internal gb_trees key-value store causes a {key_exists, {old, Client}} crash, terminating the demux process. Because the demux is shared across all DTLS associations on that listener, its crash immediately kills every active DTLS session, not just the attacker\u0026apos;s.\n\nThe attack is pre-authentication: the attacker only needs to send UDP datagrams containing valid ClientHello messages from the same source IP and port before the intermediate DOWN monitor message is processed by the gen_server. No credentials, no completed handshake, and no special configuration are required, and the crash can be repeated indefinitely to create a persistent denial of service for all clients of that listener.\n\nThis vulnerability is associated with program file lib/ssl/src/dtls_packet_demux.erl.\n\nThis issue affects OTP from OTP 25.3 before 29.0.3, 28.5.0.3, and 27.3.4.14 corresponding to ssl from 10.9 before 11.7.3, 11.6.0.3, and 11.2.12.10.(CVE-2026-55950)\n\nThe Erlang/OTP ssl application does not validate that the PSK identity list and binder list carried in a TLS 1.3 ClientHello pre-shared key extension have equal length before passing them to the session ticket handler. In tls_handshake_1_3:handle_pre_shared_key/3, an OfferedPreSharedKeys record with a mismatched number of identities and binders is forwarded directly to tls_server_session_ticket:use/4, which crashes the session ticket handler process.\n\nAn unauthenticated remote attacker can send a single crafted ClientHello to a TLS 1.3 server with session tickets enabled (stateful or stateless mode) and permanently disrupt session ticket handling on that listener. New TLS 1.3 handshakes complete but subsequently crash when the server attempts to issue a session ticket, effectively making TLS 1.3 unusable on the affected listener until the ssl application is restarted. TLS 1.2 connections are not affected.\n\nThis issue affects OTP from 22.2 before 29.0.3, 28.5.0.3 and 27.3.4.14 corresponding to ssl from 9.5 before 11.7.3, 11.6.0.3 and 11.2.12.10.(CVE-2026-55952)","status":"published","published":"2026-07-19T11:11:56Z","modified":"2026-08-18T01:21:19.028436385Z","cvss":[{"version":"3.1","score":8.2,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:46.823443Z"},{"id":"UBUNTU-CVE-2026-54887","description":"Use of Default Cryptographic Key vulnerability in Erlang/OTP ssl (DTLS server) allows predictable DTLS cookie computation during the startup window, enabling source address verification bypass. On DTLS server startup, dtls_server_connection:initial_hello/3 initializes previous_cookie_secret to the empty binary (\u003c\u003c\u003e\u003e) instead of a random value. Because HMAC with an empty key is deterministic, anyone who observes the plaintext ClientHello can compute dtls_handshake:cookie(\u003c\u003c\u003e\u003e, IP, Port, Hello) and forge a valid DTLS cookie before the first rotation of the cookie secret. The DTLS cookie (RFC 6347 §4.2.1) is a denial-of-service mitigation that prevents spoofed source IPs from forcing the server to allocate state and perform expensive cryptographic operations; it is not an authentication mechanism. During the window from server startup until the first secret rotation (0 to 15 seconds), an attacker who can observe the plaintext ClientHello can bypass the source address verification, enabling DTLS handshake amplification with spoofed source addresses. This vulnerability is associated with program file lib/ssl/src/dtls_server_connection.erl and program routine dtls_server_connection:initial_hello/3. This issue affects OTP from OTP 20.0 before OTP 29.0.3, OTP 28.5.0.3 and OTP 27.3.4.14, corresponding to ssl from 8.2 before 11.7.3, 11.6.0.3 and 11.2.12.10.","status":"published","published":"2026-07-02T17:17:00Z","modified":"2026-10-08T19:48:35.251330624Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","level":"medium"},{"version":"3.1","score":4.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N","level":"medium"}],"updated_at":"2026-11-02T16:56:41.382716Z"},{"id":"AZL-95660","title":"CVE-2026-54887 affecting package erlang for versions less than 26.2.5.21-6","description":"Use of Default Cryptographic Key vulnerability in Erlang/OTP ssl (DTLS server) allows predictable DTLS cookie computation during the startup window, enabling source address verification bypass.\n\nOn DTLS server startup, dtls_server_connection:initial_hello/3 initializes previous_cookie_secret to the empty binary (\u003c\u003c\u003e\u003e) instead of a random value. Because HMAC with an empty key is deterministic, anyone who observes the plaintext ClientHello can compute dtls_handshake:cookie(\u003c\u003c\u003e\u003e, IP, Port, Hello) and forge a valid DTLS cookie before the first rotation of the cookie secret. The DTLS cookie (RFC 6347 §4.2.1) is a denial-of-service mitigation that prevents spoofed source IPs from forcing the server to allocate state and perform expensive cryptographic operations; it is not an authentication mechanism. During the window from server startup until the first secret rotation (0 to 15 seconds), an attacker who can observe the plaintext ClientHello can bypass the source address verification, enabling DTLS handshake amplification with spoofed source addresses.\n\nThis vulnerability is associated with program file lib/ssl/src/dtls_server_connection.erl and program routine dtls_server_connection:initial_hello/3.\n\nThis issue affects OTP from OTP 20.0 before OTP 29.0.3, OTP 28.5.0.3 and OTP 27.3.4.14, corresponding to ssl from 8.2 before 11.7.3, 11.6.0.3 and 11.2.12.10.","status":"published","published":"2026-07-02T17:17:02Z","modified":"2026-11-05T05:40:51Z","updated_at":"2026-11-05T16:41:26.077208Z"},{"id":"openSUSE-SU-2026:11559-1","title":"erlang-28.5.0.4-1.1 on GA media","description":"These are all security issues fixed in the erlang-28.5.0.4-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2026-08-20T00:00:00Z","modified":"2026-08-21T09:15:09.246696292Z","updated_at":"2026-11-02T16:58:39.516824Z"},{"id":"openSUSE-SU-2026:11560-1","title":"erlang27-27.1.3-3.1 on GA media","description":"These are all security issues fixed in the erlang27-27.1.3-3.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2026-08-20T00:00:00Z","modified":"2026-08-21T09:15:09.294918569Z","updated_at":"2026-11-02T16:58:39.516824Z"},{"id":"SUSE-SU-2026:3579-1","title":"Security update for erlang26","description":"This update for erlang26 fixes the following issues:\n\n- CVE-2026-28810: predictable DNS transaction IDs can cause DNS cache poisoning (bsc#1261726).\n- CVE-2026-42789: `public_key` application accepts non-CA certificates as intermediate issuers and this enables chain\n  forgery (bsc#1266449).\n- CVE-2026-42790: Name constraints and `Subject CommonName` fallback in TLS hostname verification allows for certificate\n  forgery by MITM attacker (bsc#1266466).\n- CVE-2026-42792: permanent `epmd` DoS via connection slot exhaustion due to improper handling of exceptional\n  conditions (bsc#1272908).\n- CVE-2026-47078: relative path traversal in `zip:unzip/zip:extract` via `check_dir_level` depth-counter bypass\n  (bsc#1272909).\n- CVE-2026-48855: SFTP `READLINK` response leaks absolute backend filesystem path when root is configured (bsc#1268139).\n- CVE-2026-48856: `httpc` leaks `Authorization` headers to cross-origin redirect targets (bsc#1268141).\n- CVE-2026-48858: server-side request forgery allows FTP bounce attacks and SSRF via an unvalidated `PASV` response IP\n  address (bsc#1268142).\n- CVE-2026-48860: `ssl` (`inet_tls_dist` module) allows unauthenticated bypass of the distribution-over-TLS LAN\n  allowlist (bsc#1268146).\n- CVE-2026-49759: unbounded stack buffer overflow in SCTP error cause parsing in `inet_drv` (bsc#1268163).\n- CVE-2026-49760: stack buffer overflow in `ei_s_print_term` at very large integer (bsc#1268164).\n- CVE-2026-53422: SFTP `REALPATH` path-existence oracle allows filesystem enumeration outside configured root\n  (bsc#1270245).\n- CVE-2026-54886: SSH SFTP server denial of service via extended channel data infinite loop (bsc#1270246).\n- CVE-2026-54887: use of default cryptographic key allows predictable DTLS cookie computation during the startup window\n  (bsc#1270247).\n- CVE-2026-54891: plaintext injection towards (D)TLS client during handshake (bsc#1270250).\n- CVE-2026-55737: heap pointer corruption via signed/unsigned mismatch in `LARGE_TUPLE_EXTP` decoding in `erts`\n  external term format decoder (bsc#1272910).\n- CVE-2026-55950: time-of-check time-of-use race condition allows an unauthenticated remote attacker to crash all active\n  DTLS sessions on a listener (bsc#1270253).\n- CVE-2026-55952: missing validation allows for DoS of the TLS-1.3 server when clients send a malformed `ClientHello`\n  with mismatched PSK identity and binder list lengths (bsc#1270258).\n- CVE-2026-55953: TLS 1.2 and DTLS clients accept unoffered anonymous cipher suites and allow for server authentication\n  bypass (bsc#1272911).\n- CVE-2026-58227: TLS/DTLS denial of service via unbounded recursion on cross-signed peer certificate chain\n  (bsc#1272913).\n- CVE-2026-59250: `megaco` flex scanner buffer overflow via oversized property parm name (bsc#1272914).\n- CVE-2026-59251: denial of service via exponential certificate policy tree growth in path validation (bsc#1272915).\n","status":"published","published":"2026-08-11T14:05:54Z","modified":"2026-08-12T10:45:06.178233719Z","updated_at":"2026-11-02T15:54:05.392906Z"},{"id":"SUSE-SU-2026:3645-1","title":"Security update for erlang","description":"This update for erlang fixes the following issues:\n\n- CVE-2026-28810: predictable DNS transaction IDs can cause DNS cache poisoning (bsc#1261726).\n- CVE-2026-42789: `public_key` application accepts non-CA certificates as intermediate issuers and this enables chain\n  forgery (bsc#1266449).\n- CVE-2026-42790: Name constraints and `Subject CommonName` fallback in TLS hostname verification allows for certificate\n  forgery by MITM attacker (bsc#1266466).\n- CVE-2026-42792: permanent `epmd` DoS via connection slot exhaustion due to improper handling of exceptional\n  conditions (bsc#1272908).\n- CVE-2026-47078: relative path traversal in `zip:unzip/zip:extract` via `check_dir_level` depth-counter bypass\n  (bsc#1272909).\n- CVE-2026-48855: SFTP `READLINK` response leaks absolute backend filesystem path when root is configured (bsc#1268139).\n- CVE-2026-48856: `httpc` leaks `Authorization` headers to cross-origin redirect targets (bsc#1268141).\n- CVE-2026-48858: server-side request forgery allows FTP bounce attacks and SSRF via an unvalidated `PASV` response IP\n  address (bsc#1268142).\n- CVE-2026-49759: unbounded stack buffer overflow in SCTP error cause parsing in `inet_drv` (bsc#1268163).\n- CVE-2026-49760: stack buffer overflow in `ei_s_print_term` at very large integer (bsc#1268164).\n- CVE-2026-53422: SFTP `REALPATH` path-existence oracle allows filesystem enumeration outside configured root\n  (bsc#1270245).\n- CVE-2026-54886: SSH SFTP server denial of service via extended channel data infinite loop (bsc#1270246).\n- CVE-2026-54887: use of default cryptographic key allows predictable DTLS cookie computation during the startup window\n  (bsc#1270247).\n- CVE-2026-54891: plaintext injection towards (D)TLS client during handshake (bsc#1270250).\n- CVE-2026-55737: heap pointer corruption via signed/unsigned mismatch in `LARGE_TUPLE_EXTP` decoding in `erts`\n  external term format decoder (bsc#1272910).\n- CVE-2026-55952: missing validation allows for DoS of the TLS-1.3 server when clients send a malformed `ClientHello`\n  with mismatched PSK identity and binder list lengths (bsc#1270258).\n- CVE-2026-55953: TLS 1.2 and DTLS clients accept unoffered anonymous cipher suites and allow for server authentication\n  bypass (bsc#1272911).\n- CVE-2026-58227: TLS/DTLS denial of service via unbounded recursion on cross-signed peer certificate chain\n  (bsc#1272913).\n- CVE-2026-59250: `megaco` flex scanner buffer overflow via oversized property parm name (bsc#1272914).\n","status":"published","published":"2026-08-18T18:14:04Z","modified":"2026-08-21T09:15:05.747880529Z","updated_at":"2026-11-02T15:54:05.392906Z"},{"id":"USN-8901-1","title":"erlang vulnerabilities","description":"Wander Nauta discovered that Erlang incorrectly handled absolute paths when\nextracting zip archives. An attacker could possibly use this issue to write\narbitrary files outside of the intended directory. This issue only affected\nUbuntu 16.04 LTS, Ubuntu 18.04 LTS, and Ubuntu 20.04 LTS. (CVE-2025-4748)\n\nIt was discovered that the Erlang SFTP server did not properly limit the\nsize of packets. A remote attacker could possibly use this issue to cause\nErlang to use excessive resources, leading to a denial of service. This\nissue only affected Ubuntu 14.04 LTS, Ubuntu 16.04 LTS, and\nUbuntu 18.04 LTS. (CVE-2025-26618)\n\nIt was discovered that the Erlang SSH server did not properly limit the\nlength of algorithm names in key exchange messages. A remote attacker could\npossibly use this issue to cause Erlang to use excessive resources, leading\nto a denial of service. This issue only affected Ubuntu 14.04 LTS,\nUbuntu 16.04 LTS, and Ubuntu 18.04 LTS. (CVE-2025-30211)\n\nIt was discovered that the Erlang TFTP server incorrectly handled certain\nfile paths. A remote attacker could possibly use this issue to access files\noutside of the intended directory. (CVE-2026-21620)\n\nIt was discovered that the Erlang SFTP server incorrectly validated paths\nagainst the configured root directory. An authenticated user could possibly\nuse this issue to access files outside of the root directory.\n(CVE-2026-23942)\n\nIt was discovered that the Erlang SSH server enabled zlib compression by\ndefault and did not limit the size of decompressed data. A remote attacker\ncould possibly use this issue to cause Erlang to use excessive resources,\nleading to a denial of service. (CVE-2026-23943)\n\nIt was discovered that the Erlang HTTP server incorrectly applied directory\naccess controls to CGI scripts served via script aliases. A remote attacker\ncould possibly use this issue to bypass authentication and access protected\nCGI scripts. (CVE-2026-28808)\n\nIt was discovered that the Erlang DNS resolver used predictable transaction\nIDs and did not randomize source ports. A remote attacker could possibly\nuse this issue to perform DNS cache poisoning attacks. This issue only\naffected Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS.\n(CVE-2026-28810)\n\nIt was discovered that Erlang did not verify the signatures of designated\nOCSP responder certificates. A remote attacker could possibly use this\nissue to forge OCSP responses and bypass certificate revocation checks.\nThis issue only affected Ubuntu 26.04 LTS. (CVE-2026-32144)\n\nIt was discovered that the Erlang SFTP server incorrectly handled file\nattribute changes on open file handles. An authenticated user could\npossibly use this issue to modify the attributes of files outside of the\nroot directory. (CVE-2026-32147)\n\nIt was discovered that Erlang incorrectly allowed non-CA certificates to\nact as intermediate certificate issuers. A remote attacker could possibly\nuse this issue to forge certificate chains. (CVE-2026-42789)\n\nIt was discovered that Erlang incorrectly handled DNS name constraints\nduring hostname verification. A remote attacker could possibly use this\nissue to bypass certificate validation. This issue only affected\nUbuntu 18.04 LTS, Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and\nUbuntu 26.04 LTS. (CVE-2026-42790)\n\nIt was discovered that Erlang did not check the validity period of OCSP\nresponder certificates. A remote attacker could possibly use this issue to\nforge OCSP responses using an expired responder certificate. This issue\nonly affected Ubuntu 26.04 LTS. (CVE-2026-42791)\n\nIt was discovered that Erlang incorrectly handled relative paths when\nextracting zip archives. An attacker could possibly use this issue to write\narbitrary files outside of the intended directory. This issue only affected\nUbuntu 18.04 LTS, Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and\nUbuntu 26.04 LTS. (CVE-2026-47078)\n\nIt was discovered that the Erlang SFTP server exposed absolute paths when\nreading symbolic links. An authenticated user could possibly use this issue\nto obtain sensitive information. (CVE-2026-48855)\n\nIt was discovered that the Erlang HTTP client forwarded authorization\nheaders on cross-origin redirects. A malicious HTTP server could possibly\nuse this issue to obtain sensitive information. (CVE-2026-48856)\n\nIt was discovered that the Erlang FTP client did not validate the IP\naddress in passive mode responses. A malicious FTP server could possibly\nuse this issue to perform server-side request forgery attacks.\n(CVE-2026-48858)\n\nIt was discovered that Erlang checked the local address instead of the peer\naddress when enforcing the allowlist for distribution over TLS. A remote\nattacker could possibly use this issue to bypass access restrictions. This\nissue only affected Ubuntu 26.04 LTS. (CVE-2026-48860)\n\nIt was discovered that Erlang incorrectly handled certain SCTP ERROR\nchunks, leading to a buffer overflow. A remote attacker could possibly use\nthis issue to cause Erlang to crash, resulting in a denial of service.\n(CVE-2026-49759)\n\nIt was discovered that the Erlang erl_interface library incorrectly handled\nprinting very large integers, leading to a buffer overflow. An attacker\ncould possibly use this issue to cause Erlang to crash or execute arbitrary\ncode. (CVE-2026-49760)\n\nIt was discovered that the Erlang SFTP server incorrectly handled certain\npath resolution requests. An authenticated user could possibly use this\nissue to determine the existence of files outside of the root directory.\n(CVE-2026-53422)\n\nIt was discovered that the Erlang SFTP server incorrectly handled extended\nchannel data, leading to an infinite loop. An authenticated user could\npossibly use this issue to cause a denial of service. (CVE-2026-54886)\n\nIt was discovered that the Erlang DTLS server used a predictable cookie\nsecret on startup. A remote attacker could possibly use this issue to\nbypass source address verification. This issue only affected\nUbuntu 18.04 LTS, Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and\nUbuntu 26.04 LTS. (CVE-2026-54887)\n\nIt was discovered that Erlang TLS clients incorrectly accepted application\ndata before the handshake was completed. A remote attacker could possibly\nuse this issue to inject arbitrary data into TLS connections.\n(CVE-2026-54891)\n\nIt was discovered that the Erlang DTLS server contained a race condition\nwhen handling rapid client reconnections. A remote attacker could possibly\nuse this 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-55950)\n\nIt was discovered that Erlang did not properly validate TLS 1.3 pre-shared\nkey extensions. A remote attacker could possibly use this issue to cause\nErlang to crash, resulting in a denial of service. This issue only affected\nUbuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS.\n(CVE-2026-55952)\n\nIt was discovered that the Erlang ASN.1 decoder incorrectly handled certain\nobject identifiers. A remote attacker could possibly use this issue to\ncause Erlang to use excessive resources, leading to a denial of service.\n(CVE-2026-65634)\n\nIt was discovered that the Erlang SSH server did not properly limit the\nnumber of open channels. An authenticated user could possibly use this\nissue to cause Erlang to use excessive resources, leading to a denial of\nservice. This 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-68956)\n\nIt was discovered that the Erlang HTTP server incorrectly shared users and\ngroups between directories when using dets or mnesia authentication\nbackends. A remote attacker could possibly use this issue to bypass\nauthentication and access protected directories. (CVE-2026-74994)\n\nIt was discovered that Erlang TLS clients incorrectly accepted unsolicited\nTLS 1.3 pre-shared keys from servers. A remote attacker could possibly use\nthis issue to impersonate servers. This issue only affected\nUbuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS.\n(CVE-2026-89422)","status":"published","published":"2026-10-08T12:01:56Z","modified":"2026-10-08T19:58:53.589918012Z","updated_at":"2026-11-02T16:58:26.907654Z"}]}}