John Högberg

Inefficient algorithmic complexity in the asn1 OBJECT IDENTIFIER decoder allows a remote unauthenticated attacker to cause a denial of service by sending a crafted OID during the TLS handshake. The issue occurs because the decoder accumulates a base-128 subidentifier into an unbounded integer, resulting in quadratic total work relative to the size of a single subidentifier. This behavior is present in the `asn1rtt ber:dec subidentifiers/3` function within `lib/asn1/src/asn1rtt ber.erl`, the `asn1rtt per common:dec subidentifiers/3` function in `lib/asn1/src/asn1rtt per common.erl`, and the `asn1rtt jer:json2oid/1` function in `lib/asn1/src/asn1rtt jer.erl`. The vulnerable decoder is used in every ASN.1 module containing an OBJECT IDENTIFIER, including `OTP-PUB-KEY` during X.509 certificate parsing via `public key:pkix decode cert/2`. Since this process occurs before signature or trust chain verification, any Erlang service parsing peer TLS certificates, such as TLS clients or mutual-TLS servers, is exposed.

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.

[Content removed]

A relative path traversal issue in the stdlib zip module allows writing files outside the intended extraction directory when processing a crafted zip archive. The functions `zip:unzip/1,2` and `zip:extract/1,2` use `zip:check dir level/2` to validate entry paths by tracking directory depth with an integer counter. Because the validation only rejects paths where the final counter value is negative, a path like `../x/y` can cause the counter to go negative during traversal and then return to zero, bypassing the check and resolving to a location outside the extraction directory via `add cwd`. This issue is located in the `lib/stdlib/src/zip.erl` file.

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.

An integer underflow exists in the External Term Format (ETF) decoder within the `BIT BINARY EXT` tag (77) handler. When the decoder accepts an encoding where both length and trailing-bits fields are set to zero, the bitstring size computation underflows an unsigned integer. This results in an extremely large value (approximately 2^64) being passed as a memory allocation size, causing the allocator to abort the entire node. This VM-level abort cannot be intercepted by supervision trees, try/catch blocks, or the `[safe]` option in `binary to term/2`. Applications decoding ETF from untrusted sources using `binary to term/1,2` or `enif binary to term()` are exposed. The Erlang distribution protocol also uses this code path, though it is intended for trusted networks.