CVE-2026-23942: Erlang OTP Path Traversal Vulnerability

CVE-2026-23942 Overview

A path traversal vulnerability exists in Erlang OTP's ssh_sftpd module that allows authenticated users to escape the configured SFTP root directory and access sibling directories. The flaw stems from improper path validation in the ssh_sftpd:is_within_root/2 routine, which uses string prefix matching via lists:prefix/2 rather than proper path component validation when determining if a requested path falls within the configured root directory.

Critical Impact

Authenticated SFTP users can bypass directory isolation controls to read and write files in sibling directories that share a common name prefix with the configured root directory, potentially exposing sensitive data or enabling unauthorized modifications.

Affected Products

• Erlang OTP versions 17.0 through 28.4.1
• Erlang OTP versions through 27.3.4.9
• Erlang OTP versions through 26.2.5.18
• SSH module versions 3.0.1 through 5.5.1, 5.2.11.6, and 5.1.4.14

Discovery Timeline

• 2026-03-13 - CVE-2026-23942 published to NVD
• 2026-03-16 - Last updated in NVD database

Technical Details for CVE-2026-23942

Vulnerability Analysis

This path traversal vulnerability (CWE-22) affects the SFTP server component within Erlang OTP. The root cause lies in the ssh_sftpd:is_within_root/2 function located in lib/ssh/src/ssh_sftpd.erl, which incorrectly validates whether a user-supplied path resides within the configured root directory.

The vulnerable code uses lists:prefix/2 for string-based prefix matching rather than performing proper path component boundary validation. This approach fails to account for directory names that share a common prefix. For instance, if an administrator configures the SFTP root as /home/user1, the flawed validation logic would incorrectly consider paths like /home/user10, /home/user1_backup, or /home/user1-data as being within the allowed root directory.

An authenticated attacker can leverage this vulnerability to traverse into sibling directories, potentially accessing sensitive configuration files, user data, or application secrets stored in adjacent directory structures.

Root Cause

The vulnerability originates from the use of simple string prefix matching (lists:prefix/2) in the path validation logic. This approach only checks if the requested path string begins with the root directory string, without verifying that the path actually represents a subdirectory within the root hierarchy. Proper validation requires checking path component boundaries (e.g., verifying that after the root path, the next character is either a path separator or end of string).

Attack Vector

The attack requires authenticated access to the vulnerable SFTP server. Once authenticated, an attacker can craft SFTP requests targeting directories with names that share a prefix with the configured root directory. The exploitation is straightforward:

1. Attacker authenticates to the SFTP server
2. If the configured root is /home/user1, attacker requests access to /home/user10 or /home/user1_backup
3. The flawed prefix check passes since /home/user1 is a prefix of both paths
4. Attacker gains unauthorized access to read/write files in sibling directories

// Vulnerable path validation pattern (pre-patch)
// The server uses string prefix matching that fails to validate path boundaries
// Root: /home/user1
// Attacker path: /home/user10
// lists:prefix("/home/user1", "/home/user10") returns true (INCORRECT)

Source: GitHub Security Advisory

Detection Methods for CVE-2026-23942

Indicators of Compromise

• SFTP access logs showing requests to paths that share a common prefix with the configured root but are outside the intended directory tree
• Unexpected file access patterns indicating users accessing sibling directories (e.g., /home/user1 configured but /home/user10 accessed)
• Audit logs revealing file operations in directories that should be inaccessible based on SFTP configuration

Detection Strategies

• Monitor SFTP server logs for path access patterns that indicate boundary escape attempts, particularly paths matching the pattern <root>* where the character after root is not a path separator
• Implement file integrity monitoring on directories adjacent to configured SFTP roots
• Review authentication logs correlating successful SFTP logins with suspicious file access in sibling directories
• Deploy network monitoring to detect abnormal SFTP traffic patterns indicative of directory enumeration

Monitoring Recommendations

• Enable verbose logging for the Erlang SSH daemon to capture all SFTP path requests
• Configure alerts for file access operations in directories that share naming conventions with SFTP roots
• Implement real-time log analysis to detect path traversal attempt patterns
• Monitor system file access logs (auditd on Linux) for cross-directory access by SFTP daemon processes

How to Mitigate CVE-2026-23942

Immediate Actions Required

• Upgrade to patched Erlang OTP versions: 28.4.1, 27.3.4.9, or 26.2.5.18 (corresponding to SSH versions 5.5.1, 5.2.11.6, or 5.1.4.14)
• Review SFTP server configurations to identify deployments using the root option
• Audit directory naming conventions to identify roots with potentially exploitable sibling directories
• Consider implementing OS-level isolation (chroot, containers, SELinux/AppArmor) as defense-in-depth while patching is underway

Patch Information

The Erlang/OTP team has released security patches addressing this vulnerability. The fix implements proper path component boundary validation rather than simple string prefix matching. Updated versions include OTP 28.4.1, OTP 27.3.4.9, and OTP 26.2.5.18.

Relevant commit references:

• Commit for OTP 28
• Commit for OTP 26
• Commit for OTP 27

For additional security guidance, refer to the GitHub Security Advisory.

Workarounds

• Implement OS-level chroot jails to provide filesystem isolation independent of the application-level root option
• Deploy SFTP services within containers with restricted filesystem access to limit exposure
• Use mandatory access control systems (SELinux, AppArmor) to enforce strict file access policies for the SFTP daemon process
• Review and rename directories to ensure SFTP root directory names do not share common prefixes with sensitive sibling directories
• Consider running separate SFTP daemon instances on different ports for different user groups to reduce lateral movement risk

# Defense-in-depth configuration example
# Combine application-level root with OS-level isolation

# Example: Using systemd service with chroot for Erlang SFTP
# /etc/systemd/system/erlang-sftp.service
# [Service]
# RootDirectory=/srv/sftp-jail
# PrivateTmp=true
# ProtectSystem=strict
# NoNewPrivileges=true

# Application configuration with root option
# ssh:daemon(Port, [{subsystems, [ssh_sftpd:subsystem_spec([{root, "/home/sftpuser"}])]}, ...]).