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.
CVE-2026-116164 is a vulnerability in parse-community's parse-server that affects versions before 8.6.100 and 9.0.0 before 9.10.4-alpha.3. It allows clients to write or clear reserved internal fields in objects due to improper input validation. This can cause read failures on MongoDB queries for all users or enable attackers to bypass account lockout and password policies by clearing their own lockout state and password history.
Parse Server before 8.6.102 and 9.0.0 before 9.10.5-alpha.2 contains an authentication bypass because the validateSetUp, validateLogin, and validateUpdate methods of custom adapters subclassing AuthAdapter are never called, and an inherited default that accepts any authData is used instead. Attackers can supply arbitrary authData to sign up, link identities, log in as existing users, or skip custom additional authentication factors.
Parse Server before 8.6.104 and 9.0.0 before 9.10.5-alpha.5 saves the entire login request with master privileges when issuing an SMS multi-factor authentication verification code. An SMS MFA-enrolled user can include extra fields in that request to modify master-key-restricted fields on their own account, such as the email-verification flag or beforeSave-protected values.
Parse Server before 8.6.103 and 9.0.0 before 9.10.5-alpha.4 contains an information disclosure vulnerability in LiveQuery. Its subscription hash omits constraints next to a $or operator, including the _Session owner filter and beforeSubscribe constraints, so distinct subscriptions are grouped together. Authenticated clients subscribing with $or queries can receive other users' events, including session tokens usable for impersonation.
Parse Server versions before 8.6.98 and versions from 9.0.0 up to but not including 9.10.3-alpha.1 have an incorrect authorization vulnerability in the _Session class. This flaw allows authenticated users or anyone with a user's session token to create additional sessions and add fields to the _Session class without proper permission enforcement. These additional sessions remain active even after the original session is logged out.
Parse Server versions before 8.6.99 and versions 9.0.0 up to but not including 9.10.3-alpha.2 contain an incorrect authorization vulnerability. The server evaluates checks against the target account during user updates before verifying the caller's authorization, leaking information about usernames, emails, and, under certain password policy settings, current or previous passwords. This allows an unauthorized attacker to confirm guessed credentials and bypass account lockout mechanisms.
Parse Server versions before 8.6.97 and 9.0.0 before 9.10.2-alpha.6 have a vulnerability where errors during sending verification or password reset emails are not handled properly, causing the server process to exit. This can be triggered by a client using only public application keys when the mail provider rejects, rate limits, or is unavailable.
Parse Server 5.4.0 before 8.6.96 and 9.0.0 before 9.10.2-alpha.5 shares transactional batch state across concurrent requests, letting any client's transactional batch request interfere with other clients' database writes. On PostgreSQL or MongoDB replica sets and sharded clusters, other clients' acknowledged writes are rolled back if the batch fails, and PostgreSQL transactions can remain open indefinitely, causing subsequent writes to fail.
Parse Server versions before 8.6.93 and 9.0.0 before 9.10.1-alpha.13 have an authorization bypass vulnerability in count queries using the $relatedTo operator. This flaw allows authenticated users who can read an owning object to infer confidential membership information such as private groups or block lists by exploiting the lack of enforcement of identity-scoped protectedFields on these queries.
Parse Server versions 8.2.2 before 8.6.94 and 9.0.0 before 9.10.1-alpha.14 have an authorization flaw in their GraphQL introspection control. The control is applied only to operation text sent directly with a request, but not to operations resolved from Apollo Server's automatic persisted query cache. This allows unauthenticated attackers with the public Application Id and client key to replay cached introspection queries originally made by privileged clients, thereby retrieving the schema including private class and field names.
Parse Server versions before 8.6.95 and versions from 9.0.0 up to but excluding 9.10.2-alpha.3 contain a vulnerability where file references lacking a URL are not resolved before being passed to Cloud Code triggers and LiveQuery. This causes an uncaught exception that terminates the server process. Attackers with the ability to write to classes with Cloud Code save, find, or delete triggers or LiveQuery enabled can exploit this to crash the server or disrupt subsequent requests. This includes unauthenticated users if public write access or sign-up is allowed.
Parse Server 8.2.2 before 8.6.92 and 9.0.0 before 9.10.1-alpha.12 contains an information disclosure vulnerability in which GraphQL validation error messages reveal hidden class names when public introspection is disabled. Unauthenticated attackers holding only the public Application Id can send crafted operations triggering unknown-argument or invalid enum value errors to learn pointer and relation target classes.
Parse Server versions >=8.0.2 <8.6.91 and >=9.0.0 <9.10.1-alpha.10 have an improper authentication vulnerability in their code-based authentication adapters. These adapters do not verify the client's authorization code with the external provider during login when authentication data is supplied with username and password. This allows a low-privileged authenticated user to link an arbitrary, unverified external provider identity to their account, potentially spoofing trusted identities. Additionally, attackers can pre-hijack accounts by claiming a provider ID before the legitimate user links it. Versions 8.6.91 and 9.10.1-alpha.10 fix this by verifying credentials on login and rejecting already linked provider IDs. Disabling affected adapters is a recommended workaround.
Parse Server is an open-source backend server. In versions >= 9.0.0 and < 9.10.1-alpha.8, and in versions < 8.6.89, LiveQuery evaluates the protectedFields class-level permission against an incompletely resolved caller identity: the subscriber's roles are not resolved, and when a subscription does not supply its own session token the event payload is redacted against an anonymous identity even though the read was authorized against the connected user. As a result, field masks defined for a role, for authenticated users, or for a specific user are not applied, so an authenticated subscriber can receive field values that the REST API correctly withholds and can use a masked field to filter or watch a subscription. Only classes with LiveQuery enabled that define protectedFields under a role:, authenticated, or per-user group are affected; masks under the public (*) group are applied correctly. The issue is fixed in 9.10.1-alpha.8 and 8.6.89. As a workaround, additionally define the affected field masks under the public (*) group, or disable LiveQuery for classes whose class-level permissions rely on role-scoped, authenticated, or per-user protectedFields groups.
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.
Parse Server versions <= 8.6.87 and >= 9.0.0 < 9.10.1-alpha.7 contain an authentication bypass in the built-in LDAP authentication adapter. The adapter forwarded the client-supplied password to the directory without verifying that a password had been supplied, and treated any non-error response from the directory as proof of authentication. A zero-length credential turns an LDAP simple bind into the unauthenticated authentication mechanism described in RFC 4513 section 5.1.2, which some directories (including Active Directory in its default configuration) answer with success while mapping the connection to anonymous. As a result, an unauthenticated attacker who knows a directory username can obtain a valid session token for that account, resulting in account takeover. Only deployments that enable the LDAP authentication adapter are affected, and deployments whose directory refuses unauthenticated simple bind (such as a stock OpenLDAP configuration) are not exploitable. The issue is fixed in 8.6.88 and 9.10.1-alpha.7, which require the password to be a non-empty string and reject the request before contacting the directory.
Parse Server versions >= 9.0.0 before 9.10.0-alpha.5 and >= 8.2.2 before 8.6.86 return GraphQL validation error messages that name required custom input fields even when public introspection is disabled (graphQLPublicIntrospection: false, the default). A client holding only the public application id — with no user session, master key, or maintenance key — can trigger validation errors to learn the names of required (non-null) custom fields on classes it already references by name, partially defeating the schema-hiding intent of disabling public introspection. No stored data, credentials, optional field names, unreferenced class names, or Cloud Code function names are exposed.
Parse Server versions >= 9.0.0 before 9.10.0-alpha.6 and >= 8.2.2 before 8.6.87 disclose Pointer and Relation target class names through GraphQL validation and input-coercion error messages when public schema introspection is disabled (graphQLPublicIntrospection: false, the default). Because these errors are produced before authentication, authorization, or any resolver runs, an unauthenticated client possessing only the public application ID can trigger errors on Pointer or Relation fields to reconstruct hidden schema class names, partially defeating the schema-hiding protection. Only schema metadata (class names) is exposed; no object data, credentials, or user records are disclosed.
Parse Server versions >= 9.0.0 before 9.10.0-alpha.4 and versions before 8.6.85 contain a schema disclosure vulnerability. When the GraphQL API is mounted with public introspection disabled (graphQLPublicIntrospection: false, the default), schema-derived 'Did you mean ...?' suggestions were still returned in GraphQL error messages produced during variable coercion, which were not covered by the introspection-hardening control (that only handled validation errors). An unauthenticated caller possessing only the public application id can iteratively recover hidden schema identifiers — including registered Cloud Code function names and Parse class and field names — by submitting queries or mutations whose variables contain near-miss enum values or input-object field names. This is a follow-up bypass of GHSA-8cph-rgr4-g5vj. The issue is fixed in 9.10.0-alpha.4 and 8.6.85.