CVE-2026-105845: SQL Injection and Access Control Bypass in Payload CMS Adapters via Case-Sensitivity Flaws and Sorting

The vulnerability CVE-2026-105845 affects the open-source headless Content Management System Payload CMS. It specifically resides within the query validation layers and affects both the SQLite and PostgreSQL adapters which rely internally on Drizzle ORM for database abstraction. The primary role of the query validation layer is to restrict API queries according to the access control permissions defined for specific collections, globals, and individual fields. When users specify dynamic filters on endpoints, the validation layer is responsible for inspecting the query paths and ensuring that the requesting entity holds sufficient read privileges for every field referenced.

This vulnerability undermines these access restrictions by presenting two distinct vectors. First, the query path validation algorithm fails to identify and recursively validate nested logical constraints if they are defined with mixed-case or uppercase logical operators. Second, query sorting parameter parsing fails to evaluate field-level read permissions, permitting attackers to sort results based on values inside hidden or restricted fields. The exploitation of these issues does not require administrative rights or victim interaction, creating a wide attack surface for deployments with exposed public-facing endpoints.

By combining the logical operator case bypass and the unauthenticated sorting parameter vulnerability, an attacker can construct queries that leak arbitrary database fields. This results in complete exposure of the backend data model. Systems running affected versions of Payload CMS are highly susceptible to unauthorized data exfiltration, including user credentials, API tokens, and internal configuration details.

The core of the access control bypass in validateQueryPaths.ts lies in the strict string comparison used to identify logical operators. In the vulnerable implementation, the query validator specifically checked if the current path exactly matched the lowercase strings 'and' or 'or' prior to executing recursive checks on nested arrays of conditions. This logic did not utilize case-insensitive comparison or string normalization. Consequently, when an operator such as 'AND', 'OR', or 'And' was provided, the conditional path check evaluated to false, skipping the nested validation block entirely.

Because the logical operator path check evaluated to false, the query path processor fell back to alternative check branches. The processor encountered a branch that evaluated single field constraints but required the constraint to not be an array. Since logical conditions are formatted as arrays of criteria, this check also evaluated to false. As a result, the validator terminated processing of the operator sub-tree without pushing any validation errors to the error collector, rendering the nested constraint implicitly valid.

Once the validator successfully bypassed verification of the query, the raw query tree was forwarded to the query execution engine. The underlying database adapters, which utilize Drizzle ORM, parse dynamic query parameters in a case-insensitive manner. Drizzle ORM correctly interprets 'AND' and 'OR' as logical operators, resulting in the direct generation of SQL statements containing the unvalidated nested constraints. Consequently, the database executes instructions containing criteria referencing fields that the user does not have permission to view.

To understand the patch, we examine the logic within validateQueryPaths.ts before and after the security update. The vulnerable code restricted its matching criteria to lowercase literals, failing to capture alternate casings. In addition, the parser lacked a catch-all mechanism to reject unvalidated arrays that failed to match the defined logical operator structure, leaving a logic gap that allowed nested structures to bypass verification entirely.

// Vulnerable Code Path
if ((path === 'and' || path === 'or') && Array.isArray(constraint)) {
  for (const item of constraint) {
    if (collectionConfig) {
      promises.push(
        validateQueryPaths({
          // ... recursive validation parameters
        })
      )
    }
  }
}

The remediation applied in commit a742140ab4fca3160f7f83e9e7d996552ffc3b5a introduces string normalization and a strict validation fallback. The modified logic converts the query path to lowercase using .toLowerCase() before evaluating whether it is a logical operator. Crucially, the patch also introduces an explicit else if (Array.isArray(constraint)) block. If an array is passed that does not match a valid logical operator, the validator now flags this as an error and rejects the query, preventing arbitrary arrays from bypassing validation.

// Patched Code Path
if (['and', 'or'].includes(path.toLowerCase()) && Array.isArray(constraint)) {
  for (const item of constraint) {
    if (collectionConfig) {
      promises.push(
        validateQueryPaths({
          // ... recursive validation parameters
        })
      )
    }
  }
} else if (Array.isArray(constraint)) {
  errors.push({ path })
}

Exploitation of CVE-2026-105845 relies on exploiting the differences between the casing assumptions of the validation engine and the query compiler. Under normal operation, a query to a protected field such as secretHash would be rejected by Payload's validation engine. An attacker can circumvent this protection by nesting the restricted path within a capitalized AND array parameter, which disables validation processing for that branch.

An attacker sends a crafted request containing the capitalized filter query:

GET /api/posts?where[AND][0][secretHash][equals]=target_value HTTP/1.1
Host: vulnerable-app.local

The validation engine skips the nested array check, and the query is passed directly to the database. If a record matching the condition exists, the application returns a standard record representation, thereby confirming the existence of the specific value.

Another primary exploitation mechanism targets the unvalidated sorting mechanism. Database systems execute sorting operations prior to the serialization and sanitization phase of the API response. An attacker can supply a sort parameter referencing a restricted field such as apiKey or resetToken. By observing the sequential ordering of the returned public list across multiple requests, the attacker can systematically deduce the values of the restricted field through a binary search side-channel.

The security implications of this vulnerability are classified as critical, as indicated by its CVSS base score of 9.8. Exploitation can be achieved remotely without prior authentication, provided that the targeted API collection has query operations publicly enabled. Even in configurations where collections require authentication, any user with minimal API privileges can execute these queries to elevate their access or view restricted columns.

The impact on confidentiality is high. Attackers can read sensitive columns including password hashes, session identifiers, reset tokens, and system configurations. By leveraging the blind sorting side-channel, sensitive strings can be exfiltrated character-by-character over the network. This completely bypasses the column-level access controls designed to secure multi-tenant or multi-role environments.

The impact on integrity and availability depends heavily on the specific database engine and underlying configuration. In environments utilizing PostgreSQL, the potential exists to inject more complex SQL fragments or trigger heavy computational queries, leading to denial of service. The potential for data modification or deletion exists if the underlying database driver configuration permits multi-statement execution, although the primary vector demonstrated relies heavily on read-based blind exfiltration.

The definitive solution for CVE-2026-105845 is to upgrade the Payload CMS dependencies to the designated patched releases. Organizations deploying Payload CMS version 3 must upgrade to version 3.88.0 or higher. For teams leveraging the 4.x prerelease branch, the patch is integrated within version 4.0.0-canary.27 and all subsequent canary or stable releases. Upgrades can be performed using standard package managers.

For environments where immediate upgrading is not possible, temporary mitigations should be applied at the network or reverse proxy layer. Web Application Firewalls (WAFs) should be configured with custom inspection rules designed to detect and block incoming request parameters that contain logical operator keys with uppercase or mixed-case characters inside query strings, such as where[AND], where[Or], or where[OR].

Additionally, database adapters should be configured with the least-privilege principle. Database connection strings used by the CMS should utilize users restricted to necessary database tables, with administrative tables completely isolated. Developers are advised to audit custom collection configurations to ensure that public query permissions are disabled for collections hosting sensitive information unless strictly required by business logic.