CVE-2026-58271

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.

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.

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.

Summary

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…

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.

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.

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.

Summary

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…