CVE-2026-58272: @sync in/server Sync-in Server Has Username/Login Enumeration Vulnerability

{
  "schema_version" : "1.4.0",
  "id" : "GHSA-29hq-23m2-2j47",
  "modified" : "2026-09-22T14:49:23Z",
  "published" : "2026-09-22T14:49:23Z",
  "aliases" : [ "CVE-2026-58272" ],
  "summary" : "Sync-in Server has Username/Login Enumeration via Timing Side-Channel on POST /api/auth/login (incomplete fix of the prior timing-attack advisory)",
  "details" : "## Summary\n\nvalidateUser() 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():\n\n    async validateUser(loginOrEmail: string, password: string, ip?: string, scope?: AUTH_SCOPE): Promise<UserModel> {\n      let user: UserModel\n      try {\n        user = await this.usersManager.findUser(loginOrEmail, false)\n      } catch (e) { ... }\n      if (!user) {\n        this.logger.warn(...)\n        return null   // <-- comparePassword() is never reached here\n      }\n      return await this.usersManager.logUser(user, password, ip, scope)\n    }\n\ncomparePassword() (backend/src/common/functions.ts) already contains a dummy-hash branch that was clearly added to defend against exactly this class of attack:\n\n    export async function comparePassword(password: string, hash?: string | null): Promise<boolean> {\n      if (!hash) {\n        // No hash, waste time for time-based attacks\n        await bcrypt.compare(password, DUMMY_PASSWORD_HASH)\n        return false\n      }\n      return await bcrypt.compare(password, hash)\n    }\n\nThe 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.\n\nThere'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.\n\n## Impact\n\nAny unauthenticated client can determine whether a given username/email is a valid account on the instance by timing POST /api/auth/login:\n- Non-existent login: near-instant rejection (no bcrypt call).\n- Existing login (regardless of password correctness): consistently slower due to a real bcrypt comparison.\n\nThis enables efficient enumeration of valid accounts, which can then be used to focus credential-stuffing, password-spraying, or phishing against confirmed-valid targets.\n\n## Proof of Concept\n\nVerified with the actual comparePassword() logic and the real DUMMY_PASSWORD_HASH constant copied verbatim from backend/src/common/functions.ts, using the project's own bcryptjs dependency (no mocking of bcrypt itself):\n\n    Avg time for \"login does not exist\" path (validateUser returns null, no bcrypt call): 0.00 ms\n    Avg time for \"login exists, wrong password\" path (real bcrypt.compare runs):          114.90 ms\n    Difference: 114.90 ms (ratio: ~58923x)\n\nThe \"not found\" path reproduces validateUser()'s exact early return (no call into comparePassword); the \"wrong password\" path reproduces logUser()'s real call into comparePassword(password, user.password). The gap is large enough to be trivially observable over a real network, even accounting for jitter.\n\nReachable endpoint: POST /api/auth/login, guarded only by AuthLocalGuard (Passport local strategy invoking validateUser()), no authentication required.\n\n## Suggested fix\n\nMake validateUser() always pass through comparePassword()'s timing-equalized path, even when no user is found, e.g.:\n\n    if (!user) {\n      await comparePassword(password, null) // burns the same time as a real comparison\n      return null\n    }\n\nso the \"account not found\" and \"account found, wrong password\" branches take statistically indistinguishable time.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "@sync-in/server"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "2.4.1"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 2.4.0"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/Sync-in/server/security/advisories/GHSA-29hq-23m2-2j47"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-58272"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Sync-in/server/commit/b80efe04574039a7a302c0e1007f03a7dbe6a633"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/Sync-in/server"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Sync-in/server/releases/tag/v2.4.1"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-208" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-09-22T14:49:23Z",
    "nvd_published_at" : "2026-09-21T21:17:06Z"
  }
}