The Erlang/OTP ssl TLS 1.2 (and earlier) and DTLS client does not verify that the cipher suite selected by the server in ServerHello was among the suites offered by the client in ClientHello. The client-side tlshandshake:hello/5 handler validates the negotiated protocol version and the downgrade sentinel but hands the server-chosen suite directly to sslhandshake:handleserverhelloextensions/9, which installs it without a membership check. The TLS 1.3 client path performs this check (per RFC 8446), so it is not affected.

An on-path attacker between the client and the intended server can respond with a ServerHello selecting an anonymous key exchange suite such as TLSDHanon or TLSECDHanon that the client never offered. Anonymous suites do not require the server to present a certificate, so the entire verifypeer and cacerts configuration is bypassed: the attacker completes the handshake with its own ephemeral parameters, no certificate is validated, no hostname is checked, and ssl:connect returns {ok, Socket}. All subsequent application traffic is readable and modifiable by the attacker.

This issue affects OTP from OTP 17.0 before OTP 27.3.4.15, from OTP 28.0 before OTP 28.5.0.4, and from OTP 29.0 before OTP 29.0.4, corresponding to ssl from 5.3.4 before 11.2.12.11, from 11.3 before 11.6.0.4, and from 11.7 before 11.7.4. Whether OTP before OTP 17.0, corresponding to ssl before 5.3.4, is affected is unknown.

Improper Enforcement of Message Integrity During Transmission in a Communication Channel vulnerability in Erlang/OTP ssl (tlsgenconnection module) allows a network-positioned attacker to inject unauthenticated plaintext that the TLS client application later treats as authenticated server data.

The function tlsgenconnection:handleprotocolrecord/3 rejects APPLICATIONDATA records that arrive in pre-handshake states when the TLS endpoint acts as a server, but does not apply the same check when the endpoint acts as a client. A network-positioned attacker can send plaintext APPLICATIONDATA records to the client during the handshake. The records are buffered and, once the handshake completes successfully, delivered to the application as if they were authenticated post-handshake data. The attacker cannot observe the client's response or steer the connection, so the impact is limited to blind injection of unauthenticated bytes. The injection window is wider for TLS versions prior to TLS 1.3 than for TLS 1.3.

This vulnerability is associated with program file lib/ssl/src/tlsgenconnection.erl.

TLS 1.3 is affected starting with OTP 22.0, when TLS 1.3 support was added.

This issue affects OTP from OTP 17.0 before OTP 27.3.4.14, from OTP 28.0 before OTP 28.5.0.3, and from OTP 29.0 before OTP 29.0.3, corresponding to ssl from 5.3.4 before 11.2.12.10, from 11.3 before 11.6.0.3, and from 11.7 before 11.7.3. Whether OTP before OTP 17.0, corresponding to ssl before 5.3.4, is affected is unknown.

DTLS listener crash via race condition in dtlspacketdemux causes denial of service for all sessions

DTLS server cookie bypass during startup window due to empty initial cookie secret

The Erlang/OTP ssl application does not detect cycles when reconstructing an incomplete peer certificate chain during a TLS or DTLS handshake. In sslcertificate:handleincompletechain/5, the received chain is passed to sslcertificate:buildcertificatechain/5, which walks issuer relationships via sslcertificate:docertificatechain/7 with no cycle detection and no depth limit. When the peer supplies two mutually cross-signed certificates in unordered form (A issues B, B issues A), the issuer lookup alternates between the two certificates and the pair of functions recurses indefinitely, growing the call stack and chain accumulator without bound.

An unauthenticated remote attacker can send a crafted certificate chain in a TLS or DTLS Certificate handshake message to exhaust available memory and crash the BEAM node. Only a TCP connection and a partial handshake are required; no authentication or completed handshake is needed, and both TLS/DTLS servers and clients are affected when processing peer certificate messages.

This issue affects OTP from OTP 23.2 before OTP 29.0.4, OTP 28.5.0.4 and OTP 27.3.4.15, corresponding to ssl from 10.2 before 11.7.4, 11.6.0.4 and 11.2.12.11.

The Erlang/OTP ssl application does not validate that the PSK identity list and binder list carried in a TLS 1.3 ClientHello pre-shared key extension have equal length before passing them to the session ticket handler. In tlshandshake13:handlepresharedkey/3, an OfferedPreSharedKeys record with a mismatched number of identities and binders is forwarded directly to tlsserversessionticket:use/4, which crashes the session ticket handler process.

An unauthenticated remote attacker can send a single crafted ClientHello to a TLS 1.3 server with session tickets enabled (stateful or stateless mode) and permanently disrupt session ticket handling on that listener. New TLS 1.3 handshakes complete but subsequently crash when the server attempts to issue a session ticket, effectively making TLS 1.3 unusable on the affected listener until the ssl application is restarted. TLS 1.2 connections are not affected.

This issue affects OTP from OTP 22.2 before OTP 29.0.3, OTP 28.5.0.3 and OTP 27.3.4.14, corresponding to ssl from 9.5 before 11.7.3, 11.6.0.3 and 11.2.12.10.

Distribution-over-TLS LAN allowlist silently bypassed due to sockname/peername confusion in inettlsdist

Improper Certificate Validation vulnerability in Erlang OTP publickey (pubkeyocsp module) allows OCSP designated-responder authorization bypass via missing signature verification.

The OCSP response validation in publickey:pkixocspvalidate/5 does not verify that a CA-designated responder certificate was cryptographically signed by the issuing CA. Instead, it only checks that the responder certificate's issuer name matches the CA's subject name and that the certificate has the OCSPSigning extended key usage. An attacker who can intercept or control OCSP responses can create a self-signed certificate with a matching issuer name and the OCSPSigning EKU, and use it to forge OCSP responses that mark revoked certificates as valid.

This affects SSL/TLS clients using OCSP stapling, which may accept connections to servers with revoked certificates, potentially transmitting sensitive data to compromised servers. Applications using the publickey:pkixocspvalidate/5 API directly are also affected, with impact depending on usage context.

This vulnerability is associated with program files lib/publickey/src/pubkeyocsp.erl and program routines pubkeyocsp:isauthorizedresponder/3.

This issue affects OTP from OTP 27.0 before OTP 28.4.2 and OTP 27.3.4.10, corresponding to publickey from 1.16 before 1.20.3 and 1.17.1.2, and ssl from 11.2 before 11.5.4 and 11.2.12.7.