CVE-2026-105236: TLS 1.2 session resumption in ssl crosses SNI virtual-host client-certificate trust boundaries
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 snifun or snihosts 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 verifypeer without naming reusesessions, sslconfig:updateoptions/3 inherits the base listener's reusesessions value of true, so the default that disables reuse for client-authenticating servers does not apply. On an abbreviated handshake sslsession:isresumable/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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Erlang/OTPto a version that resolves this vulnerability.Fixed in 27.3.4.19 - Upgrade
Upgrade
Erlang/OTPto a version that resolves this vulnerability.Fixed in 28.5.0.8 - Upgrade
Upgrade
Erlang/OTPto a version that resolves this vulnerability.Fixed in 29.1.2 - Configuration
Set reuse_sessions to false for SNI virtual hosts that authenticate clients with verify_peer, unless session reuse is explicitly required and correctly named.
Erlang/OTP ssl reuse_sessions = false
Event History
Frequently Asked Questions
Which deployments are exposed?
Exposure requires multiple SNI names served from one listen socket using sni_fun or sni_hosts, TLS 1.2 session resumption, and client-certificate authentication. The names must also share a server certificate, such as a wildcard or multi-SAN certificate.
What must an attacker have to authenticate across virtual hosts?
The attacker needs a client certificate trusted by one virtual host and an established resumable TLS 1.2 session for that host. They can then attempt to resume that session while requesting another SNI name on the same listener whose client trust policy would not trust their certificate.
Can this occur when client authentication is expected to disable session reuse by default?
Yes. If an SNI option set changes to verify_peer without explicitly naming reuse_sessions, it inherits the base listener's reuse_sessions value of true. This can bypass the default behavior intended to disable reuse for client-authenticating servers.
What can be done if an update cannot be applied immediately?
Disable TLS 1.2 session reuse for the affected client-authenticating SNI configuration by explicitly setting reuse_sessions to false. TLS 1.3 does not use the affected cache and is not impacted.
How can an operator identify potentially affected configuration?
Review listeners that use sni_fun or sni_hosts and serve multiple names with a shared server certificate. Check whether any SNI-specific configuration enables verify_peer while inheriting reuse_sessions from a base listener configured with session reuse enabled.