CVE-2026-53726: Authorization Bypass in Parse Server Relation Queries ($relatedTo)

Parse Server is an open-source, highly customizable backend framework deployed on Node.js. It facilitates data storage, authentication, and push notifications through an API layer. The platform relies on a schema system featuring Classes, Pointers, and Relations to define associations between data objects. Object-level security is governed by Access Control Lists (ACLs) and Class-Level Permissions (CLPs), which dictate which client roles can read or write specific records.

A fundamental feature of Parse Server is the $relatedTo query operator, which allows clients to retrieve objects associated with a specific parent object through a defined relation field. The vulnerability designated as CVE-2026-53726 represents an authorization bypass within this operator's logic. It resides within the relational resolution process of DatabaseController.js, where queries targeting relational child entities fail to evaluate the authorization state of the parent entity.

By exploiting this failure, an unauthenticated remote attacker can query relation memberships despite the presence of restrictive access controls. If an application utilizes protectedFields or object-level ACLs to keep relation structures private, this flaw completely neutralizes those protections. The attack surface is exposed via standard public REST API endpoints, meaning no authenticated session or administrative privilege is required to execute the exploit.

The root cause of CVE-2026-53726 lies in the asymmetrical implementation of security controls between parent and child objects during query resolution. When Parse Server processes a query targeting a child class with a $relatedTo constraint, the engine inspects permissions associated with the child collection. However, the system fails to check whether the client possesses authorization to read the parent object or access the specific relation field.

The query processing pipeline within DatabaseController.js handles $relatedTo by invoking the relatedIds method. This method executes direct queries against the underlying database join tables to resolve the exact IDs of linked objects. Because this resolution happens before the query context is passed through Class-Level Permission (CLP) or Access Control List (ACL) filters, the database returns the raw matching identifiers without performing any ownership checks.

Furthermore, the DatabaseController bypasses any configured protectedFields rules of the parent class. In a standard query pipeline, if a developer defines a field as protected, the API layer strips this field from any outgoing payload to prevent unauthorized reading. Because the $relatedTo resolution evaluates the relation at the query level rather than the output level, the engine executes the join operation anyway, completely bypassing the protected designation.

To trigger this vulnerability, an attacker only needs the objectId of the parent object and the name of the relation key. Knowing or guessing these values allows the attacker to instruct Parse Server to query the join table on their behalf. The database engine returns the array of child IDs to the reduceRelationKeys method, which then mutates the original query to target those resolved child IDs, returning the data directly to the client.

In vulnerable versions of Parse Server, the reduceRelationKeys method in src/Controllers/DatabaseController.js processes logical operators ($or and $and) recursively, but extracts $relatedTo without any authentication checks. The system directly resolves relation identifiers and replaces the $relatedTo object with an array of corresponding child object IDs using this.addInObjectIdsIds(ids, query). This process relies solely on the parameters passed from the client without checking client rights.

The official patch restructures reduceRelationKeys to accept authentication parameters, including the user's auth state, ACL groups, master key flag, and schema controller. These values are forwarded to a newly introduced helper method named authorizeRelatedToQuery. This validation function intercepts the $relatedTo payload before calling this.relatedIds and determines whether the client has the necessary authorization to perform the query.

Inside authorizeRelatedToQuery, two primary security checks are enforced. First, the function checks the schema configuration of the owning class to verify if the requested relation key is listed as a protected field for the current auth context. If the field is protected, the function throws an OPERATION_FORBIDDEN error. Second, it attempts to fetch the owning parent object using the client's credentials. If the search returns no results or throws an access-denied error, the query returns an empty array, neutralizing the data leak.

Let us examine the diff of the patched implementation of reduceRelationKeys showing how the authorization check was added to secure the query execution pipeline:

// Patched Implementation of reduceRelationKeys inside DatabaseController.js
reduceRelationKeys(
  className: string,
  query: any,
  queryOptions: any,
  auth: any = {},
  aclGroup: any[] = [],
  isMaster: boolean = false,
  schemaController: ?SchemaController.SchemaController
): ?Promise<void> {
  // Recursive handling updated to pass auth, aclGroup, isMaster, and schemaController
  // Support added for recursive $nor array validation to enforce logical grouping boundaries
  var relatedTo = query['$relatedTo'];
  if (relatedTo) {
    return this.authorizeRelatedToQuery(relatedTo, auth, aclGroup, isMaster, schemaController)
      .then(canReadOwningObject => {
        delete query['$relatedTo'];
        if (!canReadOwningObject) {
          // The caller is not allowed to read the owning object, return no results
          this.addInObjectIdsIds([], query);
          return this.reduceRelationKeys(className, query, queryOptions, auth, aclGroup, isMaster, schemaController);
        }
        return this.relatedIds(relatedTo.object.className, relatedTo.key, relatedTo.object.objectId, queryOptions)
          .then(ids => {
            this.addInObjectIdsIds(ids, query);
            return this.reduceRelationKeys(className, query, queryOptions, auth, aclGroup, isMaster, schemaController);
          });
      });
  }
}

Exploiting CVE-2026-53726 requires minimal prerequisites. An attacker only needs the target Parse application ID and client/REST API keys, which are typically hardcoded into client-side mobile applications or single-page web apps. Using these credentials, the attacker crafts an HTTP request targeting the child class and inserts the $relatedTo operator inside the where parameter.

In a Relation Member Enumeration attack, the attacker constructs a query designed to extract all elements linked to a specific parent. For example, if a developer maintains a private parent class Group containing a relation key members linked to the User class, the attacker targets the User collection. By supplying a pointer to a specific Group record with the members key inside the $relatedTo object, the server returns all associated users, bypassing group-level privacy settings.

A Membership Oracle Attack represents a more targeted exploitation mechanism. Instead of attempting to list all members, the attacker adds an explicit objectId constraint referencing a specific target child record in addition to the $relatedTo query. The server processes this query and, if the target object is linked to the parent, returns the single matching record. If there is no link, the server returns an empty results list, allowing systematic brute-forcing of sensitive relationships.

Below is an example of an HTTP request showcasing a Membership Oracle Attack targeting a protected relation on a private parent object:

GET /parse/classes/RelChild?where=%7B%22%24relatedTo%22%3A%7B%22object%22%3A%7B%22__type%22%3A%22Pointer%22%2C%22className%22%3A%22RelParent%22%2C%22objectId%22%3A%22PRIVATE_PARENT_ID%22%7D%2C%22key%22%3A%22secretRel%22%7D%2C%22objectId%22%3A%22TARGET_CHILD_ID%22%7D HTTP/1.1
Host: vulnerable-parse-server.local
X-Parse-Application-Id: your_app_id
X-Parse-REST-API-Key: your_public_rest_key
Content-Type: application/json

The security impact of CVE-2026-53726 depends on the relational structure of the affected Parse Server application. In applications that manage confidential relationships—such as private communication rooms, block lists, or account-to-resource assignments—unauthorized visibility into these lists represents a significant breach of confidentiality. Attackers can map out association networks that developers assumed were secured behind robust class-level or object-level permissions.

While the exploit allows a client to verify or extract relation structures, it does not directly expose the full details of the child records if those child records themselves are secured by strict object-level ACLs. However, the exposure of the relation itself, combined with the metadata return of matching child IDs, constitutes a direct leak of relational configuration data, enabling subsequent metadata-driven attack vectors.

The CVSS v4.0 score is rated at 6.9, signifying medium severity. This rating reflects low confidentiality impact on the overall system because full object access remains subject to child-level controls, with no integrity or availability impact. The low attack complexity, lack of privilege requirements, and absence of required user interaction make this vulnerability highly reliable to exploit if target class structures are known.

The following architecture diagram illustrates the contrast between the vulnerable query flow and the patched query verification flow:

The definitive remediation for CVE-2026-53726 is updating Parse Server to a patched version. Deployments running on the 8.x release branch must be upgraded to version 8.6.80 or above. Deployments running on the newer 9.x release branch must update to version 9.9.1-alpha.6 or later. Upgrading immediately ensures that both schema validations and parent ACL evaluations are enforced natively during query reduction.

If an immediate patch deployment is not feasible due to integration cycles, administrators can apply defensive measures via Parse Cloud Code. Developers can implement a beforeFind hook on target child classes to intercept and inspect incoming query parameters. By parsing the query structure for the presence of the $relatedTo operator, the hook can manually execute an ownership check against the parent object before allowing the database query to proceed.

Another architectural workaround involves replacing native Parse Relation fields with an intermediate join class. For example, instead of creating a direct relation field, developers can define a UserGroupMembership class containing pointers to both the parent and child entities. Since this intermediate class behaves as a standard collection, standard Class-Level Permissions (CLPs) and Pointer permissions can be applied directly to secure memberships.

Detection of ongoing exploitation attempts can be achieved through network analysis and log monitoring. Security teams should configure Web Application Firewalls (WAFs) or intrusion detection rules to scan incoming HTTP query parameters for the %24relatedTo key, particularly when targeted at sensitive classes. Analyzing application logs for elevated volumes of distinct queries matching identical $relatedTo structures but varying object IDs can indicate active mapping or membership oracle enumeration.