CVE-2026-89422: 
Erlang OTP Analyse et atténuation des vulnérabilités

CVE-2026-89422 is a Key Exchange without Entity Authentication vulnerability (CWE-322) in the Erlang/OTP ssl application's TLS 1.3 client implementation, allowing an unauthenticated attacker to completely impersonate any TLS 1.3 server to an affected client. The flaw was disclosed on September 22, 2026, and affects OTP versions from 22.2 up to (but not including) the patched releases OTP 27.3.4.18, 28.5.0.7, and 29.1.1, corresponding to ssl library versions 9.5 through 11.2.12.13, 11.6.0.6, and 11.7.7. It carries a CVSS v4.0 base score of 9.3 (Critical). The vulnerability was discovered and responsibly disclosed by Milad Nasr and Luna Tong at Anthropic (GitHub Advisory, ENISA EUVD).

The root cause (CWE-322) lies in two interacting bugs introduced in OTP 22.2 (commit 21b8a1b). First, tls_gen_connection_1_3:handle_resumption/2 sets the resumption = true flag on the mere presence of a pre_shared_key extension in the ServerHello, without verifying that the client ever offered a PSK. Second, tls_handshake_1_3:get_pre_shared_key/4 silently fell back to an all-zero "no PSK" value when no matching ticket existed, rather than aborting. The combination causes maybe_resumption/1 to route the client state machine directly from wait_ee to wait_finished, entirely skipping the wait_cert_cr, wait_cert, and wait_cv states — meaning certificate path validation, verify_fun, hostname verification, partial chain processing, CRL checking, and OCSP stapling are all bypassed. Because the handshake is keyed with the ordinary non-PSK ECDHE schedule, any peer that can complete an ECDHE exchange (requiring no certificate or private key) can impersonate any server. The fix (commits afec515, 98c66c8, fd1d9d0) makes get_pre_shared_key/4 abort with a fatal illegal_parameter alert ({unsolicited_pre_shared_key, _}) when the server sends a PSK the client never offered, and moves the handle_resumption/2 call to after PSK validation as defense-in-depth (GitHub Advisory, Fix Commit).

Successful exploitation results in a complete server-authentication bypass: the client's ssl:connect/4 returns {ok, Socket} against a peer that holds no certificate, no private key, and no prior session, while the client believes the connection is fully authenticated and encrypted. The attacker holds all TLS traffic keys and can read everything the application sends (credentials, tokens, API keys, request bodies) and forge every server response, enabling full man-in-the-middle attacks on encrypted communications. Any Erlang/OTP consumer of ssl:connect when TLS 1.3 is negotiated is affected by default, including httpc over HTTPS, database and messaging client libraries, and TLS distribution clients; the session_tickets modes manual and auto are equally affected on any first connection to a host where no ticket has been cached (GitHub Advisory).

No public proof-of-concept exploit code has been published, and there is no confirmed evidence of in-the-wild exploitation as of the disclosure date (ENISA EUVD). The vulnerability is classified as automatable (NVD SSVC: automatable = yes) and requires no privileges, no user interaction, and no special preconditions beyond being able to answer a TLS 1.3 connection — making it exploitable by either a malicious host the client connects to or an on-path network attacker. The EPSS score is approximately 0.368%, reflecting low current exploitation probability. The vulnerability is not listed in the CISA KEV catalog at this time. No threat actor attribution has been reported.

1. Position: The attacker either controls a server the victim client connects to (e.g., via DNS spoofing, BGP hijacking, or a rogue Wi-Fi access point) or is on-path and can intercept/answer the TCP connection before the legitimate server responds.
2. Receive ClientHello: Accept the TCP connection and read the client's TLS 1.3 ClientHello. Parse the legacy_session_id field and the client's x25519 key_share extension — both are required to craft a valid ServerHello that the client will not reject before examining the PSK extension.
3. Craft malicious ServerHello: Construct a ServerHello that echoes the client's legacy_session_id, includes a valid supported_versions extension (TLS 1.3), a freshly generated ephemeral x25519 key_share, and — critically — a pre_shared_key extension (type 0x0029) with selected_identity = 0, which the client never offered.
4. Derive handshake keys: Using the ECDHE shared secret computed from the client's x25519 public key and the attacker's ephemeral private key, derive the RFC 8446 §7.1 handshake traffic secrets (no PSK needed; use the all-zero early secret).
5. Send encrypted flight: Send the ServerHello, a ChangeCipherSpec record, and an encrypted record containing only EncryptedExtensions and Finished (no Certificate or CertificateVerify). The Finished verify data is computed from the attacker's own handshake transcript and keys.
6. Client completes handshake: On vulnerable OTP versions, the client's handle_resumption/2 sets resumption = true on the mere presence of the PSK extension, routes past all certificate-handling states, and ssl:connect returns {ok, Socket} — the attacker now holds all application traffic keys and can read/forge all subsequent data (GitHub Advisory, Fix Commit).

• Application Behavior: ssl:peercert/1 returns {error, no_peercert} on a connection where {verify, verify_peer} is configured — this should never occur on a legitimate TLS 1.3 connection.
• Application Behavior: ssl:connection_information/2 reports {session_resumption, true} for a client that never held a session ticket for the target host (e.g., on a first connection).
• Network: Unexpected TLS ServerHello messages containing a pre_shared_key extension (type 0x0029) in responses to ClientHellos that did not include a pre_shared_key extension.
• Network: TLS handshakes that complete without a Certificate or CertificateVerify message from the server in a full (non-resumption) TLS 1.3 flow.
• Logs: On patched systems, OTP SSL logs or application error logs showing {tls_alert, {illegal_parameter, ...}} with reason unsolicited_pre_shared_key — indicating an attempted exploit was blocked.
• Network: Anomalous on-path traffic interception patterns such as asymmetric TCP routing, unexpected ARP/DNS responses, or BGP route changes preceding TLS connection establishment to sensitive endpoints (GitHub Advisory).

Upgrade to one of the patched OTP releases: OTP 27.3.4.18, OTP 28.5.0.7, or OTP 29.1.1 (corresponding to ssl library versions 11.2.12.13, 11.6.0.6, and 11.7.7 respectively). If an immediate upgrade is not possible, the only effective workaround is to restrict all affected clients to TLS 1.2 by setting {versions, ['tlsv1.2']} in the ssl client options — this avoids the vulnerable TLS 1.3 code path entirely at the cost of losing TLS 1.3. There is no configuration option that both retains TLS 1.3 and mitigates the vulnerability on unpatched versions. Applications using httpc, database drivers, messaging clients, or any other Erlang/OTP SSL consumer should be prioritized for patching (GitHub Advisory).

The vulnerability was credited to Milad Nasr and Luna Tong at Anthropic, who performed responsible disclosure to the Erlang/OTP project. The advisory was published by IngelaAndin (an Erlang/OTP maintainer) on September 22, 2026. Early community discussion appeared on Mastodon and vulnerability aggregator platforms shortly after disclosure. The NVD SSVC assessment classified the vulnerability as automatable with total technical impact, reflecting the severity of the authentication bypass. No major media coverage or significant public researcher commentary beyond the official advisory and standard vulnerability database entries has been identified at this time (GitHub Advisory, ENISA EUVD).