Dan Gudmundsson

**Name of the Vulnerable Software and Affected Versions** Erlang/OTP versions 21.0 through 27.3.4.16 Erlang/OTP versions 28.0 through 28.5.0.5 Erlang/OTP versions 29.0 through 29.0.5 stdlib versions 3.5 through 6.2.2.4 stdlib versions 7.0 through 7.3.0.1 stdlib versions 8.0 through 8.0.3 **Description** Improper validation of input quantity in the stdlib allows a remote attacker to degrade availability by providing a URI with a port component consisting of an excessively long sequence of digits. The function `uri string:get port/1` passes the port substring to `binary to integer/1` without a length bound. Consequently, a syntactically valid port of up to approximately 1.26 million digits can be converted successfully, consuming hundreds of milliseconds of arbitrary-precision arithmetic in the calling process. This conversion is triggered via every authority-parsing path in `uri string:parse/1`, including host, registered-name, and IPv4 and IPv6 forms. Any application using `uri string:parse/1` to parse attacker-supplied URIs is exposed. **Recommendations** Update Erlang/OTP to version 27.3.4.17 or later. Update Erlang/OTP to version 28.5.0.6 or later. Update Erlang/OTP to version 29.0.6 or later. Update stdlib to version 6.2.2.5 or later. Update stdlib to version 7.3.0.2 or later. Update stdlib to version 8.0.4 or later.

**Name of the Vulnerable Software and Affected Versions** Erlang/OTP versions 23.2 through 27.3.4.14 Erlang/OTP version 28.5.0.3 Erlang/OTP version 29.0.3 **Description** The ssl application fails to detect cycles when reconstructing an incomplete peer certificate chain during a TLS or DTLS handshake. Specifically, the function `handle incomplete chain/5` passes the chain to `build certificate chain/5`, which then uses `do certificate chain/7` to walk issuer relationships without a depth limit or cycle detection. If a peer provides two mutually cross-signed certificates in an unordered form, the system recurses indefinitely, causing the call stack and chain accumulator to grow without bound. An unauthenticated remote attacker can exploit this by sending a crafted certificate chain in a handshake message to exhaust memory and crash the BEAM node. This affects both servers and clients and requires only a TCP connection and a partial handshake. **Recommendations** Update Erlang/OTP to version 27.3.4.15 or later. Update Erlang/OTP to version 28.5.0.4 or later. Update Erlang/OTP to version 29.0.4 or later.

**Name of the Vulnerable Software and Affected Versions** Erlang/OTP versions 17.0 through 29.0.2 Erlang/OTP versions 28.x prior to 28.5.0.3 Erlang/OTP versions 27.x prior to 27.3.4.14 **Description** Improper enforcement of message integrity during transmission in the `tls gen connection` module allows a network-positioned attacker to inject unauthenticated plaintext that the TLS client application later treats as authenticated server data. The function `handle protocol record()` fails to reject APPLICATION DATA records that arrive in pre-handshake states when the endpoint acts as a client. An attacker can send plaintext APPLICATION DATA records during the handshake, which are buffered and delivered to the application as authenticated post-handshake data once the handshake completes. This results in the blind injection of unauthenticated bytes. The injection window is wider for TLS versions prior to TLS 1.3 than for TLS 1.3. **Recommendations** Update Erlang/OTP to version 29.0.3 or later. Update Erlang/OTP to version 28.5.0.3 or later. Update Erlang/OTP to version 27.3.4.14 or later.

**Name of the Vulnerable Software and Affected Versions** Erlang/OTP versions 22.2 through 29.0.2 Erlang/OTP version 28.5.0.3 Erlang/OTP version 27.3.4.14 ssl versions 9.5 through 11.7.2 ssl version 11.6.0.3 ssl version 11.2.12.10 **Description** The ssl application fails to validate that the PSK identity list and binder list in a TLS 1.3 ClientHello pre-shared key extension have equal length. In the function `handle pre shared key/3`, an `OfferedPreSharedKeys` record with mismatched lengths is passed to `use/4`, causing the session ticket handler process to crash. An unauthenticated remote attacker can send a crafted ClientHello to a TLS 1.3 server with session tickets enabled to disrupt session ticket handling. While new TLS 1.3 handshakes may complete, they crash when the server attempts to issue a session ticket, rendering TLS 1.3 unusable on the listener until the application is restarted. TLS 1.2 connections are not affected. **Recommendations** Update Erlang/OTP to version 29.0.3 or later. Update Erlang/OTP to a version newer than 28.5.0.3. Update Erlang/OTP to a version newer than 27.3.4.14. Update ssl to version 11.7.3 or later. Update ssl to a version newer than 11.6.0.3. Update ssl to a version newer than 11.2.12.10. Disable session tickets on TLS 1.3 servers by setting `session tickets` to disabled in the server's ssl options. Restrict the server to TLS 1.2 by setting `versions` to `['tlsv1.2']` in the server's ssl options.

**Name of the Vulnerable Software and Affected Versions** Erlang/OTP versions 25.3 through 29.0.2 Erlang/OTP versions 28.x prior to 28.5.0.3 Erlang/OTP versions 27.x prior to 27.3.4.14 ssl versions 10.9 through 11.7.2 ssl versions 11.6.x prior to 11.6.0.3 ssl versions 11.2.x prior to 11.2.12.10 **Description** A Time-of-check Time-of-use (TOCTOU) race condition exists in the `dtls packet demux` module within the ssl component. This occurs when a DTLS server listener uses a shared `dtls packet demux` `gen server` process to route UDP datagrams. An unauthenticated remote attacker can trigger a crash by rapidly sending multiple ClientHello messages from the same source address and port. This creates a race condition in the internal `gb trees` key-value store, resulting in a `{key exists, {old, Client}}` crash that terminates the demux process. Since this process is shared, all active DTLS sessions on the listener are terminated, leading to a persistent denial of service. The issue is located in the file `lib/ssl/src/dtls packet demux.erl` and only affects deployments using `ssl:listen/2` with UDP-based transport. **Recommendations** Update Erlang/OTP to version 29.0.3 or later. Update Erlang/OTP to version 28.5.0.3 or later. Update Erlang/OTP to version 27.3.4.14 or later. Update ssl to version 11.7.3 or later. Update ssl to version 11.6.0.3 or later. Update ssl to version 11.2.12.10 or later.

**Name of the Vulnerable Software and Affected Versions** Erlang/OTP versions 20.0 through 29.0.2 Erlang/OTP versions 28.0 through 28.5.0.2 Erlang/OTP versions 27.0 through 27.3.4.13 ssl versions 8.2 through 11.7.2 ssl versions 11.6.0 through 11.6.0.2 ssl versions 11.2.0 through 11.2.12.9 **Description** Use of a default cryptographic key in the DTLS server allows for predictable DTLS cookie computation during the startup window, which enables the bypass of source address verification. Upon server startup, the function `dtls server connection:initial hello/3` initializes the `previous cookie secret` variable to an empty binary instead of a random value. Since HMAC with an empty key is deterministic, an attacker observing the plaintext ClientHello can compute the `dtls handshake:cookie()` and forge a valid DTLS cookie before the first secret rotation occurs (typically within 0 to 15 seconds). This allows for DTLS handshake amplification using spoofed source addresses, bypassing the denial-of-service mitigation intended to prevent spoofed IPs from forcing the server to allocate state and perform expensive cryptographic operations. **Recommendations** Update Erlang/OTP to version 29.0.3, 28.5.0.3, or 27.3.4.14. Update ssl to version 11.7.3, 11.6.0.3, or 11.2.12.10.

**Name of the Vulnerable Software and Affected Versions** Erlang OTP versions 19.3 through 26.2.5.20 Erlang OTP versions 26.2.5.21 through 27.3.4.11 Erlang OTP versions 27.3.4.12 through 28.5.0.0 Erlang OTP versions 28.5.0.1 through 29.0.0 public key versions 1.4 through 1.15.1.6 public key versions 1.15.1.7 through 1.17.1.2 public key versions 1.17.1.3 through 1.20.3.0 public key versions 1.20.3.1 through 1.21.0 **Description** Improper certificate validation in the `pubkey cert` and `public key` modules allows a DNS nameConstraints bypass during TLS hostname verification. This occurs because `pubkey cert:validate names/6` only checks Subject Alternative Name (SAN) DNS entries against nameConstraints, meaning certificates without a SAN trivially satisfy permitted DNS constraints. Simultaneously, `public key:pkix verify hostname/3` falls back to the subject CommonName when no SAN is present, matching it against the reference hostname. This combination allows a subordinate CA with restricted DNS nameConstraints to issue a leaf certificate that an OTP TLS client accepts for an out-of-scope hostname. This bypass is reachable via `ssl:connect` using `verify peer`, a trusted CA, SNI, and the strict https hostname matcher. **Recommendations** Update Erlang OTP to version 26.2.5.21, 27.3.4.12, 28.5.0.1, or 29.0.1 depending on the current release branch. Update public key to version 1.15.1.7, 1.17.1.3, 1.20.3.1, or 1.21.1 depending on the current release branch. Use the `verify fun` option in the ssl application to ensure TLS connections fail if the end-entity certificate lacks the subjectAltName extension or a domain name, ensuring the `verify fun` does not accept the `name not permitted` error.