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 tls_handshake:hello/5 handler validates the negotiated protocol version and the downgrade sentinel but hands the server-chosen suite directly to ssl_handshake:handle_server_hello_extensions/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 TLS_DH_anon_* or TLS_ECDH_anon_* that the client never offered. Anonymous suites do not require the server to present a certificate, so the entire verify_peer 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.
This vulnerability carries a HIGH severity rating with a CVSS v3.1 score of 7.4, indicating it can be exploited remotely over the network but requires specific conditions to be met without requiring user interaction and does not require pre-existing privileges . The vulnerability impacts confidentiality (data exposure), integrity (unauthorized modifications), for affected systems. Impacting 2 products from erlang, from erlang organizations running these solutions should prioritize assessment and patching.
Reported in 2026, this vulnerability emerged during an era marked by increased sophistication in supply chain attacks, cloud infrastructure vulnerabilities, and software-as-a-service (SaaS) security challenges. Security practices during this period emphasized zero-trust architectures, container security, and API protection.
2026-07-27T16:17:49.500
2026-09-08T01:17:50.707
Modified
6b3ad84c-e1a6-4bf7-a703-f496b71e49db
CVSSv3.1: 7.4 (HIGH)
| Type | Vendor | Product | Version/Range | Vulnerable? |
|---|---|---|---|---|
| Application | erlang | erlang\/otp | < 27.3.4.15 | Yes |
| Application | erlang | erlang\/otp | < 28.5.0.4 | Yes |
| Application | erlang | erlang\/otp | < 29.0.4 | Yes |
| Application | erlang | erlang\/ssl | < 11.2.12.11 | Yes |
| Application | erlang | erlang\/ssl | < 11.6.0.4 | Yes |
| Application | erlang | erlang\/ssl | < 11.7.4 | Yes |
SecUtils normalizes and enriches National Vulnerability Database (NVD) records by standardizing vendor and product identifiers, aggregating vulnerability metadata from both NVD and MITRE sources, and providing structured context for security teams. For erlang's affected products, we extract Common Platform Enumeration (CPE) data, Common Weakness Enumeration (CWE) classifications, CVSS severity metrics, and reference data to enable rapid vulnerability prioritization and asset correlation. This record contains no exploit code, proof-of-concept instructions, or attack methodologies—only defensive intelligence necessary for patch management, risk assessment, and security operations.