MEDIUM 4.3

CVE-2026-53422: Erlang OTP SSH SFTP Path Enumeration Vulnerability

A flaw in Erlang OTP's SFTP server module allows authenticated users to discover whether files and directories exist outside their authorized access area. When a user sends a specially crafted request to the server's path-resolution function, the server's response reveals whether a path exists on the system—even if the user shouldn't have permission to see that location. An attacker can use this to map out sensitive filesystem structures, such as identifying the presence of critical files or system directories, without actually reading any contents. This is an information-disclosure issue that requires valid SFTP credentials to exploit.

Source data · NVD / CISA · public domain

CVSS
3.1 · 4.3 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Weaknesses (CWE)
CWE-204
Affected products
2 configuration(s)
Published / Modified
2026-07-02 / 2026-07-24

NVD description (verbatim)

Observable Response Discrepancy vulnerability in Erlang OTP ssh (ssh_sftpd module) allows an authenticated SFTP user to enumerate the existence of files and directories outside the configured root directory. The SSH_FXP_REALPATH handler in ssh_sftpd calls relate_file_name/3 with Canonicalize=false, unlike every other SFTP operation handler. This allows .. components in the requested path to bypass the is_within_root/2 check without being resolved. The un-canonicalized path then enters resolve_symlinks/2, which walks up the directory tree above the configured root and issues read_link() syscalls on arbitrary filesystem paths. An authenticated SFTP client can exploit this by sending a REALPATH request with a crafted traversal path. The server response differs depending on whether the target path exists on the host filesystem (SSH_FXP_NAME when the path resolves successfully, SSH_FX_NO_SUCH_FILE when it does not). This creates a path-existence oracle that an attacker can use to enumerate the filesystem structure outside the configured root, including the existence of sensitive files, directories, and mount points. The vulnerability leaks only the existence of paths. No file contents, credentials, or write access are obtainable through this issue alone. The information gained may assist further attacks when combined with other vulnerabilities. This vulnerability is associated with program files lib/ssh/src/ssh_sftpd.erl and program routine ssh_sftpd:handle_op/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.

7 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The SSH_FXP_REALPATH handler in ssh_sftpd deviates from other SFTP operation handlers by calling relate_file_name/3 with the Canonicalize parameter set to false. This bypass prevents the is_within_root/2 check from properly resolving and validating .. path traversal components. The un-canonicalized path proceeds to resolve_symlinks/2, which traverses the filesystem above the configured SFTP root, issuing read_link() syscalls against arbitrary paths. An authenticated attacker crafts a REALPATH request containing traversal sequences that trigger different server responses: SSH_FXP_NAME when a target path exists, SSH_FX_NO_SUCH_FILE when it does not. This response discrepancy creates an oracle for enumerating filesystem paths outside the SFTP sandbox. The flaw resides in lib/ssh/src/ssh_sftpd.erl, specifically in the ssh_sftpd:handle_op/4 routine.

Business impact

This vulnerability enables authenticated SFTP users to map the host filesystem structure and identify the presence of sensitive files, directories, and mount points outside their authorized scope. While no file contents or credentials are exposed, the reconnaissance capability can inform secondary attacks, particularly in environments where SFTP access is provisioned to third parties, contractors, or untrusted tenant accounts. Organizations relying on SFTP root restrictions to segregate sensitive data may find those logical boundaries partially defeated. The impact is limited to information disclosure, but in multi-tenant or high-security environments, even path existence can constitute meaningful data leakage.

Affected systems

This vulnerability affects Erlang OTP versions prior to 29.0.3, specifically OTP 17.0 through 28.x and 27.x before their patched versions (OTP 28.5.0.3 and OTP 27.3.4.14 respectively). The corresponding Erlang SSH module versions affected are 3.0.1 through 6.0.1, 5.5.2.1, and 5.2.11.8. Any system running an affected OTP version with an active SFTP server (ssh_sftpd) exposed to authenticated users is at risk. This includes Erlang-based applications, services, or appliances that bundle OTP and expose SFTP access.

Exploitability

Exploitation requires a valid SFTP user account and network access to the SSH service. No authentication bypass or privilege escalation is needed; any authenticated SFTP session suffices. An attacker iteratively sends REALPATH requests with traversal paths targeting known or guessed locations and interprets response codes to confirm path existence. The attack is deterministic and leaves minimal forensic traces—each query appears as a normal SFTP operation. The simplicity and lack of special tools make exploitation accessible to anyone with basic SFTP knowledge and valid credentials. However, in well-monitored environments, repeated pattern-based path-testing queries may trigger anomaly detection.

Remediation

Upgrade to patched versions: OTP 29.0.3 or later, OTP 28.5.0.3, or OTP 27.3.4.14. These versions restore proper canonicalization in the REALPATH handler, ensuring .. components are resolved before the is_within_root/2 check, preventing traversal above the configured root. Organizations unable to patch immediately should restrict SFTP access to trusted accounts only, disable SFTP if not required, and monitor for suspicious REALPATH requests containing ../ sequences.

Patch guidance

The fix ensures that path canonicalization occurs before the root boundary check in the REALPATH handler, aligning it with other SFTP operation handlers. Verify the patched version against the Erlang OTP release notes and advisory documentation before deploying. Test SFTP functionality with chroot or root-restricted configurations post-patch to confirm proper confinement. A staged rollout approach is recommended for production environments running mission-critical Erlang services.

Detection guidance

Monitor SFTP logs for REALPATH requests containing .. path components, especially those with multiple directory traversal sequences. Baseline normal REALPATH usage in your environment and flag outliers. Analyze SSH debug logs at verbose levels for repeated path-resolution attempts targeting directories above the configured SFTP root. Intrusion detection systems can be tuned to flag SSH_FXP_REALPATH operations with suspicious path patterns. A more granular approach is to log all REALPATH invocations with their full request paths and response codes, enabling post-incident forensic analysis.

Why prioritize this

Although the CVSS score is moderate (4.3), this vulnerability warrants prioritization in environments where SFTP is externally facing or multi-tenant. The low barrier to exploitation (valid credentials only) combined with high information-disclosure value makes it attractive for reconnaissance. In regulated industries or systems handling sensitive intellectual property, path enumeration can facilitate subsequent attacks or compliance violations. Organizations with strong external SFTP presences or those provisioning SFTP access to third parties should prioritize patching.

Risk score, explained

CVSS 4.3 reflects the limited scope: authentication is required, no code execution or denial of service occurs, and only path existence (not contents) is disclosed. The attack vector is network-accessible, and the attack complexity is low. The confidentiality impact is rated low because the information leaked is binary path existence rather than data artifacts. Integrity and availability are unaffected. In contexts where path enumeration is highly sensitive (e.g., forensic/incident response systems, classified data repositories), the real-world risk may exceed the numeric score.

Frequently asked questions

Can an attacker read file contents or steal credentials through this vulnerability?

No. This vulnerability discloses only the existence of paths on the filesystem. File contents, permissions, ownership, and credentials remain inaccessible. However, knowledge of sensitive path existence can be weaponized in combination with other vulnerabilities or as part of a broader reconnaissance campaign.

Do I need SFTP to be internet-facing to be vulnerable?

No. Any authenticated SFTP access—whether internal, over a corporate network, or via VPN—can be exploited. The risk is highest when SFTP is exposed to untrusted or semi-trusted users (contractors, customers, third parties). Internal-only SFTP is less critical but still warrants patching as part of standard security hygiene.

How quickly should we patch?

Prioritize patching within 30 days if SFTP is internet-exposed or serves multi-tenant use cases. If SFTP is internal-only and accessed by trusted accounts, a 60–90 day timeline is acceptable, provided compensating controls (access restrictions, monitoring) are in place. Test patches in a staging environment before production deployment.

Will upgrading OTP break our Erlang applications?

Patch releases (e.g., OTP 29.0.3) are designed for backward compatibility and should not break applications following standard OTP version upgrade practices. However, test thoroughly in a pre-production environment to verify your specific application and dependencies. Consult the Erlang OTP release notes for any known breaking changes.

This analysis is provided for informational purposes and is based on publicly available vulnerability data current as of the publication date. Readers should verify patch availability and applicability against official Erlang OTP advisories and their own system configurations. SEC.co makes no warranty regarding the completeness or accuracy of this analysis and assumes no liability for decisions made based on this information. Security assessments should always be conducted by qualified personnel in consultation with official vendor guidance. Timelines and severity assessments may vary based on organizational risk tolerance and operational context. Source: NVD (public-domain), retrieved 2026-08-11. Analysis generated by SEC.co (claude-haiku-4-5).