CVE-2026-55950 Erlang/OTP Vulnerability
Time-of-check Time-of-use (TOCTOU) race condition vulnerability in Erlang/OTP ssl (dtls_packet_demux module) allows an unauthenticated remote attacker to crash all active DTLS sessions on a listener. A DTLS server listener uses a single shared dtls_packet_demux gen_server process to route incoming UDP datagrams to the correct connection handler. When a DTLS client reconnects rapidly from the same source address and port (sending multiple ClientHello messages in quick succession), a race condition in the demux's internal gb_trees key-value store causes a {key_exists, {old, Client}} crash, terminating the demux process. Because the demux is shared across all DTLS associations on that listener, its crash immediately kills every active DTLS session, not just the attacker's. The attack is pre-authentication: the attacker only needs to send UDP datagrams containing valid ClientHello messages from the same source IP and port before the intermediate DOWN monitor message is processed by the gen_server. No credentials, no completed handshake, and no special configuration are required, and the crash can be repeated indefinitely to create a persistent denial of service for all clients of that listener. This vulnerability is associated with program file lib/ssl/src/dtls_packet_demux.erl. This issue affects OTP from OTP 25.3 before 29.0.3, 28.5.0.3, and 27.3.4.14 corresponding to ssl from 10.9 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 25.3 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-55950 affects Erlang/OTP. The affected range is Erlang/OTP 25.3 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 25.3 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 25.3 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-55950?
Erlang/OTP versions listed as affected should be reviewed: Erlang/OTP 25.3 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.