CVE-2026-30835: Database Metadata Leak via Malformed Regex in Parse Server

Parse Server provides a flexible REST API that automatically maps HTTP requests to database queries, supporting complex filtering operations including regular expressions ($regex). The vulnerability, identified as CVE-2026-30835, resides in the exception handling logic of the DatabaseController. When a client submits a query containing a syntactically invalid regular expression—such as an unclosed bracket or parenthesis—the underlying database driver (typically MongoDB) throws a structured error object containing detailed diagnostic information.

In affected versions, the server catches this database exception but fails to sanitize it before serializing the response to the client. The application wraps the raw database error in a Parse.Error object and re-throws it, which the API layer then converts to JSON. This behavior violates the principle of fail-safe defaults by exposing implementation details that should remain opaque to the client. The leaked information includes specific MongoDB error codes, cluster operation timestamps ($clusterTime), and topology data.

While this vulnerability does not directly permit arbitrary code execution or data modification, it is classified as a medium-severity information disclosure (CWE-209). The exposed metadata provides attackers with high-fidelity fingerprints of the backend infrastructure. This reconnaissance data significantly aids in identifying the specific database version, driver behavior, and cluster configuration, potentially facilitating targeted exploit development against the database layer.

The root cause of this vulnerability is the improper handling of upstream errors within the DatabaseController.js module. In the Parse Server architecture, the controller acts as an intermediary between the REST API adapters and the database storage adapters. When a query is executed, the controller awaits the promise returned by the storage adapter. Ideally, any rejection from the storage layer should be caught, logged internally, and transformed into a generic, safe error message for the client.

However, in the vulnerable code path, the catch block simply encapsulated the entire error object returned by the database driver into a Parse.Error.INTERNAL_SERVER_ERROR. The code did not verify whether the error object contained sensitive properties. Since Parse Server's error serialization logic iterates over enumerable properties of the error object to construct the JSON response, the rich metadata provided by modern database drivers—intended for server-side debugging—was inadvertently passed through to the HTTP response body.

Specifically, MongoDB drivers return objects that include fields such as codeName, errmsg, errorResponse, and $clusterTime. The $clusterTime field, for example, contains a signed timestamp used for synchronization in replica sets and sharded clusters. By re-throwing the raw error, Parse Server bypassed its own sanitization mechanisms, treating the database exception as a standard application error rather than a sensitive infrastructure failure.

The vulnerability exists in the query execution flow within src/Controllers/DatabaseController.js. The following analysis highlights the insecure error propagation and the subsequent patch applied in version 8.6.7.

Vulnerable Code (Pre-Patch): In the vulnerable version, the catch block directly instantiates a Parse.Error using the raw error object. This object often contains the full context from the database driver.

// src/Controllers/DatabaseController.js (Vulnerable)
return this.adapter.find(className, schema, query, options)
  .then(results => {
    // ... processing results ...
  })
  .catch(error => {
    // CRITICAL: The raw 'error' object is passed directly to the client response.
    throw new Parse.Error(Parse.Error.INTERNAL_SERVER_ERROR, error);
  });

Patched Code (Fixed): The fix introduces a check to determine if the error is already a safe Parse.Error. If not, it sanitizes the output using createSanitizedError (or similar logic depending on the branch), ensuring that only a generic message is returned unless specific debug flags are enabled.

// src/Controllers/DatabaseController.js (Patched)
return this.adapter.find(className, schema, query, options)
  .then(results => {
    // ... processing results ...
  })
  .catch(error => {
    // Check if it's already a known Parse error
    if (error instanceof Parse.Error) {
      throw error;
    }
    // If it's a raw DB error, sanitize it.
    // The sanitized message defaults to 'An internal server error occurred'
    // or a specific message if deemed safe.
    const detailedMessage = typeof error === 'string' ? error : error?.message || 'An internal server error occurred';
    throw createSanitizedError(
      Parse.Error.INTERNAL_SERVER_ERROR,
      detailedMessage,
      this.options,
      'An internal server error occurred' // The safe message sent to client
    );
  });

The createSanitizedError utility respects the enableSanitizedErrorResponse configuration. When this configuration is standard (default), the client receives the generic "An internal server error occurred" string, while the detailed error is logged server-side.

Exploiting this vulnerability requires no authentication if the Parse Server exposes any public read-access collections. The attacker merely needs to send a request with a where clause containing a malformed regular expression. The most reliable method is to open a character class or capturing group without closing it, forcing a compilation error in the database engine.

Attack Scenario: The attacker targets a standard collection endpoint, such as /classes/Users or /classes/TestObject. They inject a JSON object into the where parameter specifying a field and a $regex operator with an invalid pattern like [abc.

GET /1/classes/TestObject?where=%7B%22field%22%3A%7B%22%24regex%22%3A%22%5Babc%22%7D%7D HTTP/1.1
Host: parse-server.example.com
X-Parse-Application-Id: <AppID>

Vulnerable Response Analysis: The server responds with HTTP 500, but the body contains the leaked data. A standard response might look like this:

{
  "code": 1,
  "error": {
    "message": "Regular expression is invalid: [abc",
    "code": 51091,
    "codeName": "Location51091",
    "errorResponse": {
      "ok": 0,
      "errmsg": "Regular expression is invalid: [abc",
      "code": 51091,
      "$clusterTime": {
        "clusterTime": "734458...",
        "signature": { ... }
      },
      "operationTime": "734458..."
    }
  }
}

The presence of $clusterTime confirms the backend is a MongoDB cluster (likely Replica Set or Sharded). The specific code (51091) maps to MongoDB source code locations, allowing precise version fingerprinting.

The primary impact of CVE-2026-30835 is the leakage of technical metadata, classified as a confidentiality violation. The severity is assessed as Medium (CVSS 6.9). While the vulnerability does not expose customer PII or credentials directly, the leaked infrastructure data allows attackers to build a precise map of the backend environment.

Technical Leakage:

• Database Topology: The errorResponse object reveals if the database is running as a standalone instance, a replica set, or a sharded cluster.
• Version Fingerprinting: Specific error codes and the structure of the errorResponse object can be correlated with specific MongoDB versions.
• Operational Metrics: The $clusterTime and operationTime fields expose internal clock values, which can theoretically be used in advanced race condition attacks or to synchronize distributed attacks.

Security Implications: This information disclosure significantly lowers the barrier for subsequent attacks. Knowing the exact database version allows an attacker to search for specific unpatched CVEs in the database layer. Furthermore, verifying that the input reaches the database driver raw confirms that the application lacks comprehensive input validation layers, encouraging attackers to probe for other injection vulnerabilities (NoSQLi).

The vulnerability is addressed in Parse Server versions 8.6.7 and 9.5.0-alpha.6. Administrators should upgrade to these versions immediately. The patch modifies the DatabaseController to intercept raw database errors and replace them with generic error messages before response serialization.

Upgrade Path:

• v8.x users: Update to parse-server@8.6.7 or later.
• v9.x users: Update to parse-server@9.5.0-alpha.6 or later.

Configuration Review: Post-update, ensure that the enableSanitizedErrorResponse option is not explicitly set to false. While the patch forces sanitization for this specific error path, maintaining this setting as true (default) is best practice for production environments to prevent similar leaks in other parts of the application. Developers attempting to debug these errors should rely on server-side logs rather than API responses.

Network Defense: As a defense-in-depth measure, Web Application Firewalls (WAF) can be configured to inspect the where query parameter. Rules can be created to block requests containing known invalid regex patterns (e.g., unclosed brackets [ or parentheses () before they reach the Parse Server application logic.