CVE-2026-58227 Overview
CVE-2026-58227 is a denial-of-service vulnerability in the Erlang/OTP ssl application. The ssl_certificate:handle_incomplete_chain/5 function reconstructs incomplete peer certificate chains during TLS or DTLS handshakes without cycle detection or a depth limit. An unauthenticated remote attacker can send two mutually cross-signed certificates in unordered form (A issues B, B issues A) to trigger unbounded recursion. The recursion exhausts memory and crashes the BEAM node. Both TLS/DTLS servers and clients are affected because both process peer Certificate handshake messages. The issue is tracked as CWE-674: Uncontrolled Recursion.
Critical Impact
An unauthenticated network attacker can crash any Erlang node performing TLS or DTLS peer certificate processing with only a TCP connection and a partial handshake.
Affected Products
- Erlang/OTP from OTP 23.2 before OTP 29.0.4
- Erlang/OTP 28.5.0.4 branch
- Erlang/OTP 27.3.4.15 branch (ssl versions 10.2 before 11.7.4, 11.6.0.4, and 11.2.12.11)
Discovery Timeline
- 2026-07-27 - CVE-2026-58227 published to NVD
- 2026-07-30 - Last updated in NVD database
Technical Details for CVE-2026-58227
Vulnerability Analysis
The defect lives in the Erlang/OTP TLS/DTLS certificate chain reconstruction path. When a peer supplies an incomplete chain, ssl_certificate:handle_incomplete_chain/5 calls ssl_certificate:build_certificate_chain/5, which in turn invokes ssl_certificate:do_certificate_chain/7 to walk issuer relationships. Neither function tracks previously visited certificates and neither enforces a maximum chain depth. The vulnerability is classified under CWE-674 Uncontrolled Recursion. See the Erlang security advisory GHSA-r5jr-mq46-vmhw for authoritative technical details.
Root Cause
The issuer-lookup loop trusts that the reconstructed chain is finite. When two peer certificates cross-sign each other, the lookup alternates between them indefinitely. The call stack and chain accumulator grow without bound, driving the BEAM virtual machine into memory exhaustion.
Attack Vector
Exploitation requires only a TCP connection and a partial TLS or DTLS handshake. The attacker sends a crafted Certificate handshake message containing two mutually cross-signed certificates in unordered form. No authentication, valid certificate, or completed handshake is needed. Both server-side and client-side Erlang applications that process peer certificates are affected.
The vulnerability manifests during chain reconstruction and does not depend on any application-layer logic above the ssl module. See the CNA advisory for CVE-2026-58227 and the fix commits (1, 2, 3) for the corrected traversal logic.
Detection Methods for CVE-2026-58227
Indicators of Compromise
- Sudden BEAM VM crashes with out-of-memory errors on hosts terminating TLS or DTLS.
- Erlang crash dumps referencing ssl_certificate:do_certificate_chain/7 or deep recursion in build_certificate_chain/5.
- Rapid memory growth of the beam.smp process correlated with inbound TLS/DTLS Certificate messages.
- Repeated inbound handshakes from a single source terminating before completion.
Detection Strategies
- Inspect Erlang crash dumps and erl_crash.dump files for stack frames inside the ssl_certificate module.
- Monitor TLS/DTLS handshake failure rates and correlate spikes with process restarts of Erlang services.
- Deploy TLS-inspecting network sensors to flag Certificate messages containing certificates whose Subject and Issuer form a mutual pair.
- Use SIEM analytics to correlate BEAM restarts across clustered Erlang nodes reachable by the same client IP.
Monitoring Recommendations
- Alert on repeated SIGKILL or OOM-killer events targeting Erlang runtime processes.
- Track handshake termination metrics from load balancers and reverse proxies fronting Erlang services.
- Instrument Erlang telemetry (telemetry, observer_cli) to expose memory and reduction growth per TLS session.
How to Mitigate CVE-2026-58227
Immediate Actions Required
- Upgrade to Erlang/OTP 29.0.4, 28.5.0.4, or 27.3.4.15, or later on each affected branch.
- Inventory every service using the ssl application, including RabbitMQ, ejabberd, CouchDB, and custom Cowboy or Ranch listeners.
- Restart Erlang nodes after upgrading so the patched ssl beam files load.
- Restrict network exposure of TLS/DTLS endpoints to trusted peers until patching is complete.
Patch Information
Erlang/OTP maintainers shipped fixes in the commits 0307bff2, 241d4370, and 7db64720. The patches add cycle detection and a depth limit to ssl_certificate:do_certificate_chain/7. Refer to the GitHub Security Advisory GHSA-r5jr-mq46-vmhw and the OSV record EEF-CVE-2026-58227 for release mappings. Version ordering follows the Erlang Version Order documentation.
Workarounds
- Terminate TLS/DTLS at a non-Erlang proxy such as nginx or HAProxy that performs its own certificate validation and does not forward client certificates to the Erlang service.
- Disable client certificate authentication (verify_none) where policy allows, reducing exposure of the incomplete-chain code path.
- Apply strict network ACLs so only trusted networks can initiate TLS/DTLS handshakes with affected Erlang nodes.
- Enforce per-source connection rate limits at the edge to slow attempted DoS attempts pending patch rollout.
# Verify installed Erlang/OTP version and ssl application version
erl -eval 'io:format("OTP ~s / ssl ~s~n", [erlang:system_info(otp_release), element(3, lists:keyfind(ssl,1,application:loaded_applications()))]), init:stop().' -noshell
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
