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)

CVE-2026-58272 · Severity: medium · CVSS 5.3 · Published 2026-09-21

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.

Technologies: @sync-in/server (npm). Vendors: npm.

Quick answers

Is CVE-2026-58272 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-58272 being exploited in the wild.
How severe is CVE-2026-58272?
Medium severity, with a CVSS score of 5.3, published 21 September 2026.
Which products and versions are affected?
@sync-in/server (npm) <= 2.4.0, SEMVER:introduced=0,fixed=2.4.1.
Is there a fix for CVE-2026-58272?
Yes. @sync-in/server (npm): upgrade to 2.4.1 or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-58272 attacked?
It is attacked over the network, in a hosted service.
Am I affected by CVE-2026-58272?
Check whether you run @sync-in/server (npm) at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • @sync-in/server (npm): upgrade to 2.4.1 or later
    npm install @sync-in/server@2.4.1

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

Identifiers

  • CVE-2026-58272
  • GHSA-29hq-23m2-2j47

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

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.