GHSA-92cr-jxw4-5wjg: High severity npm/@sync-in/server vulnerability

Published Sep 22, 2026
·
Updated

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(AUTHROUTE.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 { [TOKENTYPE.ACCESS]: await this.jwtSign(user, TOKENTYPE.ACCESS, accessExpiration), [TOKENTYPE.REFRESH]: await this.jwtSign(user, TOKENTYPE.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 ACCESS2FA 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.access2faexpiration (a restricted partial token): POST /api/auth/login {"login":"test","password":"..."}

Response: {"user":{"twoFaEnabled":true},"server":{"twoFaEnabled":true},"token":{"access2faexpiration":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...", "accessexpiration": 1781235890, "refreshexpiration": 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().

Affected Software

1 affected componentFixes available
npm/@sync-in/server<=2.3.0
2.4.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/@sync-in/server to a version that resolves this vulnerability.

    Fixed in 2.4.0
  2. Compensating control

    Gate POST /api/auth/token behind the same 2FA policy as POST /api/auth/login: 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().

Event History

Sep 22, 2026
Advisory Published
via GitHub·02:46 PM
Data Sourced
via GitHub·02:46 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Which deployments and accounts are exposed?

Sync-in Server v2.3.0 is affected at POST /api/auth/token. The issue applies to accounts with TOTP 2FA enabled when server-side TOTP is enabled.

2

What does an attacker need to bypass 2FA?

The attacker needs a valid username and password for a 2FA-enabled account. No TOTP code or user interaction is required for the token request.

3

What access does a successful request provide?

The endpoint returns unrestricted Bearer access and refresh JWTs. These tokens are issued without checking the account's twoFaEnabled setting.

4

Does the standard login endpoint have the same behavior?

No. POST /api/auth/login invokes the 2FA-aware cookie-setting path and gates authentication on user.twoFaEnabled when server-side TOTP is enabled.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203