Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
validateUser() in backend/src/authentication/providers/mysql/auth-provider-mysql.service.ts returns immediately when the supplied login/email does not match any account, without ever calling comparePassword(): async validateUser(loginOrEmail: string, password: string, ip?: string, scope?: AUTHSCOPE): Promise<UserModel { let user: UserModel try { user = await this.usersManager.findUser(loginOrEmail, false) } catch (e) { ... } if (!user) { this.logger.warn(...) return null // <-- comparePassword() is never reached here } return await this.usersManager.logUser(user, password, ip, scope) } comparePassword() (backend/src/common/functions.ts) already contains a dummy-hash branch that was clearly added to defend against exactly this class of attack: export async function comparePassword(password: string, hash?: string | null): Promise<boolean { if (!hash) { // No hash, waste time for time-based attacks await bcrypt.compare(password, DUMMYPASSWORDHASH) return false } return await…
Recommended action: Upgrade to 2.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected component: Sync-in Server v2.3.0, POST /api/app/sync/operation/diff/:id, vulnerable implementation of pathFilters in backend/src/applications/sync/dtos/sync-operations.dto.ts. Summary In the vulnerable version, the sync diff endpoint accepted a user-controlled regex pattern through pathFilters and compiled it into a RegExp without complexity validation. The resulting regex was then executed synchronously against relative file paths during diff generation. A catastrophic-backtracking pattern, such as ^(a+)+b, can block the affected Node.js event loop when evaluated against a worst-case path shape. In a single-process deployment, this can make the server unavailable to other users while the regex evaluation is running. Repeated malicious requests can sustain the denial of service. Details SyncDiffDto transformed user input directly into a RegExp without validating regex complexity: The compiled regex was then executed synchronously during sync diff traversal: Because .test()…
Recommended action: Upgrade to 2.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: getTokens() at auth.service.ts:25-39 signs and returns access and refresh JWTs. It never reads user.twoFaEnabled: Compare with the login endpoint at auth.controller.ts:30-35, which calls…
Recommended action: Upgrade to 2.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected component: Sync-in Server v2.3.0, POST /api/app/sync/register. Required attacker capability: Valid login and password for a TOTP-enabled account with desktop sync permission. Summary POST /api/app/sync/register accepts credentials and a TOTP code to register a desktop sync client. In the vulnerable version, on a failed TOTP attempt, SyncClientsManager.register() called updateAccesses(user, ip, false), which hit a freeze branch that wrote passwordAttempts back unchanged. The counter never reached USERMAXPASSWORDATTEMPTS (10), so the account lockout gate never fired for repeated TOTP failures through this endpoint. A successful TOTP guess registers a sync client and returns a {clientId, clientToken} pair, provided the account has the required desktop app permission and the registration payload is valid. The token can then be exchanged via POST /api/app/sync/auth/cookie for an authenticated session. While the guessed TOTP code is still valid, and because the attacker already…
Recommended action: Upgrade to 2.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The private IP blocklist regex used in the URL download feature does not match IPv4-mapped IPv6 addresses (e.g. ::ffff:127.0.0.1), allowing SSRF protection to be bypassed on dual-stack systems. Affected components backend/src/applications/files/services/files-manager.service.ts – downloadFromUrl() checks regExpPrivateIP against request.socket.remoteAddress. backend/src/applications/files/utils/url-file.ts – regExpPrivateIP does not include ::ffff:<ipv4 variants. Details: The regExpPrivateIP regex in backend/src/applications/files/utils/url-file.ts correctly blocks standard IPv4 private ranges but does not include ::ffff: prefixed variants. On dual-stack systems, Node.js can report a socket's remoteAddress in IPv4-mapped IPv6 form, meaning the check in FilesManager.downloadFromUrl() can be bypassed entirely. PoC: poc.pdf Proof: <img width="1080" height="842" alt="1000226655" src="https://github.com/user-attachments/assets/797cea83-0a08-4a16-a91b-31c51068d473" / Impact: An…
Recommended action: Upgrade to 2.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The /api/auth/login endpoint contains a logic flaw that allows unauthenticated remote attackers to enumerate valid usernames by measuring the application's response time. Details The logic flaw can be located at the below point in source: https://github.com/Sync-in/server/blob/7868bb2b3025f92e6c38087456304758713971b2/backend/src/applications/users/services/users-queries.service.ts#L91-L95 Endpoints used for authentication should respond to the user with a consistent cadence, preventing remote actors from deriving sensitive information about an application based on backend behavior. In the case of authentication endpoints, this timing discrepancy is often caused by short-circuiting due to the lack of a matched user to compare against - as is the case with Sync-in. Validation TickTock Enum (Burp Suite Extension) was utilized to validate this finding. Authentication attempts with a valid username see a response from the application at around 350-400ms on average, while invalid…
Recommended action: Upgrade to 2.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Stored Cross-Site Scripting (XSS) vulnerability in Sync-in Server before 1.9.3 allows an authenticated attacker to execute arbitrary JavaScript in a victim's browser. By uploading a crafted SVG file containing a malicious payload, an attacker can access and exfiltrate sensitive information, including the user's session cookies.
Recommended action: Upgrade to 1.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.