CVE-2026-54887

DTLS server cookie bypass during startup window due to empty initial cookie secret

MEDIUM
4.8
CVSS Score
Published: July 2, 2026 at 04:06 PM UTC
Updated: October 25, 2026 at 09:10 PM UTC
2 products affected across 1 vendorErlang /otpErlang /ssl

Using OTP by Erlang?

Get instant alerts when new vulnerabilities affect OTP - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
MEDIUM4.8
Exploit prediction
EPSS 0.2%
SSVC
No known exploit

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 (<<>>) 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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

20.0 ≤ v < 27.3.4.1428.0 ≤ v < 28.5.0.329.0 ≤ v < 29.0.320.08.2e594aad2f87aab39e99fccf9e021bc94e0bbf7d4
Vendor states this is fixed in 888e3bcd72d5406016b9e0de741026bc2a6f114d (fixed)
Affected range stops below 27.3.4.14, so it looks safe — our inference, not a vendor statement
Affected range stops below 28.5.0.3, so it looks safe — our inference, not a vendor statement
Affected range stops below 29.0.3, so it looks safe — our inference, not a vendor statement
11.3 ≤ v < 11.6.0.311.7 ≤ v < 11.7.38.2 ≤ v < 11.2.12.10
Affected range stops below 11.2.12.10, so it looks safe — our inference, not a vendor statement
Affected range stops below 11.6.0.3, so it looks safe — our inference, not a vendor statement
Affected range stops below 11.7.3, so it looks safe — our inference, not a vendor statement

Remediation

No guide yet

No remediation guidance has been written for this CVE yet. What the record does show:

References (5)

SSVC — Action Prioritization

SSVCNo known exploitNot automatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

Attack Vector
NETWORK
Complexity
HIGH
Privileges
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
LOW
Integrity
LOW
Availability
NONE
Vector?

Quick Info

StatusMODIFIED
CWE
CWE-1394

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card