CVE-2026-105855: Privilege Escalation via Improper Access Control on Password Fields in Payload CMS

Payload CMS is an open-source, full-stack headless content management system built on Next.js and TypeScript. In authentication-enabled collections, the platform automatically manages security fields such as passwords, salts, and email addresses. The system allows developers to define field-level access controls to restrict who can read or update specific attributes within a document.\n\nThe vulnerability designated as CVE-2026-105855 represents an improper access control flaw classified under CWE-284. This flaw permits an authenticated attacker with low-level privileges to modify the password field of any other user in the database. Because the application handles password fields out of sequence during update operations, the security rules designed to protect user passwords are not correctly enforced.\n\nThe impact of this vulnerability is severe, as it facilitates unauthorized account takeovers. By altering the password of an administrator account, a low-privileged attacker can escalate their privileges to the highest level within the CMS. This allows complete administrative access to the underlying data, configuration settings, and associated services.

The root cause of CVE-2026-105855 resides in the document update utility of Payload CMS, specifically within the file packages/payload/src/collections/operations/utilities/update.ts. When processing a document update request, the API executes the updateDocument function to parse incoming data and apply database updates. To handle password hashing and saving, the application must identify whether a password update has been requested.\n\nIn the vulnerable implementation, the application extracted the password field and evaluated the shouldSavePassword boolean flag at the very beginning of the update execution block. This evaluation occurred before the execution of validation hooks and before applying field-level access controls. As a result, the state variable indicating that a password change was pending became locked into memory based on raw, unsanitized user input.\n\nEven though subsequent operations performed the field-level access control checks and correctly stripped the unauthorized password field from the sanitized payload, the persistence mechanism still relied on the early-evaluated shouldSavePassword flag and the cached raw password variable. This architectural logic error allowed the raw password update to bypass the access control system and overwrite the target database record.

The following flowchart illustrates the vulnerable control flow compared to the patched control flow. In the vulnerable version, the password update flag is evaluated prior to access control filtration. In the patched version, the check is deferred until after validation and authorization sanitization have occurred.\n\nmermaid\ngraph LR\n subgraph Vulnerable Flow\n v_input["Raw Payload Input"] --> v_eval["Evaluate shouldSavePassword"]\n v_eval --> v_auth["Run Access Control (Strips Password)"]\n v_auth --> v_write["Write Cached Password to Database"]\n end\n\n subgraph Patched Flow\n p_input["Raw Payload Input"] --> p_auth["Run Access Control (Strips Password)"]\n p_auth --> p_eval["Evaluate shouldSavePassword (Is Undefined)"]\n p_eval --> p_write["Database Write (Password Untouched)"]\n end\n\n\nThe key file affected by this logic error is packages/payload/src/collections/operations/utilities/update.ts. The vulnerable code extracted the password properties prematurely as shown below:\n\ntypescript\n// Vulnerable Code: packages/payload/src/collections/operations/utilities/update.ts\n// Line 101 - Password extracted and flag evaluated prematurely\nconst password = data?.password\n\nconst shouldSavePassword = Boolean(\n password &&\n collectionConfig.auth &&\n (!collectionConfig.auth.disableLocalStrategy ||\n (typeof collectionConfig.auth.disableLocalStrategy === 'object' &&\n collectionConfig.auth.disableLocalStrategy.enableFields)) &&\n !isSavingDraft,\n)\n\n\nThe patch resolved the issue by shifting the extraction of the password and the calculation of shouldSavePassword downstream, placing them after all field-level validation and security filtering have modified the data object:\n\ntypescript\n// Patched Code: packages/payload/src/collections/operations/utilities/update.ts\n// Line 193 - Moved downstream after access control and validation filters\n\nconst password = data?.password\nconst shouldSavePassword = Boolean(\n password &&\n collectionConfig.auth &&\n (!collectionConfig.auth.disableLocalStrategy ||\n (typeof collectionConfig.auth.disableLocalStrategy === 'object' &&\n collectionConfig.auth.disableLocalStrategy.enableFields)) &&\n !isSavingDraft,\n)\n\n\nThis simple repositioning guarantees that if the security parser strips the unauthorized password property from the data object, the variable password evaluates to undefined, and shouldSavePassword is set to false. The fix is complete and structurally sound as it aligns property evaluation with the output of the access control pipeline.

An attacker must obtain a valid, authenticated session with low-level privileges to exploit this vulnerability. The target of the attack is typically an administrative user account or another high-privileged document within an authentication-enabled collection. The attacker must know or discover the target account's unique identifier (ID) within the collection.\n\nThe exploitation begins when the attacker sends a standard document update request, such as an HTTP PATCH request, to the collection endpoint /api/users/{victim-id}. In the JSON body of this request, the attacker includes the password field populated with a new password value of their choice. No other administrative fields or parameters are required to trigger the vulnerability.\n\nUpon receiving the request, the unpatched server parses the incoming JSON, stores the attacker's password value, and establishes the internal update directive. Although the authorization middleware determines that the low-privileged attacker lacks permission to update this field and removes it from the safe data object, the server still proceeds to overwrite the database password record. The victim account is successfully compromised, permitting immediate login by the attacker.

The impact of CVE-2026-105855 is classified as high because it leads to unauthorized access and complete account compromise. An attacker who successfully takes over an administrator account gains full control over the Payload CMS application. This administrative access permits the attacker to read, alter, or delete any content, configurations, and user credentials stored in the system.\n\nUnder the CVSS v4.0 standard, this vulnerability receives a score of 7.6. The vector string is CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N. This indicates a network-based attack vector with low complexity, requiring low privileges and no user interaction, but yielding high confidentiality and integrity impact on the vulnerable system.\n\nCurrently, this vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and there is no evidence of active exploitation in the wild. However, because the exploit requires only a standard API request and low-level credentials, the likelihood of successful exploitation remains high for unpatched installations.

The primary remediation for this vulnerability is to upgrade the Payload CMS dependency to a secure release. Organizations running stable deployments must update the payload package to version 3.90.0 or later. Organizations using development or canary releases must upgrade to version 4.0.0-canary.34 or later.\n\nIf an immediate upgrade is not feasible, organizations can implement detection rules and temporary controls. Security teams should monitor web application firewalls and server logs for unauthorized PATCH or PUT requests sent to the authentication endpoints of collections where the target ID does not match the requester's ID. Any update request containing a password payload targeting another user's identifier should be flagged as suspicious.\n\nDevelopers should also audit their collection configurations to ensure that the password field is not inadvertently exposed or misconfigured. Running automated integration tests that verify password preservation when unauthorized update attempts are made can prevent regressions. Implementing database-level triggers to track changes on password hash columns can also provide an audit trail of potential compromise.