The vulnerability is caused by the DTLS server in Erlang/OTP initializing the cookie secret to an empty binary when it starts. Because the HMAC used to generate the cookie has no key, anyone who can observe the clear‑text ClientHello can compute a valid cookie before the server rotates the secret. This makes the cookie deterministic and allows a source‑address verification bypass within the first fifteen seconds after startup. The cookie, which is meant only as a denial‑of‑service mitigation to block spoofed source IPs, is therefore ineffective, enabling an attacker to forge handshakes and amplify DTLS traffic against the server. The flaw has a CVSS score of 6.3, does not lead to code execution, privilege escalation, or data disclosure, and its main impact is a medium‑severity denial‑of‑service through handshake amplification.

The vulnerability affects Erlang/OTP releases from 20.0 up to the final release before 29.0.3, as well as the specific sub‑releases 28.5.0.3 and 27.3.4.14. The corresponding ssl application versions are 8.2 and earlier, 11.7.3 and earlier, and 11.6.0.3 and earlier, and 11.2.12.10 and earlier. All affected releases run the DTLS server with the default empty cookie secret during the first fifteen seconds after startup, making them vulnerable.

The CVSS score of 6.3 indicates this is a medium‑severity vulnerability. The EPSS score of <1 % suggests exploitation is unlikely in the near term, and the flaw does not appear in the CISA KEV catalog. Attackers must be able to observe the plaintext ClientHello during the server’s startup window and then send spoofed DTLS packets using the forged cookie. Successful exploitation would force the server to process handshake attempts from forged IP addresses, potentially exhausting CPU or memory resources. No active exploitation techniques have been reported, but the risk of a denial‑of‑service attack remains if the vendor delay in applying the fix leaves systems exposed during startup.