CVE-2026-116164 in Parse Server
Summary
by MITRE • 10/25/2026
Parse Server before 8.6.100 and 9.0.0 before 9.10.4-alpha.3 does not reject reserved internal field names in client object writes, allowing clients to store or clear internal fields. Attackers can write a reserved field that makes reads of an object fail on MongoDB, disrupting queries on that class for all users, or clear their own account lockout state and password history to bypass lockout and password policies.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/25/2026
Parse Server versions prior to 8.6.100 and the 9.0.0 series before 9.10.4-alpha.3 contain a critical input validation deficiency that permits clients to manipulate reserved internal fields during object write operations. This vulnerability stems from an insufficient sanitization process where the server fails to reject or strip field names designated for internal system use, such as those managing authentication state, session management, and account security policies. By allowing these fields to be overwritten by untrusted client input, the application exposes a mechanism through which attackers can alter core operational data that should remain immutable from the user-facing API layer. This flaw represents a significant deviation from secure coding practices regarding separation of concerns between internal system logic and external user inputs, effectively bypassing intended access controls designed to protect sensitive account metadata.
The technical impact of this vulnerability is twofold, affecting both service availability and authentication integrity. On one hand, an attacker can write specific reserved field values that cause MongoDB queries on the affected class to fail catastrophically. Since these internal fields are often indexed or used in query constraints by the Parse Server backend, corrupting their structure or content disrupts database operations for all users interacting with that particular data class. This results in a denial of service condition where legitimate read and write requests cannot be processed correctly due to underlying database errors triggered by malformed internal state. On the other hand, attackers can exploit this flaw to clear their own account lockout states and password history records. By resetting these fields, an attacker effectively nullifies security mechanisms designed to prevent brute-force attacks or credential stuffing, allowing them to bypass account lockouts and reuse previously compromised passwords without restriction.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the server fails to adequately validate incoming data against expected constraints for internal fields. It also relates closely to CWE-693 Protection Mechanism Failure, specifically in how it bypasses intended security controls like account lockout policies and password history enforcement. In terms of offensive tactics, this behavior corresponds to ATT&CK technique T1078 Valid Accounts, where an attacker uses legitimate credentials but manipulates internal state to maintain access or evade detection. Furthermore, the ability to disrupt database operations for all users touches upon availability impacts similar to those seen in CWE-400 Uncontrolled Resource Consumption, although here the resource disruption is caused by logical corruption rather than sheer volume of requests.
Mitigation strategies must prioritize immediate patching to the latest stable versions of Parse Server that include these fixes. Administrators should ensure their deployment pipelines are configured to automatically apply security patches for this specific version range. In environments where upgrading is not immediately feasible, network-level controls such as Web Application Firewalls can be tuned to inspect and block requests containing suspicious internal field names in write operations. Additionally, implementing strict schema validation at the application layer that explicitly whitelists allowed fields rather than relying on implicit server-side filtering can provide a defense-in-depth approach. Regular audits of client-server interactions should also be conducted to ensure no other reserved or system-managed fields are exposed to direct manipulation via API endpoints.