CVE-2026-58271 in Server
Summary
by MITRE • 09/21/2026
Sync-in Server is an open-source platform for file storage, sharing, collaboration, and syncing. Prior to version 2.4.0, `POST /api/app/sync/register` accepts credentials and a TOTP code to register a desktop sync client. On a failed TOTP, `SyncClientsManager.register()` calls `updateAccesses(user, ip, false)`, which hits a freeze branch that writes `passwordAttempts` back unchanged. The counter never reaches `USER_MAX_PASSWORD_ATTEMPTS` (10) and the lockout gate never fires. A successful guess returns a `{clientId, clientToken}` pair. The token can be exchanged via `POST /api/app/sync/auth/cookie` for a full JWT. While the code is valid, the attacker can also call `POST /api/auth/2fa/disable` to permanently remove MFA. Version 2.4.0 patches the issue.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/21/2026
Sync-in Server serves as an open-source platform facilitating file storage, sharing, collaboration, and synchronization across devices. A critical authentication bypass vulnerability exists in versions prior to 2.4.0 within the endpoint POST /api/app/sync/register. This API is designed to register desktop sync clients by accepting user credentials along with a Time-based One-Time Password (TOTP) code for multi-factor authentication verification. The flaw resides in the implementation of the SyncClientsManager.register() method, which handles the validation logic for these TOTP codes during the registration process.
The technical root cause is a logical error in the failure handling path when an incorrect TOTP code is provided. Upon receiving invalid credentials or a failed TOTP attempt, the system invokes updateAccesses(user, ip, false) to track authentication failures. However, this function contains a freeze branch that writes the passwordAttempts counter back unchanged rather than incrementing it. Consequently, the failure count never progresses toward USER_MAX_PASSWORD_ATTEMPTS, which is set at ten attempts. This defect effectively disables brute-force protection mechanisms for TOTP codes during client registration, allowing an attacker to retry guesses indefinitely without triggering account lockout or temporary bans.
The operational impact of this vulnerability is severe as it allows unauthorized access through credential stuffing or brute-forcing of the second factor. Once an attacker successfully guesses a valid TOTP code, the system returns a clientId and clientToken pair. This token serves as a session identifier that can be exchanged via POST /api/app/sync/auth/cookie for a full JSON Web Token (JWT). Possession of this JWT grants the attacker authenticated access to the user's account with all associated privileges. Furthermore, while holding a valid token derived from this bypassed authentication flow, an attacker can invoke POST /api/auth/2fa/disable to permanently remove multi-factor authentication from the compromised account. This ensures persistent access even if the victim changes their password or rotates other credentials later.
From a classification perspective, this vulnerability aligns with CWE-307 Improper Restriction of Excessive Authentication Attempts and CWE-640 Weak Password Recovery Mechanism for Forgotten Password as it undermines the integrity of the authentication state management. In terms of attack vectors, it corresponds to MITRE ATT&CK technique T1110 Brute Force, specifically targeting multi-factor authentication mechanisms, and potentially T1538 Cloud Service Dashboard if used to access administrative interfaces. The ability to disable MFA post-compromise also relates to persistence techniques aimed at maintaining long-term unauthorized access.
To mitigate this risk, organizations running Sync-in Server versions prior to 2.4.0 should upgrade immediately to version 2.4.0 or later where the logic error in updateAccesses has been corrected. For environments unable to patch instantly, implementing a rate-limiting solution at the network perimeter can help throttle excessive requests to the registration endpoint. Additionally, monitoring for unusual patterns of failed TOTP attempts followed by successful registrations may aid in early detection of exploitation attempts. Ensuring that authentication failure counters are correctly incremented and persisted regardless of outcome is essential for maintaining robust security posture against automated attacks.