Dan Gudmundsson

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.

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.

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.

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.

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.

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.

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.