CVE-2026-105855 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, the server fails to enforce a field-level access.update restriction on the password field of an authentication collection. This issue is fixed in versions 3.90.0 and 4.0.0-canary.34.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/06/2026
Payload CMS represents a modern headless content management system built for developers, offering flexibility through its schema-driven approach to data modeling. In the specific context of authentication collections, which handle user credentials and session management, strict access control mechanisms are critical to maintaining security integrity. The vulnerability identified in versions prior to 3.90.0 and canary versions before 4.0.0-canary.34 stems from a failure in the server-side logic to properly enforce field-level restrictions on update operations for sensitive fields within these collections. Specifically, while general access controls might restrict who can view or modify entire records, the system failed to apply granular permissions that prevent unauthorized users from modifying specific high-risk fields such as passwords when they should not have write access to them.
This technical flaw constitutes a classic example of broken access control at the field level, which is categorized under CWE-284 Improper Access Control and often relates to CWE-601 URL Redirection or more accurately in this context, CWE-798 Use of Hard-coded Credentials if it leads to credential manipulation. The core issue lies in the middleware or API layer that processes update requests for authentication documents. When a user with limited privileges attempts to send an HTTP request containing a password field within the payload data, the server incorrectly accepts and persists this change without verifying whether the requesting entity has explicit permission to modify that specific attribute. This bypass of granular security policies allows any authenticated user who can access the update endpoint for authentication collections to overwrite their own or potentially other users' passwords if session management logic permits self-modification in an uncontrolled manner, or worse, exploit race conditions and authorization flaws to escalate privileges by manipulating credential hashes directly through API calls.
The operational impact of this vulnerability is severe as it compromises the fundamental security assumption that password fields are immutable except during explicit authentication flows like login or password reset. An attacker could leverage this flaw to perform unauthorized password changes, leading to account takeover scenarios where they lock out legitimate users or gain persistent access by setting a known password hash. Furthermore, if the system does not properly validate input types for hashed passwords versus plain text, it might allow an attacker to inject raw hashes that bypass subsequent verification steps depending on how the authentication middleware processes incoming data. This aligns with MITRE ATT&CK technique T1078 Valid Accounts, where attackers use legitimate credentials or manipulate them to maintain access and evade detection mechanisms designed to flag suspicious login patterns from unknown sources.
Mitigation strategies for this vulnerability involve immediate upgrading to version 3.90.0 or later, which includes the necessary patches to enforce strict field-level permissions on authentication collections. For organizations unable to upgrade immediately due to dependency constraints, implementing a reverse proxy rule that blocks direct API calls attempting to update password fields in authentication endpoints can serve as a temporary compensating control. Additionally, developers should audit their custom middleware and hooks related to user management to ensure that any custom logic does not inadvertently bypass the framework's built-in access controls. It is also recommended to review logging configurations to detect anomalous patterns of frequent password field updates from single IP addresses or users, which may indicate exploitation attempts in progress before a full patch deployment can be executed across all environments.