OFFLINE
Awaiting data
Security intelligence
MajorCritical vulnerability

CVE-2026-58269: Sync-in Server has a complete 2FA Bypass via `POST /api/auth/token`

GitHub Advisories · officialPublished Sep 22, 2026Risk 37/100

**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":"[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 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()`.

Upgrade affected packages to a patched version: @sync-in/server 2.4.0.

Vendor
Not specified
Product
@sync-in/server
Exploitation
none known
Evidence
official
CVSS
8.1

This record is attributed to GitHub Advisories. Exploitation status and remediation guidance are kept separate from the vulnerability's technical severity.

Open primary source