CVE-2026-105236

Ein Angreifer kann mehrere Schwachstellen in Erlang/OTP ausnutzen, um Sicherheitsvorkehrungen zu umgehen oder einen Denial of Service zu verursachen.

## Summary Improper Certificate Validation vulnerability in the ssl application in Erlang/OTP allows a client that holds a certificate trusted by one SNI virtual host to authenticate to a second SNI virtual host on the same listener by resuming its TLS 1.2 session there. A server that serves several SNI names from one listen socket through `sni_fun` or `sni_hosts` keeps one pre-TLS 1.3 session cache per listener and does not bind a cached session to the SNI name or client trust policy that established it. When an SNI option set switches to `verify_peer` without naming `reuse_sessions`, `ssl_config:update_options/3` inherits the base listener's `reuse_sessions` value of true, so the default that disables reuse for client-authenticating servers does not apply. On an abbreviated handshake `ssl_session:is_resumable/4` checks only that the cached session uses one of the current server certificates and carries some peer certificate, and never revalidates that certificate against the CA selected for the requested name. The names must share a server certificate, which is common with wildcard or multi-SAN certificates. TLS 1.3 does not use this cache and is not affected. This issue affects OTP from OTP 18.0 before OTP 27.3.4.19, OTP 28.5.0.8, and OTP 29.1.2, corresponding to ssl from 7.0 before 11.2.12.14, 11.6.0.7, and 11.7.8. ## Details **1. One session cache per listener.** `tls_socket:listen/3` starts one pre-TLS 1.3 session-ID tracker per listen socket via `session_id_tracker/2`. Every SNI virtual host served from that socket shares it, and the cached `#session{}` record stores the peer and server certificates but no SNI name and no client trust policy. **2. The SNI option set inherits session reuse.** When the ClientHello carries a server name, `ssl_gen_statem:handle_sni_extension/2` and `handle_sni_hostname/2` call `update_ssl_options_from_sni/2`, which passes the base listener options as fallback into `ssl_config:update_options/3`. The base listener's `verify_none` has already produced `reuse_sessions = true`. `ssl_config:opt_reuse_sessions/3` computes a `false` default for `verify_peer`, but `get_opt_bool/4` finds the inherited value and keeps it when the SNI option list does not mention `reuse_sessions`. **3. Resumption does not revalidate the peer certificate.** On an abbreviated handshake `ssl_handshake:select_session/8` calls `ssl_session:server_select_session/5`, which accepts the cached session when `ssl_session:is_resumable/4` finds that it is marked resumable, that `is_owncert/2` matches one of the current server certificates, that `reusable_options/2` sees any cached peer certificate when `fail_if_no_peer_cert` is set, and that the `reuse_session` fun agrees. Nothing compares the ClientHello server name with the name that created the session, and the cached peer certificate is not validated against the CA selected for the new name. **4. Result.** A client whose certificate chains to the lower-trust name's CA completes a full handshake there, then presents the same session ID with the higher-trust server name. The server resumes the session, reports `session_resumption` as true and the low-trust peer certificate through `ssl:peercert/1`, and the application behind the protected name sees an authenticated mTLS peer. `is_owncert/2` is why both names must share a server certificate. ## Proof of concept 1. Create one server certificate with subject alternative names `low.test` and `high.test`, two self-signed client CAs (`low-ca`, `high-ca`), and one client certificate signed by `low-ca`. 2. Start an `ssl:listen/2` server on TLS 1.2 with `{verify, verify_none}` and an `sni_fun` that returns `{verify, verify_peer}`, `{fail_if_no_peer_cert, true}` and the `low-ca` or `high-ca` `cacertfile` for the respective name. Do not set `reuse_sessions` anywhere. 3. Connect with `openssl s_client -servername high.test -tls1_2 -no_ticket` using the low client certificate. The server rejects the handshake with `unknown_ca`. 4. Connect with `-servername low.test` and the same certificate, saving the session with `-sess_out`. The handshake succeeds. 5. Connect with `-servername high.test` and `-sess_in` pointing at the saved session. The server resumes the session, `ssl:connection_information/2` reports `session_resumption` true for `high.test`, and the application behind the protected name serves the request to a client whose certificate `high-ca` never issued. ## Impact A client holding a certificate issued by the lower-trust SNI name's CA connects to the higher-trust name as a fully authenticated mTLS peer and obtains whatever that service grants on a successful client-certificate handshake. Multi-tenant or partner-facing listeners that separate trust domains by SNI name are affected. ## Workarounds - Set `{reuse_sessions, false}` in each SNI service's option set, or in the base listener options. The reporter's proof of concept confirmed that this blocks the cross-name resumption. - Serve distinct SNI trust domains on separate listen sockets, which gives each its own session cache. - Restrict the listener to TLS 1.3 with `{versions, ['tlsv1.3']}`. TLS 1.3 does not use the session-ID cache. ## Configurations Exploitation requires all of the following. One TLS listener serves at least two SNI names through `sni_fun` or `sni_hosts`. The names use the same server certificate but select different client CAs with `verify_peer`. TLS 1.2 or earlier is enabled. No SNI option set sets `reuse_sessions` to false while the base listener's effective value is true, which is the default when the base listener uses `verify_none`. The attacker holds a client certificate that the lower-trust name accepts.