CVE-2026-62325: goshs SFTP Authentication Bypass via Empty Password
Starting goshs v2.1.3 with a password-less basic-auth flag and SFTP enabled lets any attacker connect to the SFTP service without supplying credentials, because the password handler is never…

The problem
goshs uses && at sftpserver/sftpserver.go:85 to decide whether to install an SFTP password handler. When either the username or password field is empty, the condition is false and no handler is registered.
With no password handler and no public-key handler (-fkf not used), the underlying gliderlabs/ssh library sees all auth callbacks as nil and silently enables NoClientAuth = true. Any client can then connect without credentials and read, write, rename, or delete files over SFTP.
This is an incomplete fix of CVE-2026-40884, which only blocked the empty-username variant (-b ':pass') via a strings.HasPrefix sanity check. The empty-password variant (-b 'admin:') was never covered, and the root-cause && logic remained in place through v2.1.3.
Proof of concept
A working proof-of-concept for CVE-2026-62325 in github.com/patrickhener/goshs/v2, with the exact payload below.
# Start goshs with an empty password and SFTP enabled (no -fkf)
goshs -b 'admin:' -sftp
# On attacker machine: connect without supplying a password
# PreferredAuthentications=none bypasses the client-side password prompt;
# gliderlabs/ssh accepts the connection because NoClientAuth is true.
echo 'ls -la /' | sftp \
-o StrictHostKeyChecking=no \
-o UserKnownHostsFile=/dev/null \
-o PreferredAuthentications=none \
-o PubkeyAuthentication=no \
-P 2022 admin@<TARGET>The root cause is the && operator at sftpserver/sftpserver.go:85. The condition s.Username != "" && s.Password != "" is false whenever either field is empty, so sshServer.PasswordHandler is never assigned. With no public-key handler set either, gliderlabs/ssh falls through to NoClientAuth = true.
The v2.1.4 patch makes two changes derived from the diff: it flips && to || in sftpserver.go (handler is now installed when at least one credential is present), and it adds a strings.HasSuffix(opts.BasicAuth, ":") guard in sanity/checks.go alongside the existing HasPrefix check, so goshs exits early with a fatal error when -b 'user:' is passed with -sftp.
CWE-306 applies directly: a critical function (SFTP file access) lacked authentication because the handler registration was silently skipped.
The fix
Upgrade to goshs v2.1.4 (commit 32f4a0e). The release changes the boolean operator in sftpserver/sftpserver.go from && to || and adds the missing HasSuffix(":") input validation in sanity/checks.go. If you cannot upgrade immediately, avoid starting goshs with an empty password (-b 'user:') alongside -sftp, and always supply -fkf with an authorized-keys file to keep an explicit public-key handler registered.
Related research
- high · 7.4CVE-2026-53714CVE-2026-53714: Envoy Gateway xDS Authentication Bypass in GatewayNamespaceMode
- critical · 9.6CVE-2026-53649CVE-2026-53649: Joro Unauthenticated Cross-Origin Plugin Upload RCE
- high · 8.6CVE-2026-54650CVE-2026-54650: openhole-server Path Traversal via Percent-Encoded URL Segments
- critical · 9.1CVE-2026-64863CVE-2026-64863: goshs WebDAV MOVE Bypasses --no-delete