CVE-2026-120310 in Parse Server
Summary
by MITRE • 11/02/2026
Parse Server before 8.6.109 and 9.0.0 before 9.10.6-alpha.1 returns stored field values in object update responses without checking read access, so clients whose class-level permissions or object ACLs allow update but not read can see object data. Attackers can update such objects to read atomic operation results (Increment, Add, AddUnique, Remove), Cloud Code trigger-set values, and, for dot notation keys under certain conditions, the whole stored parent field.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability identified in Parse Server versions prior to 8.6.109 and 9.0.0 before 9.10.6-alpha.1 represents a critical failure in access control enforcement during object update operations. This flaw stems from an inconsistency between the permissions required for modifying data and those required for reading it within the server's response mechanism. Specifically, when a client performs an update operation on a Parse Object, the server returns the updated state of that object to confirm the change. However, in these affected versions, this return value is generated without verifying whether the requesting user possesses read access permissions for the specific fields being returned. This architectural oversight allows users who have been granted write or update privileges but explicitly denied read privileges to inadvertently disclose sensitive data contained within those objects.
From a technical perspective, the issue manifests when atomic operations such as Increment, Add, AddUnique, and Remove are executed against object fields. These operations modify existing values in place rather than replacing them entirely. Upon completion of these atomic updates, Parse Server constructs a response payload that includes the new state of the modified fields. Because the server fails to cross-reference this output with the user's read access rights defined by class-level permissions or Object Access Control Lists (ACLs), any data updated through these mechanisms becomes visible to the updater regardless of their read restrictions. This behavior effectively bypasses the intended security boundary, allowing unauthorized disclosure of information that should remain confidential based on the configured ACL policies.
The operational impact of this vulnerability is significant for applications relying on fine-grained access control models. Attackers can exploit this flaw to exfiltrate sensitive user data by performing targeted updates on objects where they have write permissions but lack read permissions. The scope of exposed information includes not only standard field values modified via atomic operations but also internal state managed through Cloud Code triggers. If a Cloud Code trigger sets specific values during an update process, these trigger-set values are included in the response and thus leaked to the attacker. Furthermore, under certain conditions involving dot notation keys for nested objects, attackers can potentially retrieve entire parent fields that were not directly targeted by the atomic operation but are structurally linked within the object hierarchy. This capability transforms a simple permission bypass into a comprehensive data exfiltration vector.
This vulnerability aligns with CWE-284 Improper Access Control and falls under the MITRE ATT&CK technique of T1530 Data from Cloud Storage, specifically relating to unauthorized access via API endpoints. The flaw highlights the importance of ensuring that all output channels in an application strictly adhere to the same security policies as input validation mechanisms. In this case, while input was correctly validated against write permissions, output generation neglected read permission checks, creating a classic side-channel information leak within the RESTful interface of the Parse Server API.
To mitigate this vulnerability, organizations must upgrade their Parse Server instances immediately to version 8.6.109 or later for the 8.x branch, and version 9.10.6-alpha.1 or later for the 9.x development line. These releases contain patches that enforce read access checks on all fields returned in update responses, ensuring consistency with ACL policies. Additionally, developers should review their application's security architecture to ensure that class-level permissions and object-specific ACLs are rigorously tested against both read and write operations. Implementing comprehensive logging for permission denials can also aid in detecting attempts to exploit this flaw before an upgrade is feasible. Regular audits of access control logic across all API endpoints are recommended to prevent similar discrepancies between input validation and output sanitization processes.