CVE-2026-21620

Erlang OTP ssl (tls_handshake_1_3, ssl_handshake and tls_client_ticket_store modules) has an improper validation of consistency within input. A malicious TLS 1.3 server can cause a denial of service of the ssl application on the client node by sending a NewSessionTicket message with invalid extensions.

Improper certificate validation in the ssl application in Erlang/OTP allows a client holding a certificate trusted by one SNI virtual host to authenticate to a second SNI virtual host on the same listener by resuming its TLS 1.2 session there. A server serving multiple SNI names from one listen socket keeps one shared session cache and does not bind a cached session to the SNI name or client trust policy that established it. This affects OTP from 18.0 before 27.3.4.19, 28.5.0.8, and 29.1.2.

An incorrect authorization vulnerability in Erlang OTP (inets modules) allows unauthenticated access to CGI scripts protected by directory rules when served via script_alias. The path mismatch between access control evaluation and script execution allows bypassing protections.

In Erlang OTP (inets httpd module), an HTTP Request Smuggling vulnerability exists. The server does not reject or normalize duplicate Content-Length headers. The first value is used, while common proxies use the last, enabling front-end/back-end desynchronization and injection of attacker-controlled bytes as the start of the next request.

An issue was discovered in Erlang/OTP 18.x related to the generation of compiled regular expressions, which is vulnerable to a heap overflow. Regular expressions using a malformed extpattern can indirectly specify an offset used as an array index.

In Erlang/OTP, when using the inet driver with {packet,4} mode, an attacker connecting to an open TCP port can exploit a signed overflow in packet length calculation, potentially overflowing the receive buffer and crashing the BEAM VM.

The httpd HTTP server in the inets application fails to enforce a configured body-size limit on chunked requests. This may allow sending very large requests, potentially leading to server overload.

The check_header/3 function in httpd rejects duplicate Content-Length but does not check for the co-presence of Transfer-Encoding and Content-Length, which can lead to request smuggling desynchronization between front-end and back-end.

Gracefulness code ignored cases that should be rejected, resulting in possible HTTP Request Smuggling opportunities.