CVE-2026-53422 in Erlang/OTP SSH
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 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.
Quick answer
Erlang/OTP SSH should be reviewed and updated if it matches the affected versions. The recommended fix is to apply the vendor-supported patched version or the mitigation steps below, then retest the public website with Fixnx.
Who is affected
Affected versions
- Erlang/OTP 17.0 up to fixed OTP branches
- OTP 27 before 27.3.4.14
- OTP 28 before 28.5.0.3
- OTP 29 before 29.0.3
- ssh 3.0.1 before fixed ssh branches
Fixed versions
- Erlang/OTP 27.3.4.14 or later
- Erlang/OTP 28.5.0.3 or later
- Erlang/OTP 29.0.3 or later
- ssh 5.2.11.9, 5.5.2.2, or 6.0.2 or later as applicable
How to fix it
CVE-2026-53422 affects Erlang/OTP SSH. The issue means path existence outside the SFTP root may be revealed. Treat this as a priority if the system is reachable by users, tenants, or the network. Update to Erlang/OTP 27.3.4.14, 28.5.0.3, or 29.0.3 or later, or follow the vendor advisory if your branch needs a backport.
- Inventory every Erlang/OTP SSH instance, appliance, container, or package in use.
- Compare installed versions with the affected ranges in the vendor advisory.
- Update to Erlang/OTP 27.3.4.14, 28.5.0.3, or 29.0.3 or later on supported systems.
- If you cannot update today, restrict access to trusted admins and trusted networks only.
- Review logs for unusual access, privilege changes, file access, or failed requests.
- Rotate secrets, tokens, and service accounts if exposure or abuse is suspected.
- Document the change and keep the advisory link with the ticket.
Scan now. Google sign-in is only needed to unlock fix guidance.
Verify the fix
- Confirm the installed version is Erlang/OTP 27.3.4.14, 28.5.0.3, or 29.0.3 or later.
- Confirm exposed admin, API, SFTP, or device access is limited to trusted users.
- Retest the affected workflow after the update or mitigation.
- Review logs again after patching for repeated suspicious activity.
- Run a new Fixnx scan where the affected service is part of the public site.
Related categories
Trusted references
FAQ
What is affected by CVE-2026-53422?
Erlang/OTP SSH versions listed as affected should be reviewed: Erlang/OTP 17.0 up to fixed OTP branches, OTP 27 before 27.3.4.14, OTP 28 before 28.5.0.3, OTP 29 before 29.0.3, ssh 3.0.1 before fixed ssh branches.
What should I fix first?
Start with internet-facing sites, admin panels, login flows, plugins, themes, modules, packages, and systems that process user-controlled input or sensitive data.
How do I confirm the fix worked?
Apply the patched version or mitigation, clear caches where relevant, retest the affected workflow, and run a new Fixnx scan to verify public website exposure signals.
How are Fixnx security risk categories chosen?
Fixnx keeps one canonical risk page and assigns only broad, relevant categories such as ecosystem, technology area, or vulnerability class.
