Threat Intelligence Database

Sync-in Server is an open-source platform for file storage, sharing, collaboration, and syncing. Versions prior to 2.4.1 contain an observable timing discrepancy in the login endpoint because authentication attempts for nonexistent accounts return without performing the bcrypt comparison used for existing accounts. An unauthenticated attacker can measure response times to enumerate valid usernames or email addresses, facilitating credential-stuffing, password-spraying, and phishing attacks. Version 2.4.1 contains a patch.

Sync-in Server is an open-source platform for file storage, sharing, collaboration, and syncing. Prior to version 2.4.0, the sync diff endpoint compiles a user-supplied string into a `RegExp` with no complexity validation. A catastrophic-backtracking pattern (e.g. `^(a+)+b`) blocks the Node.js event loop, making the entire server unresponsive to all users until the container is restarted. Version 2.4.0 patches the issue.

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.

Sync-in Server is an open-source platform for file storage, sharing, collaboration, and syncing. Prior to version 2.4.0, `POST /api/app/sync/register` accepts credentials and a TOTP code to register a desktop sync client. On a failed TOTP, `SyncClientsManager.register()` calls `updateAccesses(user, ip, false)`, which hits a freeze branch that writes `passwordAttempts` back unchanged. The counter never reaches `USER_MAX_PASSWORD_ATTEMPTS` (10) and the lockout gate never fires. A successful guess returns a `{clientId, clientToken}` pair. The token can be exchanged via `POST /api/app/sync/auth/cookie` for a full JWT. While the code is valid, the attacker can also call `POST /api/auth/2fa/disable` to permanently remove MFA. Version 2.4.0 patches the issue.

File owners were unable to unlock TYPE_TOKEN locks placed by other users, leaving files permanently locked with no recovery path outside of the database.

After guessing a 62^15 complex unique identifier, a malicious logged in user was able to retrieve a list of memberships for a circle they are not a member of.

Devolutions Server versions 2026.2.16 and earlier have an improper certificate validation vulnerability on LDAPS connections to Active Directory. This flaw allows a network-positioned attacker to intercept privileged directory service credentials by presenting a spoofed domain controller certificate.

A Server-Side Request Forgery (SSRF) vulnerability exists in the VMware synchronization feature of Devolutions Server versions 2026.2.16 and earlier. This flaw allows a low-privileged authenticated user to access other users' credentials and reach internal or cloud-metadata network endpoints by submitting a crafted connection definition for datacenter discovery.

An improper access control vulnerability exists in the vault entry listing feature of Devolutions Server versions 2026.2.16 and earlier. This flaw allows an authenticated user without the view-password permission to retrieve cleartext passwords by sending a specially crafted request to the entry listing endpoint with password disclosure parameters.

Devolutions Server versions 2026.2.16 and earlier contain an improper certificate validation vulnerability in the shared HTTP client used by synchronization and integration features. This flaw allows a network-positioned attacker to intercept and modify outbound TLS connections by presenting a spoofed or self-signed certificate.