Re: [sshfs] [SECURITY] SSHFS 3.7.6 release fixing 2 vulnerabilities

[Abhinav A. <abh...@gm...>]

Hi Nikolaus,

Thanks for reviewing the advisories. In both cases the issue is a trust
boundary, and I'll try to be precise about what is and isn't sshfs's fault.

CVE-2026-47187 (symlink targets)

For a local symlink you're right: whoever planted it already had local
write access, so "don't follow untrusted symlinks" is just Unix. The
difference here is who controls the target - the remote SFTP server, which
in this threat model is untrusted (the case being mounting servers you
don't administer: shared boxes, sftp dropboxes, a compromised host).

When you mount a server at /mnt, the reasonable expectation is that client
operations aren't redirected to arbitrary client-local paths by
server-controlled metadata. A server-supplied symlink with an absolute
target ($HOME/.ssh/config) or a relative escape
(../../../tmp/client-secret) breaks that: it is reflected into the local
VFS, and ordinary client operations - cp, an editor, a backup job - resolve
it against the *client* filesystem. The server picks the path, so it gains
a local read (the user's own tool reads whatever the target resolves to on
the client - say $HOME/.ssh/config, within the client user's own
permissions - and writes that data back over the mount, i.e. to the server
via SFTP; sshfs itself never opens the file) or a local write (server bytes
land on a server-chosen local path) - through the user's own commands, with
no prior local foothold beyond inducing the user to mount and interact with
the server, and no client-side code execution.

The honest counterpoint is that NFS and CIFS reflect server symlinks the
same way and were never CVE'd for it. What I'd point to is that sshfs
already had an option that partially addressed this class for absolute
symlinks - transform_symlinks rewrote absolute targets - but it never
covered relative "../" escapes. Once a partial mitigation is defeated by a
path it didn't anticipate, the residual is reasonable to treat as an
sshfs-side hardening gap, not just generic Unix symlink advice. rsync draws
the same line: --safe-links exists precisely to drop absolute or
tree-escaping targets, and a CVE was assigned for a gap in that guard
(CVE-2024-12088). contain_symlinks closes the gap by default;
no_contain_symlinks restores the old behavior for trusted servers.


CVE-2026-48711 (argument injection)

You're right that this is a non-issue when a user runs sshfs directly and
controls the command line. The case I'd point to is composition: any
service that maps an untrusted source string onto an sshfs invocation,
meaning to grant only "host:path". I don't have a published exploit against
a specific product to point to - the argument is that the parse owes the
same end-of-options guarantee git's connect path does.

sshfs defines and parses that "host:path" format, so I'd argue sshfs owns
that argv boundary: a value accepted in the host slot shouldn't be able to
become an ssh option. With [-oProxyCommand=CMD]:/path, find_base_path()
strips the brackets into a "-"-leading hostname that older sshfs passed to
ssh with no end-of-options guard - so the host value became an ssh option.
That is the parse failing to contain the host field, not solely the
caller's fault for passing a documented format. It's the same class git
fixed in 2017 (CVE-2017-1000117; Mercurial and Subversion shipped analogous
reject-"-" hardening), and more recently Cockpit (CVE-2026-4631) - in each
case the fix went into the component that builds the ssh argv and owns the
host-field parse boundary, not into ssh itself. Callers still need to
validate their inputs - but sshfs owns the argv it builds, the same way git
owns the one it hands to ssh.


A couple of corrections on our side:

- The advisories should say the server "induces" local I/O, not that it
writes local files directly - that wording overreached.
- On a second look the Critical/9.3 on the symlink issue is too high. The
attacker is still the remote server and the harm needs the user to run
local tooling (UI:R).

Happy to fold the threat models into both advisories so they don't lean on
the changelog.

Best
Abhinav


On Sun, May 31, 2026 at 5:08 AM Nikolaus Rath <nik...@ra...> wrote:

> Hi Haoxi,
>
> On Sun, 31 May 2026, at 12:03, H Tan wrote:
>
> Hi Nikolaus,
>
> So with the first vuln, my understanding is that when you mount sshfs to a
> sub dir, you trust the server to ONLY be able to read/write data inside
> that sub directory.
>
>
> I assume with "the server" you mean the local SSHFS process?
>
> In that case I agree, and SSHFS already guarantees that (since it's only
> ever sending data to the SSH server, which by definition can only write
> inside the mounted directory).
>
> The vuln is a malicious server (e.g. a unix shared box where an attacker
> has root) can read and write outside that directory.
>
>
> But then talking about a "malicious server" doesn't make sense. So I guess
> with "server" you mean the remote ssh server? In that case you do not need
> to "trust" it, it can only write to remote filesystems by construction
> (since the sshfs "client" is not executing any instructions, it just sends
> instructions to the server).
>
> That's exactly the kind of threat model sshfs needs to defend against from
> a client side perspective if mounting a shared server, especially now that
> Linux LPE bugs drop so frequently.
>
>
> I do not understand this sentence (nor the threat model).
>
> The second one is the ability to inject commands where the hostname is
> expected. You're right that it's a non-issue if the user is running sshfs
> on the command line. It'll only be an issue if sshfs is a component in a
> server-side integration, such as a router CGI interface allowing users to
> remote mount with controlled arguments like hostname, user pass and proxy.
> It's only an issue if sshfs is used in a context that doesn't assume the
> user can execute arbitrary ssh commands, but not a real issue for normal
> usage.
>
>
> In that case, I'd say that any "vulnerability" is in the CGI interface,
> not in SSHFS.
>
> Best,
> -Nikolaus
>
>
>
>
>
> Hope that helps.
>
>
> On Sun, 31 May 2026 at 8:19 pm, Nikolaus Rath <nik...@ra...> wrote:
>
>
> Hi,
>
> Could you provide a bit more detail about these vulnerabilities? Having
> read the Github announcement, neither of these sound like vulnerabilities
> to me:
>
> - https://github.com/libfuse/sshfs/security/advisories/GHSA-pjv6-2c3f-r357 seems
> to boil down to "don't write data into untrusted symlinks" - which is a
> general property of Unix filesystem semantics, not a bug in SSHFS.  If I
> create a symlink from ~/data/logs.txt to /etc/passwd, and can get another
> user (say root) to write into this file, then I have "tricked" root into
> writing to /etc/passwd. Why does this become a security vulnerability if
> ~/data happens to be an SSHFS mountpoint rather than a local directory tree?
>
>
> - https://github.com/libfuse/sshfs/security/advisories/GHSA-mm85-q63v-4476 seems
> to boil down to "if you can call SSHFS with arbitrary arguments, you can
> call SSH with arbitrary arguments". Not sure why this is a security
> vulnerability either, since both processes run on the same machine as the
> same user.
>
> Am I missing something?
>
> Best,
> -Nikolaus
>
> On Sat, 30 May 2026, at 00:49, H Tan wrote:
>
>
> Hi all,
>
> We have found 2 vulnerabilities in SSHFS (1 Critical, 1 High) and have
> patched them in the latest release 3.7.6.
> https://github.com/libfuse/sshfs/releases/tag/sshfs-3.7.6
>
> For distro maintainers please test and downstream this release at your
> earliest convenience. Both are client side vulnerabilities, one of them
> requires a rogue server for exploitation.
>
> See the below changelog:
>
>
>    - - Added new maintainer: abhinavagarwal07 Abhinav Agarwal
>    - - Fixed critical vulnerability CVE-2026-47187
>    <https://github.com/libfuse/sshfs/security/advisories/GHSA-pjv6-2c3f-r357>
>    - Symlink Escape: Rogue SFTP Server to Local File Read/Write), credit to
>    abhinavagarwal07
>    - - New -o contain_symlinks and -o no_contain_symlinks to control
>    symlink containment behavior
>    - - Fixed high severity vulnerability CVE-2026-48711
>    <https://github.com/libfuse/sshfs/security/advisories/GHSA-mm85-q63v-4476>
>    - Improper Neutralization of Argument Delimiters in a Command ('Argument
>    Injection'), credit to abhinavagarwal07
>    - - Fixed null-deref warning in tokenize_on_space, promote
>    strict-warnings to required
>    - - Added a number of tests in CI, including rename, chmod, fsync,
>    statvfs values, error paths, option coverage
>    - - Fixed malformed SFTP reply handling
>    - - Hardened Github Actions workflow with SHA pins, permissions,
>    timeouts, and dependabot
>
>
> Thanks for all your efforts and continued support of SSHFS.
>
>
>
> _______________________________________________
> fuse-sshfs mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs
>
>
> _______________________________________________
> fuse-sshfs mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs
>
>
> _______________________________________________
> fuse-sshfs mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-sshfs
>