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

[Nikolaus R. <nik...@ra...>]

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