CVE-2026-58272: Sync-in Server has Username/Login Enumeration via Timing Side-Channel on POST /api/auth/login (incomplete fix of the prior timing-attack advisory)

validateUser() in backend/src/authentication/providers/mysql/auth-provider-mysql.service.ts returns immediately when the supplied login/email does not match any account, without ever calling comparePassword():

async validateUser(loginOrEmail: string, password: string, ip?: string, scope?: AUTH_SCOPE): Promise { let user: UserModel try { user = await this.usersManager.findUser(loginOrEmail, false) } catch (e) { … } if (!user) { this.logger.warn(…) return null // <– comparePassword() is never reached here } return await this.usersManager.logUser(user, password, ip, scope) }

comparePassword() (backend/src/common/functions.ts) already contains a dummy-hash branch that was clearly added to defend against exactly this class of attack:

export async function comparePassword(password: string, hash?: string | null): Promise { if (!hash) { // No hash, waste time for time-based attacks await bcrypt.compare(password, DUMMY_PASSWORD_HASH) return false } return await bcrypt.compare(password, hash) }

The problem is that this protection only runs when comparePassword() is actually invoked with a falsy hash. Because validateUser() short-circuits with return null as soon as findUser() comes back empty, the “account doesn’t exist” path skips all cryptographic work entirely, while the “account exists, wrong password” path always performs a real bcrypt comparison (cost factor 10, ~100ms+). The two outcomes are trivially distinguishable by response time.

There’s already a published advisory in this repo for “Username Enumeration via Timing Attack” - this looks like the same underlying issue surfacing through a different call path (the early return in validateUser()) that the existing fix (the dummy-hash branch in comparePassword()) doesn’t actually reach, rather than a brand new vulnerability class.