CVE-2026-55953: 
CBL Mariner Schwachstellenanalyse und -minderung

CVE-2026-55953 is a TLS/DTLS cipher suite validation bypass vulnerability in Erlang/OTP's SSL library affecting TLS 1.2 (and earlier) and all DTLS versions. The flaw allows an on-path attacker to force the use of an anonymous cipher suite never offered by the client, completely bypassing server certificate verification. It was disclosed on July 27, 2026, and affects OTP from R13B03 before 27.3.4.15, from 28.0 before 28.5.0.4, and from 29.0 before 29.0.4 (corresponding to ssl library versions 3.10.7–11.7.4). The TLS 1.3 client path is not affected. It carries a CVSS v4.0 base score of 9.1 (Critical) (GitHub Advisory).

The root cause is classified as CWE-757 (Selection of Less-Secure Algorithm During Negotiation / Algorithm Downgrade). In the vulnerable code path, the client-side tls_handshake:hello/5 handler validates the negotiated protocol version and downgrade sentinel but passes the server-chosen cipher suite directly to ssl_handshake:handle_server_hello_extensions/9, which installs it without checking whether it was among the suites offered in the ClientHello. An on-path attacker can respond with a ServerHello specifying an anonymous key exchange suite such as TLS_DH_anon_* or TLS_ECDH_anon_*; because anonymous suites require no server certificate, the entire verify_peer and cacerts configuration is bypassed, no hostname check occurs, and ssl:connect returns {ok, Socket} as if the handshake succeeded normally. The fix adds a validate_cipher_suite/2 function in ssl_handshake.erl that performs a membership check and throws a fatal ILLEGAL_PARAMETER alert if the server-selected suite was not offered by the client (GitHub Advisory, Patch Commit).

Successful exploitation enables a full man-in-the-middle (MitM) attack against any TLS 1.2 or DTLS connection made by a vulnerable Erlang/OTP client. The attacker can read and modify all application-layer traffic in the session, effectively nullifying transport-layer encryption and authentication. This exposes sensitive data (credentials, API tokens, business data) to interception and allows injection of malicious content, with high confidentiality and integrity impact on the vulnerable system (GitHub Advisory).

There is no public proof-of-concept exploit or evidence of in-the-wild exploitation at this time (Feedly). Exploitation requires an on-path network position between the client and server (attack requirement: Present), meaning the attacker must be able to intercept and modify TLS handshake traffic — this limits opportunistic exploitation but is feasible in shared network environments, compromised infrastructure, or via BGP/DNS hijacking. No threat actor attribution has been reported. The EPSS score is approximately 0.245%, and the vulnerability is not listed in the CISA KEV catalog. NVD SSVC assessment classifies exploitation as "none" and automatable as "no" (Feedly).

1. Positioning: Gain an on-path network position between the target Erlang/OTP TLS client and its intended server (e.g., via ARP spoofing on a local network, rogue Wi-Fi access point, BGP hijacking, or DNS poisoning).
2. Intercept ClientHello: Capture the TLS ClientHello message sent by the vulnerable Erlang/OTP client, which lists the cipher suites it supports (none of which will be anonymous suites under a typical configuration).
3. Craft malicious ServerHello: Forge a ServerHello response selecting an anonymous cipher suite such as TLS_ECDH_anon_WITH_AES_128_CBC_SHA or TLS_DH_anon_WITH_AES_256_CBC_SHA — suites the client never offered.
4. Complete handshake without certificate: Because the vulnerable handle_server_hello_extensions/9 installs the attacker-chosen suite without a membership check, and anonymous suites require no server certificate, the handshake completes without any certificate validation or hostname check. The client's ssl:connect returns {ok, Socket}.
5. Intercept and modify traffic: With the MitM position established and the session under attacker-controlled ephemeral key material, all subsequent application-layer data is readable and modifiable by the attacker (GitHub Advisory).

• Network: Unexpected TLS handshakes completing with anonymous cipher suites (e.g., TLS_DH_anon_*, TLS_ECDH_anon_*) visible in network captures or TLS inspection logs; anomalous ARP traffic or duplicate MAC/IP mappings suggesting ARP spoofing on local segments.
• Logs: Erlang/OTP SSL debug logs (enabled via ssl:start() with logging) showing a ServerHello cipher suite that differs from any suite listed in the application's configured ciphers option; absence of certificate validation log entries for connections that should require verify_peer.
• Process/Application: Erlang applications receiving {ok, Socket} from ssl:connect on connections where certificate errors would be expected; unexpected data integrity failures or application-layer anomalies suggesting content modification in transit.

Upgrade Erlang/OTP to one of the patched versions: OTP 27.3.4.15, OTP 28.5.0.4, or OTP 29.0.4 (corresponding to ssl library versions 11.2.12.11, 11.6.0.4, and 11.7.4 respectively). As an immediate workaround, configure TLS clients to use only TLS 1.3 by setting {versions, ['tlsv1.3']} in ssl options, as the TLS 1.3 code path already performs the cipher suite membership check and is not affected. Additionally, deploy network-level controls (segmentation, encrypted tunnels, or mutual authentication at the network layer) to reduce the risk of on-path interception in environments that cannot immediately upgrade (GitHub Advisory, Patch Commit).

The vulnerability was responsibly reported by Jonatan Männchen (GitHub: maennchen) and remediated by IngelaAndin (Erlang/OTP core team), with u3s as remediation reviewer, as credited in the official GitHub Security Advisory. The advisory was published by the Erlang Ecosystem Foundation (EEF) as the CNA. Coverage has appeared on security aggregation sites including SecurityOnline.info and INCIBE-CERT, indicating moderate community awareness. No major vendor statements beyond the Erlang/OTP project itself or significant social media controversy have been identified (GitHub Advisory).