CVE-2026-105805: Sorting-Based Side-Channel Information Disclosure in Payload CMS

Payload CMS is an open-source headless content management system. Within its architecture, developers define fields and associate access control rules to restrict sensitive properties (e.g., boolean flags, system tokens, hashed password strings) from public read access.

This security control is bypassed in vulnerable versions because database queries execute sorting logic on the raw, unredacted records prior to the application of field-level authorization and redaction logic.

An attacker with read access to a collection can exploit this behavioral sequence to construct a sorting-based side-channel (also called a sorting oracle). By passing custom sort parameters targeting restricted fields and analyzing the order of returned records, the attacker can infer hidden values.

The underlying technical flaw stems from incorrect authorization evaluation (CWE-863) combined with sensitive information exposure (CWE-200) within the query parsing logic of the CMS database adapters (such as MongoDB or Drizzle-managed SQL).

The processing sequence for collection query REST requests is structured as follows:

1. The API endpoint receives query parameters, including the user-specified sort argument.
2. The server translates this argument directly into a native database sorting directive and executes the query.
3. The database returns the sorted, raw result set to the application backend.
4. The application processes the records, evaluating field-level read permissions and stripping out values for which the requesting user lacks authorization.
5. The sanitized JSON array is returned to the client.

Because database-level sorting occurs before post-query authorization redaction, the physical ordering of the document objects returned in the client response is determined by the values of the unauthorized fields. Although the JSON payload excludes the actual values, the structured position of the records reveals the comparative values of the hidden properties.

The vulnerability was resolved in commit a742140ab4fca3160f7f83e9e7d996552ffc3b5a by introducing a validation process called validateSortQuery.ts within the database query validation pipeline.

This validator maps the specified sorting fields to a temporary Where constraint structure and executes standard query validation logic against them. This ensures that a client cannot execute queries using sort parameters that reference fields they do not have the authorization to filter by.

// packages/payload/src/database/queryValidation/validateSortQuery.ts
import { validateQueryPaths } from './validateQueryPaths.js'
 
export const validateSortQuery = async ({
  collectionConfig,
  globalConfig,
  overrideAccess,
  req,
  sort,
  versionFields,
}: Args): Promise<void> => {
  if (overrideAccess || !sort) {
    return
  }
 
  const fields = versionFields || (globalConfig || collectionConfig).flattenedFields
  const sortFields = Array.isArray(sort) ? sort : [sort]
  const where: Where = {}
 
  for (const sortField of sortFields) {
    // Normalize sort arguments by stripping descending indicators and nested qualifiers
    const path = sortField.replace(/^-/, '').replace(/__/g, '.')
    const paths = getLocalizedPaths({
      collectionSlug: collectionConfig?.slug,
      fields,
      globalSlug: globalConfig?.slug,
      incomingPath: path,
      locale: req.locale!,
      overrideAccess: true,
      payload: req.payload,
    })
 
    if (path !== 'id' && path !== '_id' && paths.every(({ invalid }) => !invalid)) {
      where[path] = { exists: true }
    }
  }
 
  if (Object.keys(where).length === 0) {
    return
  }
 
  // Execute permissions check as if the client queried these paths directly in a filter
  if (collectionConfig) {
    await validateQueryPaths({
      collectionConfig,
      overrideAccess,
      req,
      versionFields,
      where,
    })
  } else {
    await validateQueryPaths({
      globalConfig,
      overrideAccess,
      req,
      versionFields,
      where,
    })
  }
}

This validator was integrated directly into find, findDistinct, findVersions, and update operation controllers. By routing the normalized sorting path into validateQueryPaths, the core permissions layer verifies if the requesting identity holds read capabilities on the field. If they do not, the application aborts the database transaction and responds with a validation error.

Exploiting this side-channel does not require system access or write capabilities. The attacker only needs access to a publicly queryable endpoint where custom sorting parameters are accepted.

To identify boolean-based hidden administrative flags (such as an isAdmin flag on a public profile list):

1. The attacker queries the users collection sorted by the hidden parameter in ascending order: GET /api/users?sort=isAdmin The application returns the user objects sorted so that false (0) values appear at the beginning of the list, followed by true (1) values. The values of the isAdmin key are stripped.
2. The attacker queries the collection sorted in descending order: GET /api/users?sort=-isAdmin This query forces true values to the top, and false values to the bottom.
3. By comparing the relative positions of user IDs between the ascending and descending responses, the attacker identifies which specific records are assigned true versus false flags.

For alphanumeric secrets (e.g., reset tokens, keys), attackers can construct iterative binary search algorithms. By comparing the sorted positions of target documents against lexicographically known dummy records, they can systematically reconstruct sensitive data strings character by character.

The security impact of CVE-2026-105805 is categorized as medium (CVSS 6.9). The primary impact is unauthorized disclosure of sensitive parameters stored in databases. Attackers can leak restricted configuration flags, reset tokens, or backend attributes that are meant to be restricted.

Because this vulnerability resides in the core query processing structure of Payload CMS, it is widespread across any customized schemas that enforce field-level security while exposing custom client-defined sorting endpoints.

There is no recorded instance of active exploitation in the wild, and public weaponized exploit tools targeting this CVE have not been released. However, due to the logical simplicity of implementing sorting-based side-channel analyses, the exploitability potential is high.

The definitive fix for this vulnerability is upgrading the application to a patched version. Upgrade dependencies to version 3.88.0 or later, or version 4.0.0-canary.27 or later if using the canary release branch.

# Upgrade Payload CMS using npm
npm install payload@3.88.0

For systems where immediate updating is blocked, developers can implement Express-level parameter sanitization middleware. This middleware intercepts query payloads and strips out forbidden sort criteria before the query parameters reach the database adapter operation layer:

app.use('/api', (req, res, next) => {
  if (req.query && typeof req.query.sort === 'string') {
    const restrictedFields = ['password', 'resetToken', 'isAdmin', 'apiKey'];
    const normalizedPath = req.query.sort.replace(/^-/, '');
    
    if (restrictedFields.includes(normalizedPath)) {
      return res.status(403).json({
        error: 'Forbidden sorting parameter requested'
      });
    }
  }
  next();
});

Security teams should configure logging and alert rules on Web Application Firewalls (WAF) to detect successive requests featuring ascending and descending queries on the same schema fields, as this is a standard indicator of an automated extraction script mapping the sorting side-channel.