CVE-2026-58269 in Server
Summary
by MITRE • 09/21/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/21/2026
Sync-in Server is an open-source platform designed for file storage, sharing, collaboration, and synchronization across devices. A critical authentication bypass vulnerability was identified in versions prior to 2.4.0 within the API endpoint responsible for issuing JSON Web Tokens (JWTs). The flaw resides specifically in the POST /api/auth/token endpoint, which accepts username and password credentials to authenticate a user session. Upon receiving valid credentials, this endpoint invokes an internal function called getTokens() that generates and returns both full access tokens and refresh JWTs without performing any additional verification regarding two-factor authentication status. This design oversight creates a significant security gap because the system fails to check whether the targeted account has Time-based One-Time Password (TOTP) second factor enabled before issuing these persistent session credentials.
The operational impact of this vulnerability is severe, as it allows an attacker who possesses stolen or phished username and password combinations to completely bypass two-factor authentication protections in a single HTTP request. Since JWTs are typically used for stateless authentication across multiple requests, obtaining valid access and refresh tokens grants the attacker full administrative control over the compromised account without ever needing to provide the second factor code. This effectively nullifies the security benefit of TOTP 2FA for any user whose credentials have been exposed through phishing, credential stuffing, or data breaches. The vulnerability is particularly dangerous because it operates silently in the background API layer, making detection by standard web application firewalls more difficult compared to direct UI-based bypasses.
In contrast, the parallel login endpoint POST /api/auth/login correctly enforces two-factor authentication requirements. This endpoint utilizes a function called setCookies(user, res, true) which explicitly gates access based on the user.twoFaEnabled attribute. If TOTP is enabled for an account, this path requires additional verification steps before proceeding with session establishment. The inconsistency between these two endpoints highlights a lack of centralized authentication logic enforcement within the application architecture. While one path respects security policies and the other ignores them, attackers can simply target the vulnerable token endpoint to circumvent all multi-factor protections intended by the system administrators.
This vulnerability aligns with CWE-287 Improper Authentication, as the software does not adequately verify identity during authentication processes when secondary factors are required. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, where attackers leverage legitimate credentials to gain unauthorized access while evading additional security controls like MFA. The root cause is a failure in implementing consistent security checks across all entry points that result in session token issuance. Developers must ensure that any API endpoint capable of generating authentication tokens performs comprehensive validation against the user's current security profile, including multi-factor status, regardless of whether primary credentials are valid.
To mitigate this issue and prevent similar flaws in future development, it is essential to centralize authentication logic into a shared service or middleware layer that enforces consistent policy checks before any token generation occurs. All endpoints responsible for issuing JWTs must explicitly verify the twoFaEnabled flag and reject requests if secondary factors are required but not provided. Additionally, implementing rate limiting on authentication-related API calls can help reduce the effectiveness of automated credential stuffing attacks. Organizations using Sync-in Server versions prior to 2.4.0 should upgrade immediately as version 2.4.0 patches this specific bypass vulnerability by ensuring that token issuance respects two-factor authentication settings uniformly across all authentication pathways.