Copyright © 2012 Red Hat, Inc. All rights reserved. Important 2026-07-27T15:21:29 erlang/otp: Erlang/OTP ssl client: Authentication bypass via unoffered anonymous cipher suite acceptance 7.4 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N CWE-940

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 OTP R13B03 before OTP 27.3.4.15, from OTP 28.0 before OTP 28.5.0.4, and from OTP 29.0 before OTP 29.0.4, corresponding to ssl from 3.10.7 before 11.2.12.11, from 11.3 before 11.6.0.4, and from 11.7 before 11.7.4. Whether OTP before OTP R13B03, corresponding to ssl before 3.10.7, is affected is unknown.

A flaw was found in the Erlang/OTP ssl client. This vulnerability allows an on-path attacker to bypass server authentication in TLS 1.2 (and earlier) and DTLS connections. By tricking the client into accepting an unoffered anonymous cipher suite, the attacker can complete the handshake without a valid server certificate. This enables the attacker to read and modify all subsequent application traffic, leading to significant information disclosure and integrity compromise.

Red Hat rates this flaw as Important (CVSS 7.4), lower than the CVE description alone might suggest, because successful exploitation requires an on-path (man-in-the-middle) attacker positioned between the affected Erlang/OTP TLS client and its intended server. Per CVSS scoring guidance, this network-positioning requirement is scored as Attack Complexity High. Clients that only negotiate TLS 1.3 are not affected, as the TLS 1.3 client handshake path independently validates the negotiated cipher suite. Clients using only TLS 1.3 are not affected; the TLS 1.3 client handshake path validates the negotiated cipher suite. As a workaround for TLS 1.2/DTLS clients prior to upgrading, explicitly disable anonymous cipher suites (TLS_DH_anon_*, TLS_ECDH_anon_*) in the ssl client configuration, or restrict the client to TLS 1.3-only. Red Hat Hardened Images 2026-07-28T00:00:00Z RHSA-2026:47009 erlang27-main-27.3.4.15-0.1.hum1 Red Hat OpenStack Platform 16.2 Affected erlang Red Hat OpenStack Platform 17.1 Affected erlang Red Hat OpenStack Platform 18.0 Affected erlang https://www.cve.org/CVERecord?id=CVE-2026-55953 https://nvd.nist.gov/vuln/detail/CVE-2026-55953 https://cna.erlef.org/cves/CVE-2026-55953.html https://github.com/erlang/otp/commit/064e236414614f9085cbbbd6eacf0e43c02d1b4b https://github.com/erlang/otp/commit/0a82596d425abe43dc2e0b3d74aa1557ef74051c https://github.com/erlang/otp/commit/e6ff938116b2872bccc478af7fefb56627285b77 https://github.com/erlang/otp/security/advisories/GHSA-c6cw-pr89-w882 https://osv.dev/vulnerability/EEF-CVE-2026-55953 https://www.erlang.org/doc/system/versions.html#order-of-versions