Description

Parse Server is an open source backend server. In versions prior to 8.6.90 and in versions from 9.0.0 prior to 9.10.1-alpha.9, the device token deduplication logic for installation records does not validate the type of client-supplied installation fields before using them to build database queries. An unauthenticated remote attacker who knows only the public application ID can submit non-string values in these fields to inject query operators, causing the deduplication cleanup — which runs with elevated privileges before class-level permissions are evaluated — to delete every device registration in the application or an attacker-chosen subset of them. No account, session token, master key, or user interaction is required. Deleted registrations cannot be recovered on the server, so push notifications cannot be delivered until every client re-registers. Any deployment that exposes the REST API to clients and uses push notifications is affected in its default configuration. Versions 8.6.90 and 9.10.1-alpha.9 fix the issue by rejecting non-string values with a client error and by scoping the deduplication cleanup to the calling application. No workaround other than upgrading is available.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-26T14:16:44.397Z",
  "pubdate": "2026-09-26T14:16:44.397Z",
  "executiveSummary": "Parse Server is susceptible to a critical NoSQL injection vulnerability within its device token deduplication logic for installation records. The flaw allows unauthenticated remote attackers to inject malicious query operators into client-supplied installation fields, bypassing standard security controls. By leveraging this vulnerability, an attacker can trigger the deletion of all device registrations within an application, effectively disabling push notification services.\nThe vulnerability stems from improper validation of input types in the deduplication process, which executes with elevated privileges prior to class-level permission evaluations. Because the cleanup operation is not adequately scoped to the calling session, the impact is severe, potentially resulting in a total loss of device registration data. This flaw does not require authentication, master keys, or session tokens, making it highly exploitable for any deployment exposing the REST API. The risk is classified as critical, as it mandates immediate intervention to prevent service disruption and permanent data loss of client registration states.",
  "technicalDetails": "The vulnerability resides in the backend logic responsible for managing installation record deduplication. In Parse Server versions prior to 8.6.90 and 9.0.0 through 9.10.1-alpha.9, the system fails to enforce strict data-type validation on client-supplied fields. Specifically, when the server processes installation updates, it constructs database queries using these fields to maintain unique device token associations. An attacker can supply non-string values (e.g., objects containing NoSQL operators like $ne, $gt, or $in) instead of the expected string format.\nBecause this deduplication logic executes with elevated privileges—bypassing standard class-level permissions (CLPs) and access control lists—the server interprets the attacker-supplied operators as part of the query logic. By submitting a crafted payload, an attacker can force the database query to match an unintended subset of records or, in the worst-case scenario, all records associated with the application's installation class.\nThe attack flow proceeds as follows: 1) An unauthenticated attacker identifies the public application ID of a target Parse Server deployment. 2) The attacker crafts an API request targeting the installation record endpoint, inserting NoSQL operator objects into fields intended for simple string values. 3) The server's deduplication routine parses the input without type sanitization. 4) The injected query executes against the underlying database (e.g., MongoDB), causing the logic to identify valid user registrations as duplicates or redundant records. 5) The server triggers a cleanup operation, which systematically deletes the matching records. 6) Because these records are purged from the database, the server's push notification functionality is rendered inoperable until every impacted client initiates a fresh registration request. As the deletion occurs directly at the database level through the application logic, the damage is immediate and necessitates full client-side intervention for remediation."
}