CVE-2026-105855: 
JavaScript vulnerability analysis and mitigation

CVE-2026-105855 is an improper access control vulnerability in Payload CMS, an open-source headless content management system, where field-level access.update restrictions on the password field of authentication collections are not enforced server-side. This allows a low-privileged authenticated attacker to update another user's password despite explicit restrictions being configured. Affected versions include all releases before 3.90.0 and canary releases from 4.0.0-canary.0 through 4.0.0-canary.33. The vulnerability was published on September 18, 2026, and carries a CVSS v4.0 base score of 7.6 (High) (GitHub Advisory, Payload Security Advisory).

The root cause is classified as CWE-284 (Improper Access Control). In the vulnerable code path within packages/payload/src/collections/operations/utilities/update.ts, the password field extraction and the shouldSavePassword logic were evaluated before field-level access control checks were applied, meaning the server would process and persist a new password even when the collection's access.update restriction on the password field denied the requesting user permission. The fix (commit 9de9e79) moves the password extraction and shouldSavePassword evaluation to occur after access control checks are enforced, ensuring the restriction is respected. Exploitation requires the attacker to hold a valid low-privilege account within the same auth collection and that the target collection has a field-level access.update restriction configured on the password field (Payload Security Advisory, Fix Commit).

Successful exploitation allows an authenticated low-privileged attacker to overwrite another user's password, effectively taking over that account regardless of the field-level access restrictions configured by the application developer. This compromises both confidentiality (attacker gains access to the victim's account and its data) and integrity (unauthorized modification of authentication credentials). Availability is not directly impacted, but account takeover could enable lateral movement within the CMS, escalation to administrative accounts, and unauthorized access to managed content or sensitive application data (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the advisory date. The EPSS score is 0.0, and the NVD SSVC assessment indicates exploitation is "none" and the vulnerability is not automatable. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires a low-privilege authenticated account, which limits the attack surface compared to unauthenticated vulnerabilities, but the impact upon successful exploitation is significant (GitHub Advisory, Feedly).

1. Obtain a low-privilege account: Register or obtain credentials for a low-privilege user account within the target Payload CMS auth collection (e.g., a standard "user" role).
2. Identify the target: Determine the ID of the user account whose password you wish to change (e.g., an admin or another user), using the Payload REST API or admin UI if accessible.
3. Send a crafted update request: Issue an authenticated HTTP PATCH/PUT request to the Payload REST API endpoint for the auth collection (e.g., PATCH /api/users/<target-id>), including a password field in the request body with the desired replacement password, using your low-privilege session token.
4. Bypass access restriction: Due to the vulnerability, the server processes and saves the new password before evaluating the field-level access.update restriction, so the password is updated despite the restriction.
5. Log in as the victim: Use the target user's email and the newly set password to authenticate, achieving account takeover (Payload Security Advisory, Fix Commit).

• Network: Unexpected PATCH or PUT requests to /api/<auth-collection>/<user-id> endpoints containing a password field, originating from low-privilege user sessions targeting other users' IDs.
• Logs: Payload application logs showing successful document update operations on auth collection records where the requesting user is not the record owner and the update payload includes a password field; subsequent login events for a user from an unfamiliar IP or session shortly after such an update.
• Authentication Events: Login success events for a user account immediately following an update request to that account's record by a different user, especially if the original account owner did not initiate a password change.

Users should upgrade the payload npm package to version 3.90.0 or later (stable), or 4.0.0-canary.34 or later (canary). No configuration-based workaround is available; the only remediation is upgrading to a patched version. After upgrading, users should regenerate Payload types (pnpm payload generate:types) and, if using a relational database, run the provided migrations as described in the v3.90.0 release notes (Payload Release v3.90.0, GitHub Advisory).

The v3.90.0 release notes from the Payload CMS maintainers describe this as part of a set of "critical security fixes" and recommend upgrading as soon as possible, even for users not directly affected by the specific issues listed (Payload Release v3.90.0). The vulnerability was reported by community researcher pavelkohout396 and published by maintainer DanRibbens (Payload Security Advisory). No significant broader media coverage or notable social media discussion has been identified beyond the official advisory.