CVE-2026-55953 in OTP
Summary
by MITRE • 07/27/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/27/2026
This vulnerability represents a critical flaw in the Erlang/OTP SSL/TLS implementation that undermines fundamental security assurances provided by the transport layer. The issue stems from an incomplete validation mechanism within the client-side TLS handshake process where the ssl_handshake:hello/5 handler fails to verify that the server-selected cipher suite was actually offered by the client during the initial ClientHello message. This oversight creates a pathway for man-in-the-middle attacks that bypass certificate verification entirely, as demonstrated by the specific anonymous key exchange suites such as TLS_DH_anon_ and TLS_ECDH_anon_ that can be selected without client consent.
The technical flaw manifests in the ssl_handshake:handle_server_hello_extensions/9 function which directly installs the server-chosen cipher suite without performing a membership check against the client's previously advertised options. This behavior deviates from established TLS standards where the server must select from the intersection of offered cipher suites, as defined in RFC 5246 for TLS 1.2 and earlier versions. The vulnerability is classified under CWE-298 as it involves improper certificate validation and represents a downgrade attack vector that compromises the security model. This flaw exists only in the TLS 1.2 and earlier implementations, with TLS 1.3 client paths correctly implementing the required validation per RFC 8446 specifications.
The operational impact of this vulnerability is severe and directly enables active attack scenarios that completely bypass the certificate verification infrastructure. An on-path attacker can exploit this weakness to perform successful man-in-the-middle attacks where they respond to client connections with ServerHello messages selecting anonymous cipher suites that the client never offered. The consequence is that the entire ssl:connect function returns {ok, Socket} without any certificate validation or hostname checking, effectively allowing attackers to establish secure-looking connections using their own ephemeral parameters. This creates a scenario where all subsequent application traffic becomes readable and modifiable by the attacker, as demonstrated in the ATT&CK framework's T1573.002 technique for protocol manipulation. The vulnerability affects a broad range of OTP versions from 17.0 through 28.5.0.4 and 29.0.4, impacting ssl implementations from versions 5.3.4 through 11.7.4.
Mitigation strategies must focus on immediate version upgrades to patched releases including OTP 27.3.4.15, 28.5.0.4, and 29.0.4 or equivalent ssl versions that contain the required validation fixes. Organizations should also implement network-level protections such as certificate pinning and additional transport layer security measures to reduce attack surface. The fix requires implementing proper cipher suite intersection validation in the client-side TLS handshake process, ensuring that server-selected suites are verified against the originally offered options before being installed into the connection state. This remediation addresses the root cause by aligning with TLS specification requirements and prevents the exploitation of anonymous cipher suite selection that bypasses peer certificate verification entirely.