CVE-2026-58270

Sync-in Server before version 2.4.1 has an observable timing discrepancy in the login endpoint because authentication attempts for nonexistent accounts return without performing the bcrypt comparison used for existing accounts. An unauthenticated attacker can measure response times to enumerate valid usernames or email addresses, facilitating credential-stuffing, password-spraying, and phishing attacks. Version 2.4.1 contains a patch.

In Sync-in Server prior to version 2.4.0, the failed-TOTP lockout mechanism does not work because the passwordAttempts counter is never incremented. An attacker can brute-force TOTP codes without limit, and upon success obtain a client token exchangeable for a full JWT and permanently disable MFA.

Sync-in Server is an open-source platform for file storage, sharing, collaboration, and syncing. Prior to version 2.4.0, POST /api/auth/token authenticates with username and password only, then calls getTokens(), which returns full access and refresh JWTs without checking whether the account has TOTP 2FA enabled. An attacker with stolen or phished credentials can bypass 2FA in a single request. The parallel login endpoint (POST /api/auth/login) correctly enforces 2FA by calling setCookies(user, res, true), which gates on user.twoFaEnabled. Version 2.4.0 patches the issue.

Sync-in Server is a secure, open-source platform for file storage, sharing, collaboration, and syncing. In versions prior to 2.3.0, the regex used in the URL download feature for blocking private IP addresses does not match IPv4-mapped IPv6 addresses, allowing SSRF protection to be bypassed on dual-stack systems.