Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Erlang OTP ssh (sshsftpd module) allows an authenticated SFTP user to render an SFTP channel permanently unresponsive.

The handledata/4 function in sshsftpd contains a catch-all clause that accepts channel data of any type. When channel data with a non-zero type code (SSHMSGCHANNELEXTENDEDDATA) arrives with an empty pending buffer and a payload at or below the SFTP packet size limit, the clause tail-calls itself with identical arguments, creating an infinite loop.

The SFTP protocol operates exclusively on normal channel data (type 0). Extended data (non-zero type) is meaningless for SFTP and is never sent by conforming clients. However, the SSH protocol permits any channel participant to send extended data on an open channel, so an authenticated SFTP client can trigger the loop by sending SSHMSGCHANNELEXTENDEDDATA with any datatypecode and any non-empty payload at or below the size limit.

The targeted sshsftpd process enters an infinite tail-recursive loop. It never processes another message, its message queue grows without bound, and it can only be stopped by killing the process. BEAM's reduction-based scheduler preemption continues to function, so other processes on the node are not starved, but each stuck channel process consumes its full CPU time share continuously and accumulates unbounded message queue memory. Opening many channels amplifies the CPU and memory impact.

Erlang/OTP SSH configurations using the default maxchannels setting (infinity) allow an authenticated user to open unlimited channels per connection, amplifying the attack without requiring multiple TCP connections or authentications.

No file contents, credentials, or write access are obtainable through this issue. The impact is limited to denial of service on targeted SFTP channels, with secondary CPU degradation and memory growth.

This vulnerability is associated with program file lib/ssh/src/sshsftpd.erl and program routine sshsftpd:handledata/4.

This issue affects OTP from OTP 17.0 before OTP 29.0.3, OTP 28.5.0.3 and OTP 27.3.4.14, corresponding to ssh from 3.0.1 before 6.0.2, 5.5.2.2 and 5.2.11.9.

Erlang/OTP is a set of libraries for the Erlang programming language. In versions prior to OTP-27.3.4 (for OTP-27), OTP-26.2.5.12 (for OTP-26), and OTP-25.3.2.21 (for OTP-25), Erlang/OTP SSH fails to enforce strict KEX handshake hardening measures by allowing optional messages to be exchanged. This allows a Man-in-the-Middle attacker to inject these messages in a connection during the handshake. This issue has been patched in versions OTP-27.3.4 (for OTP-27), OTP-26.2.5.12 (for OTP-26), and OTP-25.3.2.21 (for OTP-25).

Improper Handling of Highly Compressed Data (Compression Bomb) vulnerability in Erlang OTP ssh (sshtransport modules) allows Denial of Service via Resource Depletion.

The SSH transport layer advertises legacy zlib compression by default and inflates attacker-controlled payloads pre-authentication without any size limit, enabling reliable memory exhaustion DoS.

Two compression algorithms are affected:

zlib: Activates immediately after key exchange, enabling unauthenticated attacks zlib@openssh.com: Activates post-authentication, enabling authenticated attacks

Each SSH packet can decompress ~255 MB from 256 KB of wire data (1029:1 amplification ratio). Multiple packets can rapidly exhaust available memory, causing OOM kills in memory-constrained environments.

This vulnerability is associated with program files lib/ssh/src/sshtransport.erl and program routines sshtransport:decompress/2, sshtransport:handlepacketpart/4.

This issue affects OTP from OTP 17.0 before OTP 28.4.1, OTP 27.3.4.9 and OTP 26.2.5.18, corresponding to ssh from 3.0.1 before 5.5.1, 5.2.11.6 and 5.1.4.14.

Hi Fabian,

Thank you very much for this discovery and for the additional detail.

On Fri, Apr 18, 2025 at 02:01:44PM +0200, Fabian Bäumer wrote: Now, what prevented detection of this vulnerability by tools like SSHambles, is that the server does not respond to these requests. For others looking this up, it's actually SSHamble (without the "s"):

https://www.runzero.com/sshamble/ https://github.com/runZeroInc/sshamble

How did your team find this vulnerability? Manual auditing? Different tool? A formal verification project? Am I affected?

All users running an SSH server based on the Erlang/OTP SSH library are likely to be affected by this vulnerability. If your application uses Erlang/OTP SSH to provide remote access, assume you are affected. This has some additional detail on Elixir/Phoenix:

https://paraxial.io/blog/erlang-ssh

"The default configuration for Phoenix does not expose the Erlang SSH daemon to the public internet. It is technically possible you are vulnerable if your application does expose Erlang's SSH daemon, for example Elixir sftp clients do this."

Regarding Matt Keeley's exploit I posted yesterday, they now have a blog post explaining how the exploit was created mostly by AI:

https://platformsecurity.com/blog/CVE-2025-32433-poc

That's very impressive, although it might have been helped by the fix containing a regression test, which already was almost a public PoC:

https://github.com/erlang/otp/commit/6eef04130afc8b0ccb63c9a0d8650209cf54892f#diff-156a6329570e311c82b40c32d19acb37ef6d03339219ea18cd2a2a4e5649c8e5R390

as it included the main steps:

earlyrce(Config) -> [...] {send, hello}, {send, sshmsgkexinit}, {match, #sshmsgkexinit{=''}, receivemsg}, {send, SshMsgChannelOpen}, {send, SshMsgChannelRequest},

Alexander

On Wed, Apr 16, 2025 at 07:28:58PM +0200, Fabian Bäumer wrote: we (Fabian Bäumer, Marcus Brinkmann, Marcel Maehren, Jörg Schwenk (Ruhr University Bochum)) found a critical security vulnerability in the Erlang/OTP SSH implementation. The vulnerability allows an attacker with network access to an Erlang/OTP SSH server to execute arbitrary code without prior authentication. This vulnerability has been assigned CVE-2025-32433 with an estimated CVSSv3 of 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). The issue is caused by a flaw in the SSH protocol message handling which allows an attacker to send connection protocol messages prior to authentication.

Am I affected?

All users running an SSH server based on the Erlang/OTP SSH library are likely to be affected by this vulnerability. If your application uses Erlang/OTP SSH to provide remote access, assume you are affected.

Impact

The vulnerability allows an attacker to execute arbitrary code in the context of the SSH daemon. If your SSH daemon is running as root, the attacker has full access to your device. Consequently, this vulnerability may lead to full compromise of hosts, allowing for unauthorized access to and manipulation of sensitive data by third parties, or denial-of-service attacks.

Mitigation

Users are advised to update to the latest available Erlang/OTP release. Fixed versions are OTP-27.3.3, OTP-26.2.5.11, and OTP-25.3.2.20. As a temporary workaround, access to vulnerable SSH servers can be prevented by suitable firewall rules.

Advisory

An official advisory is available on GitHub: https://github.com/erlang/otp/security/advisories/GHSA-37cp-fgq5-7wc2 Matt Keeley (CC'ed) has just published an exploit at:

https://github.com/ProDefense/CVE-2025-32433

I'm also attaching the files to this message for archival. These correspond to the first and currently the only commit in the above repo, commit hash 7936ef1cae51717e191328f3f571bf8a69370ce0. I did not test this, but at least it doesn't look obviously wrong to me.

I've also already seen an animated GIF of someone else's unreleased exploit running (probably real), and a fake exploit for this bug on a pastebin (doesn't look malicious, just fake).

Alexander