Fedora Account System
Red Hat Associate
Red Hat Customer
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process. The Erlang/OTP ssl TLS 1.2 (and earlier) and DTLS client does not verify that the cipher suite selected by the server in ServerHello was among the suites offered by the client in ClientHello. The client-side tls_handshake:hello/5 handler validates the negotiated protocol version and the downgrade sentinel but hands the server-chosen suite directly to ssl_handshake:handle_server_hello_extensions/9, which installs it without a membership check. The TLS 1.3 client path performs this check (per RFC 8446), so it is not affected. An on-path attacker between the client and the intended server can respond with a ServerHello selecting an anonymous key exchange suite such as TLS_DH_anon_* or TLS_ECDH_anon_* that the client never offered. Anonymous suites do not require the server to present a certificate, so the entire verify_peer and cacerts configuration is bypassed: the attacker completes the handshake with its own ephemeral parameters, no certificate is validated, no hostname is checked, and ssl:connect returns {ok, Socket}. All subsequent application traffic is readable and modifiable by the attacker. This issue affects OTP from 17.0 before 27.3.4.15, 28.5.0.4, and 29.0.4 corresponding to ssl from 5.3.4 before 11.2.12.11, 11.6.0.4, and 11.7.4.
Taking this for the Messaging SIG. Maintained Erlang builds for EL9 and EL10 are provided by the CentOS Messaging SIG, which tracks upstream and carries security backports. The fix for CVE-2026-55953 is being built there now as erlang-26.2.5.21-5. Upstream OTP did not ship a fix on the 26.x line (fixes are 27.3.4.15 / 28.5.0.4 / 29.0.4 only), so the ssl_handshake.erl client cipher-suite membership check is backported onto 26.2.5.21. These packages work on RHEL, CentOS Stream, AlmaLinux, Rocky Linux and other RHEL-compatible distributions: dnf install centos-release-messaging dnf install erlang EPEL Erlang is not tracking upstream releases, so the maintained EL9/EL10 path for this fix is the Messaging SIG rather than EPEL.
The Messaging SIG build carrying the fix has now been promoted to the release repositories on both streams: - erlang-26.2.5.21-5.el9s - erlang-26.2.5.21-5.el10s so the maintained path is available now: dnf install centos-release-messaging dnf install erlang For the record on scope: EPEL 10 has no erlang build in any of its branches, and EPEL 9 currently carries erlang-26.2.5-1.el9. Erlang on EL9/EL10 is maintained by the CentOS Messaging SIG rather than by EPEL, so closing WONTFIX here and pointing users at the SIG packages above.