CVE-2026-89422 in OTP
Summary
by MITRE • 09/22/2026
Key Exchange without Entity Authentication vulnerability in Erlang/OTP ssl allows a peer that answers a TLS 1.3 client connection to impersonate the intended server. A pre_shared_key extension in the ServerHello that the client never offered causes the client to complete the handshake without validating the server's certificate, so ssl:connect returns {ok, Socket} against a peer holding no certificate, no private key and no prior session.
tls_client_connection_1_3:handle_server_hello/2 passes the received extension to tls_gen_connection_1_3:handle_resumption/2, which sets resumption = true on its mere presence without checking that the client offered a PSK. tls_handshake_1_3:get_pre_shared_key/4 meanwhile falls back to the all-zero "no PSK" value and keys the handshake with the ordinary non-PSK schedule, so the attacker's own ephemeral key suffices. The resumption flag then routes maybe_resumption/1 straight to wait_finished, skipping the certificate-handling states, so certificate path validation, verify_fun, hostname verification, partial_chain, CRL checking and OCSP stapling are all bypassed. The default client configuration is affected; clients restricted to TLS 1.2 are not.
This issue affects OTP from OTP 22.2 before OTP 27.3.4.18, OTP 28.5.0.7, and OTP 29.1.1, corresponding to ssl from 9.5 before 11.2.12.13, 11.6.0.6, and 11.7.7.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/23/2026
The Erlang/OTP SSL module contains a critical vulnerability in its TLS 1.3 implementation that allows an attacker to perform entity authentication bypass during the key exchange phase. This flaw enables a malicious peer responding to a client connection request to impersonate the intended server without possessing any valid certificates, private keys, or prior session state with the victim. The root cause lies in how the SSL library processes the pre_shared_key extension within the ServerHello message sent by the server during the handshake process. Under normal TLS 1.3 operations, a client only expects to resume a previous session if it explicitly offered a Pre-Shared Key (PSK) in its ClientHello. However, this vulnerability arises because the implementation incorrectly interprets the mere presence of a pre_shared_key extension in the ServerHello as an indication that resumption is active, regardless of whether the client actually initiated such a request.
The technical flaw manifests within specific internal functions responsible for handling TLS 1.3 handshake messages. Specifically, the tls_client_connection_1_3:handle_server_hello/2 function passes the received extension data to tls_gen_connection_1_3:handle_resumption/2. This downstream function sets an internal resumption flag to true solely based on the presence of the extension in the server's response, failing to verify that the client had previously offered a PSK. Concurrently, the function tls_handshake_1_3:get_pre_shared_key/4 detects no valid pre-shared key context and defaults to using all-zero values for the PSK identifier. Consequently, the handshake proceeds with the standard non-PSK key schedule, meaning the attacker can use their own ephemeral keys to establish encryption without needing any prior shared secrets or certificate-based authentication materials.
The operational impact of this vulnerability is severe because it completely bypasses critical security controls designed to verify server identity. When the resumption flag is incorrectly set to true, the handshake state machine routes execution directly from the ServerHello processing phase to the wait_finished state via maybe_resumption/1. This path skips all intermediate states responsible for certificate handling and validation. As a result, essential verification steps are entirely omitted, including certificate chain validation, custom verify_fun callbacks, hostname verification against the server's identity, partial chain acceptance logic, Certificate Revocation List (CRL) checking, and Online Certificate Status Protocol (OCSP) stapling checks. The ssl:connect function consequently returns {ok, Socket}, indicating a successful connection to an unauthenticated peer that holds no certificate or private key corresponding to the intended target server.
This vulnerability is classified under CWE-295 Improper Certificate Validation and aligns with MITRE ATT&CK techniques related to Man-in-the-Middle attacks where authentication mechanisms are bypassed. The flaw specifically affects TLS 1.3 implementations within Erlang/OTP, while clients restricted exclusively to TLS 1.2 remain unaffected due to the different handshake structure of that protocol version which does not utilize this specific resumption logic in the same manner. The issue impacts OTP versions from 22.2 up through various patched releases before 27.3.4.18 and 28.5.0.7, as well as OTP 29.1.1. Correspondingly, the ssl application is affected in versions prior to 11.2.12.13, 11.6.0.6, and 11.7.7 respectively.
To mitigate this vulnerability, organizations must upgrade their Erlang/OTP installations to the patched versions mentioned above immediately. For environments where upgrading is not immediately feasible, implementing strict network-level controls such as mutual TLS or IP whitelisting can provide an additional layer of defense against unauthorized server impersonation. Additionally, developers should review application code that relies on ssl:connect for critical operations and consider adding explicit post-connection verification steps if the library version cannot be updated promptly. It is crucial to ensure that all client endpoints are patched to prevent attackers from exploiting this logic error to intercept sensitive data or inject malicious content under the guise of a legitimate server identity.