CVE-2026-54887 Erlang/OTP Vulnerability
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.
Quick answer
Erlang/OTP should be reviewed and updated if it matches the affected versions. The recommended fix is to apply the vendor-supported patched version or the mitigation steps below, then retest the public website with Fixnx.
Who is affected
Affected versions
- Erlang/OTP 20.0 through 29.0.2
- Erlang/OTP 28.x before 28.5.0.3
- Erlang/OTP 27.x before 27.3.4.14
Fixed versions
- Erlang/OTP 29.0.3 or later
- Erlang/OTP 28.5.0.3 or later
- Erlang/OTP 27.3.4.14 or later
How to fix it
CVE-2026-54887 affects Erlang/OTP. The affected range is Erlang/OTP 20.0 through 29.0.2, Erlang/OTP 28.x before 28.5.0.3, Erlang/OTP 27.x before 27.3.4.14. Update to Erlang/OTP 29.0.3 or later, Erlang/OTP 28.5.0.3 or later, Erlang/OTP 27.3.4.14 or later. Fix exposed systems first, especially where internet-facing services, admin panels, and trusted internal users can be reached. If abuse is suspected, review logs and rotate secrets that may have been exposed.
- Inventory every Erlang/OTP install and note the exact version.
- Compare each install with the affected range: Erlang/OTP 20.0 through 29.0.2, Erlang/OTP 28.x before 28.5.0.3, Erlang/OTP 27.x before 27.3.4.14.
- Update to Erlang/OTP 29.0.3 or later, Erlang/OTP 28.5.0.3 or later, Erlang/OTP 27.3.4.14 or later.
- If you cannot patch today, restrict internet-facing services, admin panels, and trusted internal users to trusted users and networks.
- Back up the current configuration before changing production systems.
- Review recent logs for crashes, strange admin actions, failed logins, or unexpected access.
- Rotate passwords, tokens, certificates, or keys if compromise is suspected.
- Document the change, owner, date, and final version.
Scan now. Google sign-in is only needed to unlock fix guidance.
Verify the fix
- Confirm the installed version now matches the fixed guidance: Erlang/OTP 29.0.3 or later, Erlang/OTP 28.5.0.3 or later, Erlang/OTP 27.3.4.14 or later.
- Confirm old affected versions are no longer deployed: Erlang/OTP 20.0 through 29.0.2, Erlang/OTP 28.x before 28.5.0.3, Erlang/OTP 27.x before 27.3.4.14.
- Confirm internet-facing services, admin panels, and trusted internal users is limited to the smallest needed group.
- Rerun the relevant Fixnx scan or internal security check after the change.
- Save logs, screenshots, or package output as proof of the fix.
Related categories
Trusted references
FAQ
What is affected by CVE-2026-54887?
Erlang/OTP versions listed as affected should be reviewed: Erlang/OTP 20.0 through 29.0.2, Erlang/OTP 28.x before 28.5.0.3, Erlang/OTP 27.x before 27.3.4.14.
What should I fix first?
Start with internet-facing sites, admin panels, login flows, plugins, themes, modules, packages, and systems that process user-controlled input or sensitive data.
How do I confirm the fix worked?
Apply the patched version or mitigation, clear caches where relevant, retest the affected workflow, and run a new Fixnx scan to verify public website exposure signals.
How are Fixnx security risk categories chosen?
Fixnx keeps one canonical risk page and assigns only broad, relevant categories such as ecosystem, technology area, or vulnerability class.