Executive brief
Sync-in Server is a file storage and collaboration platform that includes a login system. Attackers can determine whether a username exists on a Sync-in instance by measuring how long the login API takes to respond—non-existent accounts respond nearly instantly, while valid accounts take ~115ms longer due to password hashing. This allows adversaries to build a list of valid accounts to target with password-guessing or phishing attacks.
Technical details
The vulnerability is a timing side-channel in the validateUser() function (backend/src/authentication/providers/mysql/auth-provider-mysql.service.ts). When a login attempt fails because the user does not exist, the function returns null immediately via an early return statement, completely bypassing the comparePassword() function. In contrast, when a user exists but the password is wrong, comparePassword() is invoked and performs a real bcrypt comparison (cost factor 10, ~100ms+). Although a previous advisory attempted to mitigate timing attacks by adding a dummy-hash branch to comparePassword(), this protection is never reached for non-existent users due to the early return in validateUser(). The two code paths are trivially distinguishable by response time: the "account not found" path takes ~0ms, while the "account exists" path consistently takes ~115ms. The vulnerability is reachable via the unauthenticated POST /api/auth/login endpoint. A fix is available in version 2.4.1, which ensures validateUser() always calls comparePassword() even when no user is found, burning cryptographic time in both branches.
Affected products
- Sync-in @sync-in/server <= 2.4.0
Timeline
- 2026-09-22: disclosed: Advisory GHSA-29hq-23m2-2j47 published
- 2026-06-24: patched: Fix committed (b80efe04) and released in v2.4.1
- 2026-09-21: other: CVE-2026-58272 published on NVD