CVE intelligence and bounded remediation

CVE-2026-54887 — Erlang Erlang/Otp security vulnerability

Medium CVSS 6.3

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:init…

Severity
Medium
CVSS
6.3 (4.0)
Published
2026-07-02
CISA KEV
Not currently listed
Ecosystem
software/application
Weaknesses
CWE-1394

Affected products

  • erlang / erlang/otp
  • erlang / erlang/ssl

Showing 2 representative product identities from 6 source matches. Confirm exact affected versions with the linked vendor and NVD evidence.

Matched remediation archetype

Cryptography, certificate, signature, and channel validation

This catalog composition supplies bounded fallback guidance. Explicitly reviewed curated workflows load with the complete record below.

Check exposure

  • Inventory affected algorithms, key uses, trust stores, certificate validation settings, random sources, and plaintext channels across clients and services.
  • Determine which secrets, identities, signatures, or data protections depend on the affected primitive or validation path.
  • Check debug, compatibility, fallback, and hostname or audience override settings in build and runtime configuration.

Remediate safely

  • Use a maintained platform cryptographic API with approved algorithms, modes, parameters, randomness, and full peer identity validation.
  • Remove insecure fallback and validation bypasses; separate keys by purpose and load them from managed secret storage.
  • Plan rotation or reissuance for affected keys, certificates, tokens, hashes, or ciphertext and document compatibility sequencing.

Authoritative sources

Complete CVE record and remediation plan

The detailed catalog view below loads this exact record, its source evidence, and the full seven-phase agentic change plan.