CVE-2026-116165 in Parse Server
Summary
by MITRE • 10/25/2026
Parse Server before 8.6.101 and 9.0.0 before 9.10.4-alpha.4 contains a missing authorization vulnerability on MongoDB deployments that lets clients without the master key delete the stored schema of any class. Unauthenticated attackers can send REST API delete requests targeting the internal _SCHEMA collection to remove field definitions, class-level permissions, and protected fields, exposing data to unauthorized reads and modifications.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/25/2026
The vulnerability identified in Parse Server versions prior to 8.6.101 and 9.0.0 before 9.10.4-alpha.4 represents a critical failure in access control mechanisms within MongoDB deployments that utilize the default schema management architecture. This flaw stems from an improper implementation of authorization checks on specific internal API endpoints, specifically those interacting with the _SCHEMA collection. In standard Parse Server configurations, this collection stores metadata regarding application data structures, including field definitions for every class, class-level permissions governing read and write access, and protected fields that are intended to be immutable by end-users. The absence of a mandatory verification step requiring the master key or an equivalent administrative credential allows any client with network connectivity to interact directly with these internal schema resources without proper authentication.
From a technical perspective, this is classified as CWE-269 Improper Privilege Management, where the software does not properly restrict access for users lacking appropriate privileges. The vulnerability specifically targets the REST API endpoints responsible for deleting or modifying entries in the _SCHEMA collection. Because MongoDB deployments often expose these internal structures to application-level APIs for dynamic schema evolution, the lack of a strict gatekeeper mechanism means that unauthenticated actors can send DELETE requests targeting specific class schemas. This action effectively strips the database of its structural constraints and security policies defined by the developer. The attacker does not need valid user credentials or API keys; they only require knowledge of the target class names and access to the Parse Server REST interface, which is often publicly accessible on standard ports.
The operational impact of this vulnerability is severe and potentially catastrophic for data integrity and confidentiality. By deleting field definitions, an attacker can corrupt the application's understanding of its own data model, leading to runtime errors or complete service unavailability as the server attempts to process records that no longer match expected schemas. More critically, removing class-level permissions allows unauthorized users to bypass existing access control lists. This exposes sensitive data stored in those classes to arbitrary reads and modifications by any client. Protected fields, which are designed to prevent tampering with critical metadata or system-controlled attributes, become vulnerable to alteration, further degrading the security posture of the entire application environment.
This attack vector aligns closely with MITRE ATT&CK technique T1530 Data from Information Repositories, as it involves accessing and manipulating data stored in a database repository without proper authorization. It also reflects aspects of T1489 Service Stop, since corrupting schema definitions can lead to denial of service conditions for legitimate users attempting to access the application. The ability to modify permissions directly impacts confidentiality and integrity objectives defined in standard security frameworks like ISO 27001, as it allows unauthorized data exfiltration and potential injection of malicious content into previously secure datasets.
Mitigation strategies must prioritize immediate patching and architectural review. Organizations running affected versions should upgrade Parse Server to version 8.6.101 or later for the legacy branch, or version 9.10.4-alpha.4 and above for the development branch, where these authorization checks have been reinforced. For environments that cannot immediately update due to compatibility constraints, implementing a reverse proxy with strict access control lists can restrict external access to internal API endpoints. Additionally, reviewing MongoDB deployment configurations to ensure that schema modification operations are strictly bound to administrative roles is essential. Regular security audits focusing on REST API endpoint permissions and continuous monitoring for anomalous DELETE requests against the _SCHEMA collection will help detect exploitation attempts early.