CVE-2026-109302

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 before 8.6.95 and 9.0.0 before 9.10.2-alpha.3 does not resolve file references lacking a URL before passing objects to Cloud Code triggers and LiveQuery, causing an uncaught exception that terminates the process. Attackers able to write to a class with Cloud Code save, find, or delete triggers or LiveQuery enabled, including unauthenticated users when public write access or sign-up is allowed, can crash the server or break subsequent requests.

Parse Server prior to versions 8.6.67 and 9.7.0-alpha.11 has a vulnerability where an attacker can bypass Cloud Function validator access controls by appending "prototype.constructor" to the function name in the URL. This causes all access control enforcement to be skipped, allowing unauthenticated callers to invoke protected Cloud Functions.

Parse Server prior to versions 8.6.3 and 9.1.1-alpha.4 is vulnerable to an attack where an unauthenticated attacker can forge a Google authentication token with 'alg: "none"', allowing them to log in as any user linked to a Google account without knowing their credentials.

Parse Server is an open source backend that can be deployed to any infrastructure that runs Node.js. In versions prior to 8.6.0-alpha.2, a GitHub CI workflow is triggered in a way that grants the GitHub Actions workflow elevated permissions, giving it access to GitHub secrets and write permissions which are defined in the workflow. Code from a fork or lifecycle scripts is potentially included. Only the repository's CI/CD infrastructure is affected, including any public GitHub forks with GitHub Actions enabled. This issue is fixed in version 8.6.0-alpha.2 and commits 6b9f896 and e3d27fe.

Parse Server prior to versions 5.5.2 and 6.2.1 is vulnerable to prototype pollution, which can lead to remote code execution through the MongoDB BSON parser.

Parse Server before 8.6.93 and 9.0.0 before 9.10.1-alpha.13 does not enforce identity-scoped protectedFields (authenticated, role, or per-user groups) on count queries using the $relatedTo operator, exposing the size of protected Relation fields. An authenticated user who can read the owning object can combine counts with an objectId constraint as a membership oracle to reveal confidential memberships such as private groups or block lists.

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 >= 9.0.0 < 9.10.1-alpha.10 and >= 8.0.2 < 8.6.91 do not verify the client's authorization code with the external provider on the login endpoint when authentication data is supplied with a username and password. This allows a low-privileged authenticated user to attach an arbitrary, unverified provider identity to their own account, and also enables account pre-hijacking. Fixed in versions 9.10.1-alpha.10 and 8.6.91.

Parse Server versions >= 9.0.0 and < 9.10.1-alpha.8, and versions < 8.6.89, evaluate 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. 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. Fixed in 9.10.1-alpha.8 and 8.6.89.