CVE-2026-68956: 
CBL Mariner vulnerability analysis and mitigation

CVE-2026-68956 is an SSH session channel exhaustion vulnerability in Erlang/OTP's SSH daemon, classified as "Allocation of Resources Without Limits or Throttling" (CWE-770). An authenticated remote attacker can crash the Erlang VM by repeatedly opening session channels that are never assigned a handler, exhausting node memory. The vulnerability affects OTP from version 18.1.2 (ssh 4.1.1) up to — but not including — OTP 27.3.4.18, OTP 28.5.0.7, and OTP 29.1.1 (corresponding to ssh 5.2.11.13, 5.5.2.6, and 6.0.6 respectively). It was published on September 22, 2026, with a CVSS v4.0 base score of 7.1 (High) (GitHub Advisory, Feedly).

The root cause lies in the "session" clause of ssh_connection:handle_msg/4, which checks only minimal_remote_max_packet_size before calling setup_session/5. This function unconditionally builds a #channel{} record and stores it in the ETS channel cache without enforcing any channel count limit. The max_channels daemon option was previously enforced only by ssh_channel_sup:max_num_channels_not_exceeded/2, which counts supervisor children — meaning idle session channels that never receive a shell, exec, or subsystem handler are invisible to this check. Per RFC 4254 §5.1, many session channels are permitted per connection, and since each #channel{} record costs only a few hundred bytes, a single authenticated connection can accumulate enough records to exhaust the Erlang VM's memory and terminate the emulator. The fix (commits 79c2d2b, e181009, e2bbad0) introduces a new cache_insert/3 function that enforces max_channels at the ETS cache level before any channel record is stored (GitHub Advisory, Patch Commit).

Successful exploitation causes a complete denial of service: the Erlang VM (BEAM emulator) terminates due to memory exhaustion, bringing down every application running on the affected node — not just the SSH daemon. There is no confidentiality or integrity impact; no file contents, credentials, or write access are obtainable. The blast radius is limited to the affected Erlang node, but in environments where multiple services share a single OTP node (common in Elixir/Erlang deployments), the outage can be broad (GitHub Advisory, Feedly).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation as of the time of publication (Feedly). Exploitation requires valid SSH credentials but no special privileges beyond authentication; a single connection is sufficient to carry out the attack. The EPSS score is approximately 0.475%, indicating a low current probability of exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The attack is not automatable without credentials, which somewhat limits opportunistic exploitation (GitHub Advisory).

1. Obtain valid SSH credentials: Acquire any valid username and password (or key) for the target Erlang/OTP SSH daemon — standard user-level access is sufficient.
2. Identify a vulnerable target: Confirm the target is running an affected OTP version (18.1.2 through 27.3.4.17, 28.x before 28.5.0.7, or 29.x before 29.1.1) using banner grabbing or version enumeration.
3. Establish an SSH connection: Connect to the target SSH daemon using any standard SSH client or library (e.g., Python's paramiko, Erlang's own ssh module).
4. Open session channels in a loop without activating them: Using the SSH protocol directly (e.g., via a low-level SSH library), send repeated SSH_MSG_CHANNEL_OPEN messages with channel_type = "session" but never follow up with a shell, exec, or subsystem request. Each channel is accepted and stored as a #channel{} record in the ETS cache.
5. Exhaust node memory: Continue opening channels until the Erlang VM's memory is exhausted. Since each record is only a few hundred bytes, tens of thousands of channels may be needed, but this is achievable within a single connection session.
6. Erlang emulator terminates: Once memory is exhausted, the BEAM emulator crashes, taking down all applications on the node (GitHub Advisory, Feedly).

• Network: Unusually high number of SSH_MSG_CHANNEL_OPEN messages from a single source IP on the SSH port (default 22) without corresponding shell/exec/subsystem requests; sustained SSH connection with no interactive activity.
• Logs: Erlang/OTP SSH daemon logs showing a large number of channel open events from a single connection with no subsequent channel activation; BEAM crash dump files (e.g., erl_crash.dump) generated in the OTP working directory.
• Process/System: Sudden spike in memory consumption by the Erlang VM process (beam.smp) followed by process termination; OS-level OOM killer events targeting the BEAM process.
• File System: Presence of an erl_crash.dump file in the application working directory, timestamped at the time of the incident, containing memory exhaustion indicators (GitHub Advisory).

Upgrade to a patched OTP release: OTP 27.3.4.18 (ssh 5.2.11.13), OTP 28.5.0.7 (ssh 5.5.2.6), or OTP 29.1.1 (ssh 6.0.6). Patched versions enforce max_channels at the ETS cache insertion point and change defaults to max_channels = 256 and max_sessions = 1024; deployments requiring unlimited behavior can set {max_channels, infinity} and {max_sessions, infinity} explicitly after upgrading. If immediate patching is not possible, the following partial mitigations reduce exposure without fully preventing the attack: set max_sessions to a finite value to limit simultaneous connections; apply OS-level connection rate limiting (e.g., iptables connlimit); constrain Erlang VM memory via cgroups or ulimit; and restrict SSH daemon access to trusted networks only. Note that idle_time, max_initial_idle_time, max_heap_size, and the +hmax flag do not mitigate this vulnerability (GitHub Advisory).

The advisory was published by the Erlang Ecosystem Foundation (EEF) as the CNA, with the fix credited to researcher Mikaka27 and reviewed by u3s. The vulnerability received coverage in Linux security roundup publications and German Linux security news (pro-linux.de), and was picked up by Fedora and Debian package advisories shortly after disclosure. A Mastodon post by security researcher @hugovalters noted the issue. Overall community reaction has been measured, reflecting the limited scope (DoS only, requires authentication) and the availability of a patch (GitHub Advisory, Feedly).