CVE-2026-119570 in parse-server
Summary
by MITRE • 10/30/2026
Parse Server from 9.7.0 before 9.10.5-alpha.7 contains an information disclosure vulnerability that allows clients to receive protected field values written by beforeSave triggers using dot notation keys. When protectedFieldsSaveResponseExempt is set to false, clients with create or update permission can read values a trigger writes beneath a protected field in the same request.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/30/2026
Parse Server versions prior to 9.10.5-alpha.7 contain an information disclosure vulnerability rooted in how the framework handles response serialization for protected fields during save operations involving beforeSave triggers. The core technical flaw lies in the interaction between the protectedFields configuration and the execution of server-side hooks. Specifically, when a client with create or update permissions performs a write operation that includes data written by a beforeSave trigger beneath a protected field using dot notation keys, the system fails to correctly mask these values in the API response. This behavior occurs even when the protectedFieldsSaveResponseExempt configuration option is explicitly set to false, which is intended to enforce strict masking of sensitive fields upon save responses. The vulnerability effectively bypasses the security boundary established by the application's access control policies because the server returns the full object state including the newly written trigger data as if it were part of the original client request or a standard public field update.
The operational impact of this flaw is significant for applications relying on Parse Server to enforce fine-grained data privacy and role-based access controls. Attackers who possess basic create or update permissions can exploit this behavior to exfiltrate sensitive information that was intended to be hidden from the requesting client. This often involves internal logic, system-generated identifiers, or other confidential metadata injected by server-side triggers for business logic purposes rather than direct user input. By leveraging dot notation keys in their requests, malicious actors can trigger the flawed serialization path and receive responses containing these protected values. This constitutes a classic case of insecure direct object references combined with improper access control, leading to unauthorized data exposure that undermines the confidentiality guarantees provided by the platform's security model.
From an industry standards perspective, this vulnerability aligns closely with CWE-209, which describes the generation of error messages containing sensitive information, and more accurately with CWE-613, insufficient session expiration or management in some contexts, but primarily it falls under CWE-862, missing authorization. The attack vector allows an authenticated user to access resources they are not explicitly authorized to view by exploiting a logic flaw rather than breaking encryption or authentication mechanisms directly. In the context of the MITRE ATT&CK framework for enterprise security, this behavior facilitates Data Exfiltration over Application Protocol and potentially contributes to Discovery activities where attackers map out internal data structures and hidden fields that were not intended for client-side consumption. The use of dot notation keys suggests a potential overlap with CWE-798, use of hard-coded credentials or configuration values if those protected fields contain such sensitive settings, though the primary issue is the unauthorized disclosure via API response manipulation.
To mitigate this vulnerability, organizations running Parse Server must upgrade to version 9.10.5-alpha.7 or any subsequent stable release where the logic for handling beforeSave trigger outputs in relation to protected fields has been corrected. Until an upgrade can be performed, administrators should review their application's use of dot notation keys within save operations and consider implementing additional server-side validation layers that explicitly strip sensitive data from responses regardless of the framework's default behavior. It is also advisable to audit existing codebases for any reliance on beforeSave triggers writing directly into protected field paths using nested key structures, as this pattern increases exposure risk in unpatched environments. Regular security assessments and penetration testing focused on API response parsing can help identify similar logic flaws where server-side state modifications are inadvertently exposed through client-facing endpoints.