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

[H T. <hao...@gm...>]

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. The vuln is a malicious server (e.g. a unix shared box
where an attacker has root) can read and write outside that directory.
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.

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.

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
>