Description

Sync-in Server is an open-source platform for file storage, sharing, collaboration, and syncing. Versions prior to 2.4.1 contain 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-21T21:17:06.207Z",
  "pubdate": "2026-09-21T21:17:06.207Z",
  "executiveSummary": "Sync-in Server versions prior to 2.4.1 are susceptible to an observable timing discrepancy within the authentication endpoint, classified as an information disclosure vulnerability.\nThe vulnerability arises from non-constant time execution paths during login attempts; specifically, the application returns early when a requested account identifier does not exist in the database, bypassing the computational cost of the bcrypt password hashing function.\nThis flaw allows unauthenticated remote attackers to perform timing analysis on HTTP response latency to accurately enumerate valid usernames or email addresses registered on the platform.\nBy confirming the existence of valid accounts, adversaries can significantly enhance the efficacy of downstream attack vectors, including credential-stuffing, targeted password-spraying, and spear-phishing campaigns.\nThe exposure risk is elevated due to the lack of requirements for prior authentication or elevated privileges, enabling automated exploitation over the network.\nRemediation requires upgrading the Sync-in Server installation to version 2.4.1, which implements a constant-time authentication response mechanism.",
  "technicalDetails": "The vulnerability is localized to the authentication logic of the Sync-in Server login endpoint. The root cause is a branch-dependent execution path that deviates based on the validity of the provided user identifier.\nWhen a login request is processed, the system first queries the backend database for the presence of the submitted account identifier. If the account is not found, the function returns an error response immediately.\nConversely, if the account exists, the application proceeds to retrieve the stored hashed password and utilizes the bcrypt algorithm to verify the provided plaintext password against the hash. The bcrypt computation is intentionally resource-intensive to prevent brute-force attacks, creating a significant, measurable latency difference compared to the early-return path taken by nonexistent accounts.\nAn attacker can exploit this timing discrepancy by sending a series of crafted login requests and measuring the Round-Trip Time (RTT) of the server response with high precision. By calculating the statistical variance in response times, the attacker can distinguish between legitimate account identifiers (which incur the overhead of the bcrypt operation) and non-existent identifiers (which resolve near-instantaneously).\nThe attack flow follows a systematic process: 1) The attacker compiles a list of candidate usernames or email addresses. 2) The attacker submits automated HTTP requests to the login endpoint for each candidate. 3) The attacker captures and filters response latency data to remove network jitter. 4) Candidates that consistently correlate with high-latency signatures are flagged as valid user accounts.\nThis enumeration process does not require any specialized privileges or previous access to the application, making it highly accessible to external actors. Because the bcrypt comparison is the primary bottleneck, the temporal difference is sufficiently large to be detectable over standard network connections.\nSuccessful exploitation facilitates post-exploitation activities such as account takeovers through credential stuffing or brute-forcing. Furthermore, by identifying specific user account patterns, attackers can craft highly targeted phishing lures, increasing the likelihood of successful credential harvesting or social engineering attacks against the platform's user base.\nAll Sync-in Server versions prior to 2.4.1 are confirmed to be affected. The mitigation in version 2.4.1 ensures that the server performs a dummy bcrypt computation or enforces a fixed response delay regardless of account existence, thereby normalizing the response time and obfuscating the authentication result."
}