CVE-2026-58227: 
CBL Mariner 취약성 분석 및 완화

CVE-2026-58227 is a TLS/DTLS Denial-of-Service vulnerability in the Erlang/OTP ssl application caused by uncontrolled recursion during certificate chain reconstruction. When a peer supplies two mutually cross-signed certificates in unordered form (A issues B, B issues A), the chain-building logic in ssl_certificate:handle_incomplete_chain/5 enters unbounded recursion with no cycle detection or depth limit, exhausting available memory and crashing the BEAM node. The vulnerability affects OTP versions from 23.2 before 29.0.4, 28.5.0.4, and 27.3.4.15 (corresponding to ssl library versions 10.2 before 11.7.4, 11.6.0.4, and 11.2.12.11). It was disclosed on July 27, 2026, and carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory, Feedly).

The root cause is CWE-674 (Uncontrolled Recursion) in ssl_certificate.erl. Specifically, ssl_certificate:handle_incomplete_chain/5 passes the received certificate chain to ssl_certificate:build_certificate_chain/5, which walks issuer relationships via ssl_certificate:do_certificate_chain/7 without any cycle detection or maximum depth enforcement. When two mutually cross-signed certificates are present (cert A signed by B, cert B signed by A), the issuer lookup alternates indefinitely between the two, growing both the call stack and chain accumulator without bound until the BEAM process runs out of memory. The fix replaces the recursive chain-building approach for unordered/extraneous certificates with an acyclic directed graph (digraph:new([acyclic])) and adds a MAX_CHAIN depth limit of 12, along with a DER-based duplicate certificate check in do_certificate_chain (GitHub Commit, GitHub Advisory).

Successful exploitation results in complete availability loss of the targeted BEAM node — the process exhausts available memory and crashes. Both TLS/DTLS servers and clients are affected when processing peer Certificate messages, meaning any Erlang/OTP application using the ssl library for TLS or DTLS communication is at risk. There is no confidentiality or integrity impact; the attack is purely a Denial-of-Service. Because only a TCP connection and a partial handshake are required — no authentication or completed handshake is needed — the attack surface is broad and the barrier to exploitation is very low (GitHub Advisory, Feedly).

No public proof-of-concept exploit code has been observed, and there is no evidence of in-the-wild exploitation at the time of disclosure (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.35%, reflecting a currently low probability of exploitation in the near term. However, the attack is highly automatable (NVD SSVC: automatable=yes) — requiring only a TCP connection and a crafted TLS Certificate message — making it straightforward to weaponize against any exposed Erlang/OTP TLS endpoint (Feedly).

1. Reconnaissance: Identify internet-facing services built on Erlang/OTP that expose TLS or DTLS endpoints (e.g., RabbitMQ, Ejabberd, CouchDB, or custom Erlang applications). Use tools like Shodan or Censys to find services advertising Erlang-based TLS stacks, or target known OTP versions 23.2 through 29.0.3.
2. Generate malicious certificate pair: Create two self-referential, mutually cross-signed certificates using OpenSSL or a custom script — Certificate A signed by Certificate B's key, and Certificate B signed by Certificate A's key — forming a cycle.
3. Initiate TLS/DTLS handshake: Establish a TCP connection to the target's TLS or DTLS port and begin a handshake. No prior authentication or credential is required.
4. Send crafted Certificate message: During the handshake, transmit a TLS Certificate message containing the two mutually cross-signed certificates in unordered form (e.g., [A, B] where A issues B and B issues A).
5. Trigger unbounded recursion: The target's ssl_certificate:handle_incomplete_chain/5 receives the chain and calls build_certificate_chain/5, which recurses indefinitely between the two certificates via do_certificate_chain/7 with no cycle detection.
6. BEAM node crash: The call stack and chain accumulator grow without bound, exhausting available memory and crashing the BEAM node, resulting in a complete Denial-of-Service of the target application (GitHub Advisory, Feedly).

• Network: Unexpected or repeated TLS/DTLS connection attempts that do not complete a full handshake; connections that terminate abruptly after the Certificate message exchange phase.
• Logs: Erlang crash dump files (erl_crash.dump) generated in the application working directory, indicating BEAM node memory exhaustion; OTP error logger entries showing process termination due to system_limit or out-of-memory errors during TLS handshake processing.
• Process: Sudden termination of the BEAM VM process (beam.smp or erl) without a graceful shutdown signal; abnormal memory growth in the Erlang VM process immediately preceding a crash, observable via OS-level monitoring tools (e.g., top, ps, or application performance monitors).
• Application: Service unavailability of Erlang-based applications (e.g., RabbitMQ, Ejabberd) coinciding with inbound TLS connection activity from unexpected or untrusted sources.

Upgrade Erlang/OTP to one of the patched versions: OTP 29.0.4, OTP 28.5.0.4, or OTP 27.3.4.15 (corresponding to ssl library versions 11.7.4, 11.6.0.4, and 11.2.12.11 respectively). No official workaround is provided by the vendor for systems that cannot be immediately patched. As a compensating control, implement network-level access controls (firewalls, TLS termination proxies) to restrict untrusted or unauthenticated TLS/DTLS connections to affected Erlang/OTP services, reducing the attack surface until patching is feasible (GitHub Advisory, Feedly).

The vulnerability was responsibly disclosed by Lukas Backström at Erlang Solutions, who is credited in the official GitHub Security Advisory (GitHub Advisory). Security news outlets including SecurityOnline.info covered the disclosure alongside other Erlang/OTP vulnerabilities. Tenable published Nessus detection plugins (IDs 330376 and 331347) shortly after disclosure, indicating prompt uptake by the vulnerability management community (Feedly).