CVE-2026-54887: Erlang/OTP DTLS Cookie Forgery via Default Cryptographic Key

Technical summary

The vulnerability stems from `dtls_server_connection:initial_hello/3` initializing `previous_cookie_secret` to an empty binary (`<<>>`) rather than a cryptographically random value at startup. RFC 6347 specifies that DTLS cookies use HMAC to prevent denial-of-service amplification attacks. However, HMAC with an empty key produces a deterministic output. An attacker who observes plaintext ClientHello traffic can invoke `dtls_handshake:cookie(<<>>, IP, Port, Hello)` to recompute the exact cookie the server would generate, bypassing the intended source address verification. The vulnerability window closes after the first cookie secret rotation, typically 15 seconds post-startup. This is classified as CWE-1394 (Use of a Broken or Risky Cryptographic Algorithm), reflecting the use of a predictable cryptographic constant in a security-critical context.

Business impact

Organizations running DTLS-dependent services (such as CoAP gateways, IoT platforms, or VPN endpoints built on Erlang/OTP) face potential amplification attacks during server restarts or deployments. An attacker exploiting this could direct high-volume traffic toward victim IP addresses by spoofing source IPs in DTLS handshake requests, potentially disrupting service availability or overwhelming downstream systems. The practical impact is limited by the 15-second exploitation window and the requirement to observe plaintext traffic, but in containerized or cloud environments with frequent restarts, the cumulative exposure may be significant.

Affected systems

The vulnerability affects Erlang/OTP ssl library versions: OTP 20.0 through OTP 29.0.2 (ssl versions 8.2 through 11.7.2), with patches available in OTP 29.0.3 (ssl 11.7.3), OTP 28.5.0.3 (ssl 11.6.0.3), and OTP 27.3.4.14 (ssl 11.2.12.10). Systems running DTLS services on vulnerable Erlang/OTP versions are at risk. Applications that do not expose DTLS endpoints or that use non-Erlang DTLS implementations are not affected. The vulnerability is specific to the DTLS server role; DTLS clients are unaffected.

Exploitability

Exploitation requires three conditions: (1) the target must be running a vulnerable DTLS server on Erlang/OTP, (2) the attacker must have network visibility to observe plaintext ClientHello messages (achievable on shared networks or through passive eavesdropping), and (3) the attacker must exploit within approximately 15 seconds of server startup. The technical bar is low—computing an HMAC is trivial—but the temporal constraint and observability requirement moderate practical exploitability. The vulnerability is not currently tracked on the CISA Known Exploited Vulnerabilities catalog, indicating no widespread active exploitation has been reported.

Remediation

Upgrade to patched versions: OTP 29.0.3 or later, OTP 28.5.0.3, or OTP 27.3.4.14 (or later in the 27.x line). Verify the corresponding ssl library version matches the patched release. For organizations unable to patch immediately, mitigation strategies include: deploying DTLS endpoints behind a network-level rate limiter or ingress filter to reduce amplification potential; minimizing server restart frequency; and implementing network-level monitoring for anomalous DTLS handshake patterns from spoofed sources.

Patch guidance

Consult the official Erlang/OTP release notes to confirm patch availability for your current version. OTP follows a versioning scheme where patches are released as incremental updates (e.g., OTP 29.0.3). Test patches in a staging environment before production deployment, particularly if your application has long-running DTLS connections or relies on specific OTP features. The ssl library upgrade should be transparent to most applications, but verify DTLS handshake behavior under normal and restart conditions.

Detection guidance

Monitor DTLS servers for signs of exploitation: (1) unexpected spikes in DTLS ClientHello messages immediately following server restarts, especially with varied source IPs, (2) ClientHello traffic from spoofed or unlikely source addresses, and (3) successful DTLS cookie validation despite mismatched source addresses (if your instrumentation tracks this). Enable logging of DTLS handshake events and correlate with server restart timestamps. Network-level indicators include high-volume UDP traffic on DTLS ports (typically 5684 for CoAP/DTLS) originating from multiple IPs targeting a single destination during narrow time windows.

Why prioritize this

Although assigned a CVSS score of 4.8 (MEDIUM), this vulnerability warrants near-term attention because: (1) the exploit window is narrow but predictable (tied to deployment schedules), (2) organizations running container orchestration with frequent restarts face cumulative exposure, and (3) amplification attacks can impact availability of collocated systems. However, it is not an emergency fix given the observability requirements and lack of current active exploitation. Prioritize based on your DTLS deployment footprint and restart frequency.

Risk score, explained

The CVSS 3.1 score of 4.8 reflects: Attack Vector = Network (unauthenticated, remote), Attack Complexity = High (requires observing plaintext traffic and timing), Privileges Required = None, User Interaction = None, Scope = Unchanged, Confidentiality Impact = Low (information leakage via amplification), Integrity Impact = Low (ability to inject traffic), and Availability Impact = None (CVSS does not score amplification DoS in this vector). The 'H' attack complexity appropriately reflects the practical constraints. In environments with high DTLS restart frequency or where amplification attacks pose significant business risk, consider this a local risk elevation.

Frequently asked questions