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

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

On Sun, 31 May 2026, at 17:02, Abhinav Agarwal wrote:
> 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).

I still do not understand how this is different from, for example, root accessing a symlink in a user's home directory.

Putting it differently, you should never follow symlinks when writing into a path that you do not trust. This is already the case locally, and it also applies when accessing a network mount (like SSHFS).

My best guess is that you're trying to make SSHFS mounts more secure than local directories. Maybe that's a useful feature in some situations, but the absence of such an (unexpected) feature is not a security vulnerability any more that my front door has a "security vulnerability" because it doesn't protect me from walking out without an umbrella and getting wet if it rains. It's not the job of a front door to protect me from rain, and it's not the job of a filesystem to protect the user from symlinks.

> 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. 

I disagree that this is a reasonable expectation. If you don't want to follow symlinks (because you don't trust them), you shouldn't use file system operations that automatically follow symlinks. 

> 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 
> [...]

The crucial difference is that "transform_symlinks" is a convenience feature that needs to be explicitly enabled, it is not a security feature. I have no objections to making transform_symlinks more powerful but please don't call it a security vulnerability - and don't enable it by default.

(The documentation of the new "contain_symlinks" option says that it rejects access to any symlink target containing ".." - this will cover a huge number of legitimate use-cases and isn't even needed, since only targets that resolve to outside the mountpoint are risky by your definition).

> hardening gap, not just generic Unix symlink advice. rsync draws the same line: --safe-links exists precisely to 

The crucial difference is that rsync is not providing a filesystem but writing to the local filesystem, which users may want to continue to trust.

> 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, 

...is buggy and has a security vulnerability. That's not SSHFS fault.


By all means, I do not object to any of the changes. You found a bug in the argument parsing (though it requires intent to trigger), and you added a feature to block access to some symlinks. These are real improvements, but there is no need to sell them as security vulnerabilities. The claim that not using "contain_symlinks" should only be used with "fully trusted" servers is misleading (you should still think twice about connecting to an untrusted server even if you enable contain_symlinks, and not using contain_symlinks simply means that you should not trust the directory structure any more than you trust the server).


Best,
-Nikolaus