Erlang OTP up to 3.0.0/6.0.1/16.x/29.0.2 SFTP Protocol ssh_sftpd.erl infinite loop

Summaryinfo

A vulnerability, which was classified as problematic, was found in Erlang OTP up to 3.0.0/6.0.1/16.x/29.0.2. This vulnerability affects unknown code in the library lib/ssh/src/ssh_sftpd.erl of the component SFTP Protocol. The manipulation results in infinite loop. This vulnerability is reported as CVE-2026-54886. No exploit exists. You should upgrade the affected component.

Detailsinfo

A vulnerability was found in Erlang OTP up to 3.0.0/6.0.1/16.x/29.0.2. It has been classified as problematic. Affected is some unknown functionality in the library lib/ssh/src/ssh_sftpd.erl of the component SFTP Protocol. The manipulation with an unknown input leads to a infinite loop vulnerability. CWE is classifying the issue as CWE-835. The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop. This is going to have an impact on availability. CVE summarizes:

Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Erlang OTP ssh (ssh_sftpd module) allows an authenticated SFTP user to render an SFTP channel permanently unresponsive. The handle_data/4 function in ssh_sftpd contains a catch-all clause that accepts channel data of any type. When channel data with a non-zero type code (SSH_MSG_CHANNEL_EXTENDED_DATA) 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 SSH_MSG_CHANNEL_EXTENDED_DATA with any data_type_code and any non-empty payload at or below the size limit. The targeted ssh_sftpd 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 max_channels 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/ssh_sftpd.erl and program routine ssh_sftpd:handle_data/4. This issue affects OTP from OTP 17.0 until OTP 29.0.3, 28.5.0.3, and 27.3.4.14 corresponding to ssh from 3.0.1 until 6.0.2, 5.5.2.2, and 5.2.11.9.

The weakness was disclosed by Lukas Backström. The advisory is shared for download at github.com. This vulnerability is traded as CVE-2026-54886 since 06/16/2026. The exploitability is told to be easy. There are known technical details, but no exploit is available.

Upgrading to version 3.0.1, 5.2.11.9, 5.5.2.2, 6.0.2, 17.0, 27.3.4.14, 28.5.0.3 or 29.0.3 eliminates this vulnerability. Applying the patch eaf9550b8ad4738b81149d3f617102d980c6dd18 is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Vendor

• Erlang

Name

• OTP

Version

• 3.0
• 6.0.0
• 6.0.1
• 16.x
• 29.0.0
• 29.0.1
• 29.0.2

Website

• Product: https://github.com/erlang/otp/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion