CVE-2026-105859 in Payload
Summary
by MITRE • 10/06/2026
Payload is a free and open source headless content management system. In versions before 3.90.0 and canary versions before 4.0.0-canary.34, an attacker can submit a request to a specific update endpoint that modifies collection documents without enforcing collection or field-level access control when orderable is enabled on a collection or join field. This issue is fixed in versions 3.90.0 and 4.0.0-canary.34.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/06/2026
Payload CMS, a popular open-source headless content management system built for Node.js, suffered from an authorization bypass vulnerability affecting specific releases prior to version 3.90.0 and canary versions before 4.0.0-canary.34. The core of the issue lies in how the application handles document updates when certain configuration options are enabled within collection schemas or join fields. Specifically, when a collection is configured with orderable capabilities or utilizes specific field types that support ordering mechanisms, the underlying logic for processing update requests fails to properly validate user permissions against the target resource. This architectural flaw allows an authenticated attacker who possesses minimal privileges, such as the ability to create documents in other collections, to manipulate and reorder existing documents within a protected collection without holding the necessary read or write access rights themselves.
The technical mechanism of this vulnerability exploits the separation between data retrieval logic and permission enforcement during update operations. In standard CMS workflows, updating an orderable list typically requires verifying that the user has explicit permissions for each document being reordered. However, in the affected versions, the endpoint responsible for handling these bulk or sequential updates bypasses the granular access control checks at both the collection level and the individual field level. This oversight means that once a request is authenticated, the system trusts the input data regarding which documents to update and their new positions without cross-referencing them against the user's role-based permissions defined in the Payload configuration. Consequently, an attacker can submit crafted HTTP requests to reorder or modify document structures within collections they are not authorized to access, effectively circumventing the intended security boundaries of the application.
From a risk perspective, this vulnerability represents a significant breach of integrity and confidentiality principles depending on the sensitivity of the data stored in the affected collections. By allowing unauthorized users to alter the order or content of documents, an attacker can disrupt business logic that relies on specific ordering, such as featured articles, product listings, or administrative dashboards. Furthermore, if the update operation inadvertently exposes sensitive fields during the reordering process due to how the database query is constructed under these conditions, it could lead to information disclosure. This aligns with CWE-269, which describes Improper Privilege Management, where a user can perform actions that exceed their assigned privileges. Additionally, this behavior maps to MITRE ATT&CK techniques related to privilege escalation and lateral movement within the application layer, as an attacker leverages existing low-level access to gain unauthorized control over higher-value resources.
To mitigate this vulnerability, organizations running Payload CMS must immediately upgrade to version 3.90.0 or later, which includes patches for canary versions starting from 4.0.0-canary.34. These updates enforce strict validation of collection and field-level access controls during update operations involving orderable fields. For environments where an immediate upgrade is not feasible due to dependency constraints, administrators should consider implementing reverse proxy rules or WAF policies that restrict access to the specific vulnerable endpoints unless explicitly required by authorized roles. Additionally, reviewing custom API routes and extensions for similar patterns of insufficient authorization checks is recommended to ensure comprehensive security posture across all application components. Regular auditing of user permissions and minimizing the use of orderable features on highly sensitive collections can also serve as effective defense-in-depth strategies while waiting for patch deployment.