Severity by source
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
Network-reachable with no auth required, but the 15-second timing window constraint elevates AC to H; impact is availability-only with no data exposure.
Primary rating from Vendor (EEF).
CVSS VectorVendor: EEF
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
Lifecycle Timeline
1DescriptionCVE.org
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 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 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.
AnalysisAI
The DTLS server in Erlang/OTP ssl initializes its cookie secret to a hardcoded empty binary on startup, making HMAC-based cookie computation deterministic and fully predictable to any network observer for the 0-to-15-second window before the first secret rotation. Any attacker who can observe a plaintext DTLS ClientHello during this window can forge valid cookies, bypassing the RFC 6347 §4.2.1 source address verification mechanism and enabling handshake amplification attacks with spoofed source IPs. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires three concurrent conditions to hold: the DTLS server must be within its 0-to-15-second startup window before the first cookie secret rotation occurs; the attacker must have network visibility to observe a plaintext DTLS ClientHello exchange (ClientHello is inherently unencrypted per the DTLS handshake design, so any on-path or passive observer qualifies); and the attacker must be able to send UDP packets with spoofed source addresses to the server. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The vendor-published CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N, score 6.3) captures three key constraints: the attack is network-accessible and requires no authentication, but exploitation is gated by a precise timing condition (AT:P) - the predictable window lasts only 0 to 15 seconds after each server startup. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An on-path attacker positioned to observe UDP traffic to a newly started DTLS server sends a legitimate ClientHello during the 0-to-15-second startup window, captures the server's plaintext HelloVerifyRequest, and independently computes the deterministic HMAC cookie using the publicly known empty key. The attacker then sends a high volume of ClientHellos with spoofed victim source IP addresses carrying valid forged cookies, causing the server to allocate handshake state and perform expensive cryptographic operations on behalf of non-existent peers - reflecting amplified traffic toward spoofed targets. … |
| Remediation | Upgrade Erlang/OTP to version 29.0.3, 28.5.0.3, or 27.3.4.14 (corresponding to ssl library versions 11.7.3, 11.6.0.3, or 11.2.12.10 respectively), which replace the hardcoded empty-binary initial cookie secret with a cryptographically random value. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
Denial of service in Erlang/OTP erts (inet_drv SCTP handler) lets unauthenticated remote attackers crash the BEAM VM by
Remote denial of service in Erlang/OTP's ssl application (dtls_packet_demux module) lets an unauthenticated attacker cra
Authorization bypass in Erlang OTP's inets HTTP server allows unanauthenticated remote attackers to execute CGI scripts
Denial of service in the Erlang/OTP ssl application (OTP 22.2 through 29.0.3, and the 28.5.x/27.3.x maintenance branches
Erlang OTP public_key module (versions 1.16 through 1.20.3 and 1.17.1.2) fails to cryptographically verify OCSP responde
Authentication bypass in Erlang/OTP's TLS distribution module (inet_tls_dist) lets any attacker holding a TLS certificat
Credential leakage in Erlang/OTP's inets httpc client (versions 17.0 through 29.0.2, 28.5.0.2, and 27.3.4.13) allows att
Stack-based buffer overflow in Erlang OTP's erl_interface C library (`ei_s_print_term`) crashes processes when decoding
Username enumeration via timing side-channel in Erlang/OTP SSH daemon (OTP 29.0-29.0.1) allows unauthenticated remote at
Erlang/OTP kernel inet_res DNS resolver uses predictable sequential transaction IDs and lacks source port randomization,
SSRF and FTP bounce attacks are enabled in Erlang/OTP's ftp_internal module because the PASV handler blindly trusts the
Blind plaintext injection into Erlang/OTP TLS clients allows a network-positioned attacker to insert unauthenticated APP
Same weakness CWE-1394 – Use of Default Cryptographic Key
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-41411