CVE-2026-58227: 
CBL Mariner Análise e mitigação de vulnerabilidades

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 (certificate 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 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 application versions 10.2 before 11.7.4, 11.6.0.4, and 11.2.12.11). It was disclosed on July 27, 2026, with 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 an attacker supplies two mutually cross-signed certificates (A issues B, B issues A) in unordered form, the issuer lookup alternates between the two certificates indefinitely, growing both the call stack and chain accumulator without bound until the BEAM process exhausts available memory. The fix replaces the recursive approach with an acyclic directed graph (digraph:new([acyclic])) for unordered/extraneous chain handling, and adds a MAX_CHAIN depth limit of 12 and a DER-based duplicate certificate check in do_certificate_chain (GitHub Commit, GitHub Advisory).

Successful exploitation results in complete denial of service for 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 application for TLS or DTLS communication is at risk. There is no confidentiality or integrity impact; the sole consequence is availability loss, which can be severe for high-availability systems built on Erlang/OTP such as telecommunications infrastructure, messaging platforms, and distributed databases (GitHub Advisory, Feedly).

The vulnerability is highly automatable: only a TCP connection and a partial TLS/DTLS handshake are required — no authentication or completed handshake is needed. No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation as of the disclosure date. The EPSS score is approximately 0.0035 (low probability of exploitation in the near term), and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The vulnerability was responsibly disclosed by Lukas Backström at Erlang Solutions (GitHub Advisory, Feedly).

1. Reconnaissance: Identify internet-facing services running Erlang/OTP versions 23.2 through 29.0.3 (or equivalent ssl application versions 10.2 through 11.7.3) using tools like Shodan or Censys, targeting TLS/DTLS endpoints (e.g., port 443, 8883, 5671, or custom DTLS ports).
2. Generate malicious certificate pair: Create two self-signed or CA certificates where certificate A lists B as its issuer and certificate B lists A as its issuer — forming a mutual cross-signing cycle. This can be done with OpenSSL or custom tooling to craft the issuer/subject fields appropriately.
3. Initiate TLS/DTLS handshake: Establish a TCP (or UDP for DTLS) connection to the target and begin a TLS/DTLS handshake.
4. Send crafted Certificate message: During the handshake, transmit a TLS Certificate message containing the two mutually cross-signed certificates in unordered form. No completed handshake or authentication is required — the Certificate message alone triggers the vulnerable code path.
5. Trigger unbounded recursion: The target's ssl_certificate:handle_incomplete_chain/5 processes the unordered chain, entering infinite recursion between the two certificates, exhausting memory and crashing the BEAM node (GitHub Advisory, Feedly).

• Network: Repeated incomplete TLS/DTLS handshakes from a single source IP that terminate abruptly without completing; unusual volume of Certificate handshake messages containing only two certificates with circular issuer relationships.
• Logs: Erlang/OTP crash dump files (erl_crash.dump) generated in the working directory of the BEAM process; OTP error logger entries indicating process termination due to memory exhaustion or stack overflow during SSL handshake processing.
• Process: Sudden termination of the BEAM VM process (beam.smp or beam) with out-of-memory errors; abnormal memory growth in the Erlang node observable via observer or OS-level monitoring tools immediately preceding a crash.
• File System: Presence of erl_crash.dump files with stack traces referencing ssl_certificate:build_certificate_chain, ssl_certificate:do_certificate_chain, or ssl_certificate:handle_incomplete_chain functions (GitHub Advisory).

Upgrade to one of the patched OTP releases: OTP 29.0.4, OTP 28.5.0.4, or OTP 27.3.4.15 (corresponding to ssl application versions 11.7.4, 11.6.0.4, or 11.2.12.11 respectively). The fix introduces an acyclic digraph-based approach for unordered certificate chain handling, a MAX_CHAIN depth limit of 12, and a DER-based duplicate certificate guard in do_certificate_chain. No official workaround short of patching is provided by the vendor. As interim mitigations, consider implementing network-level rate limiting on TLS/DTLS handshake attempts, restricting accepted certificate chain structures at the network perimeter, and deploying automated BEAM node restart procedures to minimize downtime in the event of exploitation (GitHub Advisory, GitHub Commit).

The vulnerability was responsibly disclosed by Lukas Backström at Erlang Solutions and acknowledged by the Erlang/OTP project team, with remediation developed by IngelaAndin and reviewed by dgud and u3s. Security aggregators including SecurityOnline.info covered the disclosure alongside other Erlang/OTP vulnerabilities. The vulnerability has been picked up by standard vulnerability tracking platforms (VulnDB, OSV, CIRCL) shortly after disclosure, indicating normal community awareness without significant amplification or controversy (GitHub Advisory, SecurityOnline).