CVE-2026-58270: Regular Expression Denial of Service (ReDoS) in Sync-in Server

The Sync-in Server provides an open-source platform designed for file storage, sharing, and synchronization. The primary entry point for determining differences between client-side and server-side directories is the API endpoint POST /api/app/sync/operation/diff/:id. This endpoint allows clients to optimize operations by filtering synchronization tasks based on file paths. The system exposes an input parameter named pathFilters within the HTTP request body to handle this filtering functionality.

In vulnerable instances (prior to version 2.4.0), the application accepts user-controlled inputs for this parameter and compiles them directly into native JavaScript RegExp objects. Because these inputs are evaluated synchronously against paths during directory traversal, the endpoint exposes a significant attack surface. An attacker can exploit this behavior by introducing complex regular expression patterns designed to exhaust server resources.

Because Node.js runs on a single-threaded architecture, any CPU-intensive synchronous operation immediately impacts application performance. Evaluating a complex regular expression against a large directory structure under these conditions results in thread starvation. The resulting event-loop blockage denies access to all other application features for all active users.

The underlying technical flaw lies in the handling of the pathFilters property during data transfer object (DTO) validation. The backend employs the class-transformer library to map and sanitize input properties incoming from the request. In the vulnerable configuration, the mapping process lacks constraints on both string length and regular expression syntax structure.

The JavaScript regular expression engine inside the V8 runtime uses a backtracking-based matching algorithm (a Non-deterministic Finite Automaton, or NFA). When a regular expression containing nested quantifiers or overlapping alternations (such as (a+)+) is evaluated against an input string that matches the pattern only partially before failing (such as aaaa...aaac), the engine attempts to evaluate every possible parsing permutation before determining a non-match. This causes the matching complexity to scale exponentially ($O(2^N)$) or as a high-degree polynomial relative to the input length.

Because the V8 regular expression engine executes synchronously within the active thread context, the event loop is unable to process other ticks. This blocks inbound TCP connections, HTTP requests, database transactions, and health checks. System metrics will show 100% CPU utilization on the core running the Node.js process while the process remains completely unresponsive.

Prior to version 2.4.0, the vulnerability was located in backend/src/applications/sync/dtos/sync-operations.dto.ts. The class SyncDiffDto contained the following insecure instantiation logic:

export class SyncDiffDto {
  // ... other properties
 
  @IsOptional()
  @Transform(({ value }) => (typeof value === 'string' && value.length > 0 ? new RegExp(value, 'i') : null))
  pathFilters?: RegExp = null
}

The implementation shown above executes the new RegExp(value, 'i') constructor directly on any non-empty string. It does not limit the length of value or analyze the input for nested repetitions.

To resolve this issue, the patch implemented in commit b1dcaa1d1c1bb17ab6c31a404cc9cead7efdd979 routes the string validation through a secure helper function named transformPathFilters:

import { BadRequestException } from '@nestjs/common'
import safeRegex from 'safe-regex2'
 
const MAX_PATH_FILTER_LENGTH = 200
const MAX_PATH_FILTER_REPETITIONS = 25
 
export function transformPathFilters(value: unknown): RegExp | null {
  // 1. Verify type structure
  if (typeof value !== 'string' || value.length === 0) {
    return null
  }
 
  // 2. Reject inputs exceeding static length limits
  if (value.length > MAX_PATH_FILTER_LENGTH) {
    throw new BadRequestException('Path filter pattern is too long')
  }
 
  // 3. Prevent runtime syntax compilation errors
  let pathFilter: RegExp
  try {
    pathFilter = new RegExp(value, 'i')
  } catch {
    throw new BadRequestException('Invalid path filter pattern')
  }
 
  // 4. Validate regular expression complexity via AST heuristic analysis
  if (!safeRegex(pathFilter, { limit: MAX_PATH_FILTER_REPETITIONS })) {
    throw new BadRequestException('Unsafe path filter pattern')
  }
 
  return pathFilter
}

This remediation structure enforces verification layers at four distinct stages. The inclusion of the safe-regex2 library analyzes the compiled regular expression's abstract syntax tree (AST) to identify potential catastrophic backtracking scenarios before the pattern can be run against system-level file paths.

To exploit this vulnerability, an attacker must first obtain low-privileged credentials on the target Sync-in Server. This is required because the POST /api/app/sync/operation/diff/:id endpoint requires authentication. Once authenticated, the attacker obtains an authorization header or cookie.

The attacker then maps or identifies an existing workspace ID (:id) or creates a directory to synchronize. The exploitation payload contains a classic catastrophic backtracking pattern, such as ^(a+)+b, embedded inside the pathFilters parameter of the sync request.

POST /api/app/sync/operation/diff/workspace-123 HTTP/1.1
Host: target-server.local
Authorization: Bearer <valid_low_privileged_token>
Content-Type: application/json
 
{
  "secureDiff": false,
  "pathFilters": "^(a+)+b"
}

When this payload is submitted, the backend compiles the pattern. During the synchronization phase, the engine attempts to match this pattern against directory files containing long strings of 'a' characters (such as aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.txt). Because the string ends in .txt instead of b, the regex engine fails to match. The nested quantifiers force the engine to calculate billions of potential matching states, locking up the CPU and preventing the application from handling further operations.

The CVSS base score of 6.5 reflects a high availability impact with low exploit complexity. Because the server completely stops responding to requests, external reverse proxies or load balancers typically drop connections with gateway timeouts (HTTP 504).

The denial of service state persists as long as the V8 thread continues to compute the permutations. Because there is no default execution timeout for native RegExp.prototype.test() operations in JavaScript, the application remains unresponsive until the process is manually killed or restarted by an orchestrator like Docker or Kubernetes.

This vulnerability does not directly expose files or allow arbitrary code execution. However, the resulting outage can disrupt operational workflows. This makes it an effective tool for attackers seeking to degrade infrastructure during coordinated multi-stage incidents.

The primary remediation step is to update the Sync-in Server installation to version 2.4.0 or later. This ensures the transformPathFilters security layer is integrated into the validation cycle of the application.

For systems where immediate upgrades are not possible, administrators should deploy Web Application Firewall (WAF) rules. These rules should inspect the body of requests destined for /api/app/sync/operation/diff/ to block known catastrophic backtracking regex signatures (such as nested repeating groups containing wildcard symbols).

To prevent regressions, developers should add defensive unit tests to the CI/CD pipeline. These tests should verify that the application properly handles both malicious and excessively long regular expression strings.

it('rejects unsafe regular expressions with an explicit error', () => {
  const runValidation = () => transformPathFilters('^(a+)+b')
  expect(runValidation).toThrow(BadRequestException)
  expect(runValidation).toThrow('Unsafe path filter pattern')
})