Sync-in Server CVE-2026-58271

Exploitation requires that the attacker already possess the victim's valid username and password (PR:L) and that the target account has 2FA/TOTP enabled - the flaw specifically defeats the second factor by preventing the failed-attempt counter from ever reaching USER_MAX_PASSWORD_ATTEMPTS (10) on the POST /api/app/sync/register desktop-sync path. Limiting factors: the attacker must brute-force a rotating 6-digit TOTP within its short validity window (reflected as AC:H), and must hold working first-factor credentials, so this is not exploitable against accounts for which the attacker lacks the password. Affected deployments are Sync-in Server instances prior to version 2.4.0.

This is a real, credible authentication-security issue but not a mass-exploitation emergency. The CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N, base 6.8) correctly captures a network-reachable flaw that nonetheless requires meaningful preconditions: AC:H reflects the need to brute-force a rotating 6-digit TOTP within its validity window, and PR:L reflects that the attacker must already possess the victim's valid username and password - the vulnerability defeats the second factor, not the first. Impact is genuine (C:H/I:H): a successful guess yields a clientToken exchangeable for a full JWT, and the attacker can then permanently disable MFA, i.e. full account takeover. No EPSS score, no CISA KEV listing, and no public POC were provided, so this is 'no public exploit identified at time of analysis' - treat exploitation as plausible-but-unproven rather than active. The 6.8 rating is broadly justified; the practical risk hinges entirely on whether an attacker has already obtained valid passwords (credential stuffing/phishing), so this is best prioritized as a defense-in-depth/MFA-integrity fix rather than an unauthenticated RCE-tier drop-everything issue.

An attacker who has already harvested a Sync-in user's password (via phishing or a prior breach) but is blocked by 2FA repeatedly calls POST /api/app/sync/register with that password and guessed TOTP codes; because failed TOTP attempts never increment the lockout counter, the account is never locked and the code can be brute-forced. On a correct guess the server returns {clientId, clientToken}, which the attacker exchanges at POST /api/app/sync/auth/cookie for a full JWT and then calls POST /api/auth/2fa/disable to permanently strip MFA. No public exploit code is currently identified, but the attack requires only standard HTTP requests once valid credentials are held.