CVE-2026-94200: TLS 1.3 client ticket store crashed by NewSessionTicket with empty early_data extension in ssl
Improper Validation of Consistency within Input vulnerability in Erlang OTP ssl (tlshandshake13, sslhandshake and tlsclientticketstore modules) allows a malicious TLS 1.3 server to cause a denial of service of the ssl application on the client node.
The TLS 1.3 client decodes the extensions of a NewSessionTicket message as if they came from EncryptedExtensions. It therefore accepts a 0-length earlydata extension, a form that is only valid in ClientHello and EncryptedExtensions. With {sessiontickets, auto}, the client stores the ticket in the node-global tlsclientticketstore. On the next automatic resumption, tlshandshake13:getmaxearlydata/1 crashes the store with a caseclause. Repeated crashes can exceed the restart intensity of the ssl supervisors, which use the restforone strategy, and take down ssl for all connections on the node.
This issue affects OTP from OTP 23.3 before OTP 27.3.4.19, OTP 28.5.0.8, and OTP 29.1.2, corresponding to ssl from 10.3 before 11.2.12.14, 11.6.0.7, and 11.7.8.
Affected Software
Event History
Frequently Asked Questions
Which client deployments are exposed to this denial of service?
TLS 1.3 clients running affected Erlang/OTP releases are exposed when they use automatic session tickets, {session_tickets, auto}. The ticket is stored in the node-global tls_client_ticket_store, so repeated crashes can disrupt ssl for all connections on that client node.
What must an attacker be able to do to trigger the issue?
An attacker must operate or control a TLS 1.3 server that the affected client connects to. The server sends a NewSessionTicket containing a zero-length early_data extension, then the failure occurs on the client's next automatic session resumption.
Are default settings affected?
The described vulnerable path requires {session_tickets, auto}. The provided information does not state whether that setting is enabled by default.
What versions contain the fixes?
Fixed OTP releases are 27.3.4.19, 28.5.0.8, and 29.1.2. Fixed ssl releases are 11.2.12.14, 11.6.0.7, and 11.7.8; affected ranges begin at OTP 23.3 and ssl 10.3.
How can I recognize that this issue is being exploited or has occurred?
The relevant failure is a case_clause crash in tls_handshake_1_3:get_max_early_data/1 during automatic session resumption. Repeated ssl application crashes may exceed supervisor restart intensity and cause ssl to become unavailable for all connections on the node.