highCVE-2026-55952

CVE-2026-55952 Erlang/OTP Vulnerability

The Erlang/OTP ssl application does not validate that the PSK identity list and binder list carried in a TLS 1.3 ClientHello pre-shared key extension have equal length before passing them to the session ticket handler. In tls_handshake_1_3:handle_pre_shared_key/3, an OfferedPreSharedKeys record with a mismatched number of identities and binders is forwarded directly to tls_server_session_ticket:use/4, which crashes the session ticket handler process. An unauthenticated remote attacker can send a single crafted ClientHello to a TLS 1.3 server with session tickets enabled (stateful or stateless mode) and permanently disrupt session ticket handling on that listener. New TLS 1.3 handshakes complete but subsequently crash when the server attempts to issue a session ticket, effectively making TLS 1.3 unusable on the affected listener until the ssl application is restarted. TLS 1.2 connections are not affected. This issue affects OTP from 22.2 before 29.0.3, 28.5.0.3 and 27.3.4.14 corresponding to ssl from 9.5 before 11.7.3, 11.6.0.3 and 11.2.12.10.

ProductErlang/OTP
CVSS8.2
EPSS0.00487
UpdatedJuly 14, 2026

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 22.2 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-55952 affects Erlang/OTP. The affected range is Erlang/OTP 22.2 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.

  1. Inventory every Erlang/OTP install and note the exact version.
  2. Compare each install with the affected range: Erlang/OTP 22.2 through 29.0.2, Erlang/OTP 28.x before 28.5.0.3, Erlang/OTP 27.x before 27.3.4.14.
  3. 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.
  4. If you cannot patch today, restrict internet-facing services, admin panels, and trusted internal users to trusted users and networks.
  5. Back up the current configuration before changing production systems.
  6. Review recent logs for crashes, strange admin actions, failed logins, or unexpected access.
  7. Rotate passwords, tokens, certificates, or keys if compromise is suspected.
  8. 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 22.2 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-55952?

Erlang/OTP versions listed as affected should be reviewed: Erlang/OTP 22.2 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.