CVE-2026-54887
Erlang\/Otp 20.0 – 27.3.4.14
Raw 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:XSummary
CVE-2026-54887 is a medium-severity Use of Default Cryptographic Key (CWE-1394) vulnerability in Erlang Erlang\/Otp. Its CVSS base score is 6.3 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique Reflection Amplification (T1498.002); ranked at the 16th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SC-12 (Cryptographic Key Establishment and Management) and SC-8 (Transmission Confidentiality and Integrity) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-41411
Vulnerability Data
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 (<<>>) instead of a…
more
random value. Because HMAC with an empty key is deterministic, anyone who observes the plaintext ClientHello can compute dtls_handshake:cookie(<<>>, 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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise TechniquesAI
Why these techniques?
Vulnerability directly enables DTLS handshake amplification via spoofed source addresses by bypassing cookie-based source verification (RFC 6347), mapping to reflection/amplification DoS.
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
Mitigating Controls (NIST 800-53 r5) AI
Requires cryptographic key establishment and management that generates and uses random, non-predictable keys for DTLS cookie secrets instead of an empty binary at startup.
Enforces transmission confidentiality and integrity protections that prevent an attacker from observing plaintext ClientHello messages needed to compute the deterministic cookie.
Mandates timely flaw remediation to apply the patched Erlang/OTP ssl versions that initialize the cookie secret with a random value.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Configuration management directly prohibits default keys via hardened baselines and change control.
Credential/key management practices eliminate default cryptographic keys for identities and services.
Strong authentication requirements implicitly disallow default keys but do not address key management itself.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Mandates proper key management, directly preventing use of default cryptographic keys.
Enforces secure configuration baselines that should replace default keys.
Controls software installation and configuration, reducing risk of default keys being left in place.
Change-management processes should detect and remediate default cryptographic keys.
Requires secure authentication mechanisms that would be undermined by default keys.