CVE-2026-55953

Executive Summary

CVE-2026-55953 is a severe security vulnerability in the Erlang/OTP SSL/TLS client implementation that fails to validate whether the cipher suite selected by a server during TLS 1.2 or DTLS handshakes was actually offered by the client. An on-path attacker can exploit this flaw by responding to a client's ClientHello with a ServerHello that selects an anonymous Diffie-Hellman cipher suite (e.g., TLS_DH_anon_* or TLS_ECDH_anon_*) — suites that require no server certificate and completely bypass verify_peer and cacerts validation. This results in full man-in-the-middle (MITM) compromise of all application-layer data exchanged over the affected connection. The vulnerability impacts Erlang/OTP releases from 17.0 through all versions before 27.3.4.15, 28.5.0.4, and 29.0.4, specifically affecting the SSL application versions 5.3.4 through 11.2.12.11, 11.6.0.4, and 11.7.4. The TLS 1.3 code path is not vulnerable as it correctly enforces RFC 8446 cipher suite membership verification.

Technical Analysis

The vulnerability resides in the Erlang/OTP SSL client handshake processing logic, specifically within the tls_handshake:hello/5 handler and the subsequent ssl_handshake:handle_server_hello_extensions/9 function. During a TLS 1.2 (or DTLS) handshake, the client constructs a ClientHello message containing a list of cipher suites it is willing to negotiate, presented in order of preference. Per the TLS specification (RFC 5246 section 7.4.1.2), the server MUST select a cipher suite from this offered list. However, the Erlang/OTP implementation fails to enforce this constraint server-side.

The vulnerable code path operates as follows:

1. The client initiates a connection by sending a ClientHello containing offered cipher suites and protocol version preferences.
2. An on-path attacker intercepts this ClientHello and responds with a crafted ServerHello.
3. The ServerHello selects an anonymous cipher suite (e.g., TLS_DH_anon_WITH_AES_256_CBC_SHA or TLS_ECDH_anon_WITH_AES_128_CBC_SHA) that was never included in the client's offered suite list.
4. The client's tls_handshake:hello/5 handler validates the negotiated protocol version and checks for the TLS 1.2 downgrade sentinel but does not perform a membership check on the selected cipher suite against the offered list.
5. The server-chosen suite is passed directly to ssl_handshake:handle_server_hello_extensions/9, which installs it as the active cipher state without any verification.
6. Because anonymous suites require no certificate exchange, the client skips server certificate validation entirely — verify_peer, cacerts, and hostname verification are all bypassed.
7. The client completes the handshake, sends its Finished message with the negotiated keys, and ssl:connect/2 returns {ok, Socket}.

The critical distinction is that the TLS 1.3 client path correctly performs this cipher suite membership check per RFC 8446 requirements. This asymmetry between the TLS 1.2/DTLS and TLS 1.3 code paths confirms this is an implementation oversight rather than a design flaw.

The attack requires no client-side configuration changes — even clients with strict verify_peer and cacertfile options set are vulnerable, because the anonymous suite selection means no certificate is ever presented for validation. The attacker controls the ephemeral Diffie-Hellman parameters, giving them complete knowledge of the session keys.

Exploitation Scenarios

The attack chain for CVE-2026-55953 is straightforward but requires network-level positioning. Here is a detailed technical walkthrough:

Step 1 — Target Reconnaissance and Identification

The attacker first enumerates services that employ the Erlang/OTP SSL client. These are typically:

• Erlang-based application servers (e.g., RabbitMQ, CouchDB, ejabberd) clustering over TLS
• Erlang distribution nodes using Crypto and ssl for inter-node communication
• Phoenix/Elixir web applications making outbound HTTPS calls
• MQTT brokers, AMQP clients, or other IoT device firmware built on Erlang/OTP

Reconnaissance involves banner grabbing or Erlang distribution port scanning (EPMD protocol, port 4369) to identify cluster peers. Erlang distribution uses port 4369 (EPMD) and random ports for node-to-node communication over TLS/DTLS.

Step 2 — Network Position Establishment

The attacker must be an on-path observer between the client and the intended server. This may involve:

• ARP spoofing on a local subnet
• DNS poisoning to redirect the target hostname to an attacker-controlled IP
• Routing manipulation in a compromised network segment
• Physical access to the network path (for IoT devices)

No TLS interception proxy is required because the attack operates at the TLS handshake layer itself — the attacker spoofs the server's identity before the connection is established.

Step 3 — Handshake Manipulation

Given an on-path position, the attacker intercepts the client's ClientHello. The client's offered cipher suite list typically contains strong suites such as TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC030). The attacker does not modify this ClientHello — instead, they discard it and craft a malicious ServerHello:

ServerHello:
  Version: TLS 1.2 (0x0303)
  Random: [attacker-chosen, includes correct downgrade sentinel values]
  SessionID: [mirrored from ClientHello]
  CipherSuite: TLS_DH_anon_WITH_AES_256_CBC_SHA (0x003A)
  CompressionMethod: null

The attacker must correctly include the TLS 1.2 downgrade sentinel (44 4F 57 4E 47 52 44 01) in the Random field so the client's downgrade protection check passes. Since the attacker controls the ServerHello, they can set these bytes correctly.

Step 4 — Key Exchange and Connection Establishment

The attacker sends a ServerKeyExchange message containing their own ephemeral Diffie-Hellman parameters. In the anonymous DH case:

• ServerDHParams includes the DH prime (p), generator (g), and Ys (public value)
• The attacker selects these values and retains the corresponding private exponent

The client responds with its ClientKeyExchange containing its ephemeral public DH value. At this point, both sides compute the same pre-master secret. The attacker must also correctly respond to the client's ChangeCipherSpec and Finished messages. Since they control the DH private key, they can compute the master secret and verify the client's Finished MAC.

Step 5 — Traffic Interception and Modification

Once the handshake completes, ssl:connect returns {ok, Socket}. All application data is encrypted with keys derived from the attacker-controlled DH parameter. The attacker can:

• Decrypt all client-to-server traffic (including authentication credentials, session tokens, database queries)
• Inject/modify/forget application-level messages
• Maintain the MITM position for the entire session lifetime
• Proxy the connection to the real server or terminate it

Step 6 — Post-Exploitation Impact

Realistic impact scenarios include:

• Credential harvesting from applications using SSL client authentication (e.g., Erlang distribution nodes exchanging secrets)
• Database-credential exposure from clients connecting to PoSTGRESQL or MySQL over TLS
• Session hijacking for web-based Erlang applications
• IoT device compromise — many IoT devices run Erlang-based firmware (e.g., some Zigbee gateways use Erlang); the attacker gains full remote control disguised as a legitimate TLS session

Impact Assessment

Business Impact: This vulnerability allows complete man-in-the-middle compromise of TLS-protected communications, defeating one of the primary security controls enterprises rely upon for data-in-transit protection. Any organization running Erlang/OTP-based services that communicate over TLS 1.2 or DTLS is at risk. The confidentiality and integrity impact are both high — an attacker can read, modify, and forge all application traffic.

Affected Systems: Erlang/OTP installations across cloud environments, on-premise servers, embedded systems, and IoT devices. Notable Erlang-based ecosystem components affected include RabbitMQ (a widely adopted message broker), CouchDB databases, ejabberd XMPP servers, and a substantial portion of IoT device firmware built on Erlang/OTP.

Blast Radius: The vulnerability is remotely triggerable but requires on-path network positioning. It does not require authentication. The attack surface includes all TLS 1.2/DTLS client connections made from affected Erlang installations. Because the confidentiality and integrity of all application-layer data are compromised, the severity exceeds typical memory-corruption vulnerabilities. The CVSS score is N/A in the advisory data, though based on the vulnerability class (CWE-757) and network adjacency requirement, a reasonable scoring under a vector with AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N would yield a high severity rating — however, as no official vector is provided, this is not a substitute for the NVD score.

Exploitability in the Wild: There is no known CISA KEV inclusion, no published exploit code, and no records of in-the-wild exploitation observed at the time of writing. The EPSS score of 0.00245 (15.8th percentile) reflects a low probability of exploitation attempts in the immediate term. However, the vulnerability class (cipher suite downgrade / negotiation bypass) has historical precedent for weaponization once public awareness increases.

Detection Guidance

The following detection rules focus on identifying anomalous TLS handshakes where anonymous cipher suites are negotiated, ERT/OTP-specific handshake characteristics, and potential MITM indicators.

Sigma Rule

title: ANOMALY - Anonymous Cipher Suite Negotiation in TLS 1.2 Handshake
id: 1b7f3c4d-9e8a-4b2c-ae31-7f041d2c8815
status: experimental
description: Detects TLS ServerHello messages negotiating anonymous Diffie-Hellman cipher suites that should not appear in legitimate client connections
author: Valtersit Threat Intelligence
date: 2026/02/14
modified: 2026/02/14
logsource:
  category: network_connection
  product: zeek
  definition: Requires TLS logs
detection:
  selection:
    tls.version: TLSv12
    tls.cipher:
      - 'TLS_DH_anon_*'
      - 'TLS_ECDH_anon_*'
  condition: selection
falsepositives:
  - Legitimate use of anonymous cipher suites by internal applications (extremely rare)
  - TLS examination tools running diagnostics
level: high
tags:
  - attack.t1190
  - attack.t1557.001
  - cve.2026.55953

YARA Rule

rule CVE_2026_55953_ErlangSSL_AnonSuite_Downgrade {
    meta:
        author = "Valtersit Threat Intelligence"
        description = "Detects TLS ServerHello messages with anonymous cipher suites targeting Erlang/OTP SSL clients"
        cve = "CVE-2026-55953"
        date = "2026-02-14"
        severity = "high"
    strings:
        $anon_dh = { 00 3A }  // TLS_DH_anon_WITH_AES_256_CBC_SHA
        $anon_dh128 = { 00 34 }  // TLS_DH_anon_WITH_AES_128_CBC_SHA
        $anon_ecdh = { C0 18 }   // TLS_ECDH_anon_WITH_AES_128_CBC_SHA
        $anon_ecdh256 = { C0 19 } // TLS_ECDH_anon_WITH_AES_256_CBC_SHA
        $server_hello = { 02 }
        $tls12 = { 03 03 }
    condition:
        $server_hello at 0 and $tls12 in (1..9) and any of ($anon*)
}

Suricata IDS Rule

alert tcp any any -> any any (msg:"CVE-2026-55953 - Negotiation of anonymous cipher suite in TLS 1.2 handshake"; flow:established,to_server; app-layer-protocol:["tls","ssl"]; content:"|02|"; depth:1; content:"|03 03|"; distance:1; within:2; content:"|00 3A|"; within:2; content:"|00 34|"; within:2; content:"|C0 18|"; within:2; content:"|C0 19|"; within:2; reference:cve,2026-55953; reference:url,valtersit.com; sid:2026055953; rev:1;)

Elastic Detection

any where network.protocol == "tls" and
  tls.version_protocol == "tlsv1.2" and
  (network.transport == "tcp" or network.transport == "udp") and
  tls.cipher_suite_startswith ("TLS_DH_anon_") or
  tls.cipher_suite_startswith ("TLS_ECDH_anon_")

Splunk SPL Query

index=network sourcetype=bro:ssl:json
| where proto="tls" AND tls_version="TLSv12"
| where match(cipher, "(?i)TLS_DH_anon_|TLS_ECDH_anon_")
| rex field=cipher "^(?<cipher_name>[A-Z0-9_]+)"
| where cipher_name LIKE "%ANON%"
| stats count by src_ip, dest_ip, dest_port, cipher, server_name
| where count > 0

Wazuh OSSEC Rule

<group name="tls_anomaly,">
  <rule id="100559" level="12">
    <decoded_as>json</decoded_as>
    <field name="tls.version">TLSv12</field>
    <field name="tls.cipher">TLS_DH_anon_|TLS_ECDH_anon_</field>
    <description>CVE-2026-55953: Anonymous cipher suite negotiated in TLS 1.2 handshake - possible MITM</description>
    <group>tls_anomaly,cve-2026-55953,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence Assessment (2/4 — CLAIMED): The OSV database lists a single source claiming a patch exists for the affected versions. This patch confidence score indicates that while a fix is claimed to exist, it has not been independently verified by multiple sources or through direct vendor advisories. Enterprises should treat the patch status with caution and apply layered mitigations accordingly.

Immediate Mitigations (Compensating Controls):

1. Force TLS 1.3 Client Connections: The most effective immediate mitigation. Configure all Erlang/OTP SSL clients to restrict protocol versions to ['tlsv1.3']. The TLS 1.3 client path in the Erlang/OTP implementation correctly performs cipher suite membership checks per RFC 8446 and is not affected by thisCVE. Example Erlang configuration:

ssl:connect(Host, Port, [{versions, ['tlsv1.3']},
                          {verify, verify_peer},
                          {cacerts, CA_Certs}], Timeout).

2. Network-Level Access Controls: Restrict outbound TLS connections from Erlang-based services to approved destinations using egress firewall rules. This limits the attacker's ability to respond with malicious ServerHello messages by removing the network path.

3. Network Intrusion Detection: Deploy the Suricata IDS rule above at network choke points to alert on anomalous anonymous suite negotiation.

4. Application-Level Certificate Pinning: Where feasible, implement certificate pinning in application code as an additional validation layer. This does not fix the underlying flaw but adds defense-in-depth.

Patch/Upgrade Steps:

1. Upgrade Erlang/OTP to a patched version:

   • For OTP 27.x: upgrade to version 27.3.4.15 or later
   • For OTP 28.x: upgrade to version 28.5.0.4 or later
   • For OTP 29.x: upgrade to version 29.0.4 or later
   • Corresponding ssl application versions: 11.2.12.11, 11.6.0.4, or 11.7.4 (respectively)

2. Verify the upgrade: After deployment, confirm the ssl application version using:

application:get_key(ssl, vsn).

3. Test TLS 1.2 connections post-upgrade: Verify that the patched client correctly rejects server-selected cipher suites that were not offered. A simple test is to attempt a connection to a test server configured to offer an anonymous suite and confirm the handshake fails.

Long-Term Hardening:

1. Maintain a TLS 1.3-only posture for all new Erlang/OTP deployments. Even with the patch applied, TLS 1.2 provides additional attack surface for future flaws.

2. Implement continuous vulnerability scanning for Erlang/OTP dependencies in the software supply chain. Use tools that track SBOM (Software Bill of Materials) for OTP releases.

3. Conduct periodic network penetration testing specifically focused on MITM scenarios to validate that certificate validation is enforced even when protocol downgrades are attempted.

4. Monitor OSV and Erlang/OTP mailing lists for further advisories and patch confirmations, as the current patch confidence is low (2/4).

References

1. National Vulnerability Database: https://nvd.nist.gov/vuln/detail/CVE-2026-55953
2. OSV Advisory (Patch Source): https://osv.dev/vulnerability/CVE-2026-55953
3. Valtersit Threat Intelligence Portal: https://valtersit.com/cve-2026-55953
4. Erlang/OTP Security Advisories: https://www.erlang.org/security
5. RFC 8446 (TLS 1.3 — cipher suite selection requirements): https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.3

Threat Actor Activity: No known threat actor campaigns have been publicly attributed to exploitation of CVE-2026-55953 at the time of this report. The CVE is not present in the CISA Known Exploited Vulnerabilities (KEV) catalog, and there is no published evidence of in-the-wild exploitation or functional exploit code. The EPSS score of 0.00245 (15.8th percentile) indicates a low probability of immediate exploitation attempts. Security teams should nonetheless treat this as a high-priority fix given the severity of MITM compromise and the prevalence of Erlang/OTP in enterprise infrastructure (notably RabbitMQ deployments).