SFTP chroot bypass via path traversal in SSH_FXP_FSETSTAT
## Summary Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Erlang OTP ssh (ssh\_sftpd module) allows an authenticated SFTP user to modify file attributes outside the configured chroot directory. The SFTP daemon (ssh\_sftpd) stores the raw, user-supplied path in file handles instead of the chroot-resolved path. When SSH\_FXP\_FSETSTAT is issued on such a handle, file attributes (permissions, ownership, timestamps) are modified on the real filesystem path, bypassing the root directory boundary entirely. Any authenticated SFTP user on a server configured with the root option can modify file attributes of files outside the intended chroot boundary. The prerequisite is that a target file must exist on the real filesystem at the same relative path. Note that this vulnerability only allows modification of file attributes; file contents cannot be read or altered through this attack vector. If the SSH daemon runs as root, this enables direct privilege escalation: an attacker can set the setuid bit on any binary, change ownership of sensitive files, or make system configuration world-writable. This vulnerability is associated with program files lib/ssh/src/ssh\_sftpd.erl and program routines ssh\_sftpd:do\_open/4 and ssh\_sftpd:handle\_op/4. This issue affects OTP from OTP 17.0 before OTP 28.4.3, OTP 27.3.4.11 and OTP 26.2.5.20, corresponding to ssh from 3.0.1 before 5.5.3, 5.2.11.7 and 5.1.4.15. ## Workaround \* Do not use the root option in ssh\_sftpd:subsystem\_spec/1, and instead rely on OS-level chroot or container isolation to confine SFTP users. \* Ensure the Erlang VM is not running as a privileged OS user. Running the VM as an unprivileged user limits the impact of this vulnerability, since attribute modifications are constrained by that user's OS-level permissions. ## Configuration The SFTP subsystem must be configured with the root option in ssh\_sftpd:subsystem\_spec/1. The root option is not set by default.
02 / AFFECTED SOFTWARE
Affected packages
81 explicit affected versions
38 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Erlang OTP ssh (ssh_sftpd module) allows an authenticated SFTP user to modify file attributes outside the configured chroot directory. The SFTP daemon (ssh_sftpd) stores the raw, user-supplied path in file handles instead of the chroot-resolved path. When SSH_FXP_FSETSTAT is issued on such a handle, file attributes (permissions, ownership, timestamps) are modified on the real filesystem path, bypassing the root directory boundary entirely. Any authenticated SFTP user on a server configured with the root option can modify file attributes of files outside the intended chroot boundary. The prerequisite is that a target file must exist on the real filesystem at the same relative path. Note that this vulnerability only allows modification of file attributes; file contents cannot be read or altered through this attack vector. If the SSH daemon runs as root, this enables direct privilege escalation: an attacker can set the setuid bit on any binary, change ownership of sensitive files, or make system configuration world-writable. This vulnerability is associated with program files lib/ssh/src/ssh_sftpd.erl and program routines ssh_sftpd:do_open/4 and ssh_sftpd:handle_op/4. This issue affects OTP from OTP 17.0 before OTP 28.4.3, OTP 27.3.4.11 and OTP 26.2.5.20, corresponding to ssh from 3.0.1 before 5.5.3, 5.2.11.7 and 5.1.4.15.
## Summary Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Erlang OTP ssh (ssh\_sftpd module) allows an authenticated SFTP user to modify file attributes outside the configured chroot directory. The SFTP daemon (ssh\_sftpd) stores the raw, user-supplied path in file handles instead of the chroot-resolved path. When SSH\_FXP\_FSETSTAT is issued on such a handle, file attributes (permissions, ownership, timestamps) are modified on the real filesystem path, bypassing the root directory boundary entirely. Any authenticated SFTP user on a server configured with the root option can modify file attributes of files outside the intended chroot boundary. The prerequisite is that a target file must exist on the real filesystem at the same relative path. Note that this vulnerability only allows modification of file attributes; file contents cannot be read or altered through this attack vector. If the SSH daemon runs as root, this enables direct privilege escalation: an attacker can set the setuid bit on any binary, change ownership of sensitive files, or make system configuration world-writable. This vulnerability is associated with program files lib/ssh/src/ssh\_sftpd.erl and program routines ssh\_sftpd:do\_open/4 and ssh\_sftpd:handle\_op/4. This issue affects OTP from OTP 17.0 before OTP 28.4.3, OTP 27.3.4.11 and OTP 26.2.5.20, corresponding to ssh from 3.0.1 before 5.5.3, 5.2.11.7 and 5.1.4.15. ## Workaround \* Do not use the root option in ssh\_sftpd:subsystem\_spec/1, and instead rely on OS-level chroot or container isolation to confine SFTP users. \* Ensure the Erlang VM is not running as a privileged OS user. Running the VM as an unprivileged user limits the impact of this vulnerability, since attribute modifications are constrained by that user's OS-level permissions. ## Configuration The SFTP subsystem must be configured with the root option in ssh\_sftpd:subsystem\_spec/1. The root option is not set by default.
05 / REFERENCES
Further evidence
- https://cna.erlef.org/cves/CVE-2026-32147.html
- https://github.com
- https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/32xxx/CVE-2026-32147.json
- https://github.com/erlang/otp
- https://github.com/erlang/otp/commit/28c5d5a6c5f873dc701b597276271763e7d1c004
- https://github.com/erlang/otp/security/advisories/GHSA-28jg-mw9x-hpm5
- https://nvd.nist.gov/vuln/detail/CVE-2026-32147
- https://osv.dev/vulnerability/EEF-CVE-2026-32147
- https://www.erlang.org/doc/system/versions.html#order-of-versions