Parse Server vulnerabilities

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 vulnerability allows unauthenticated attackers with public Application Id and client key to replay an introspection query from Apollo Server's cache to retrieve the GraphQL schema, including private class and field names. The introspection control is only applied to directly sent operations, not to those from the persisted query cache.

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.

Parse Server, an open source backend server, in versions prior to 8.6.90 and from 9.0.0 prior to 9.10.1-alpha.9, has a vulnerability in the device token deduplication logic for installation records. The logic 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 to inject query operators, causing the deduplication cleanup to delete every device registration in the application or an attacker-chosen subset.

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 forwards the client-supplied password without verifying it is provided and treats any non-error response as proof of authentication. An unauthenticated attacker knowing a directory username can obtain a valid session token for that account, leading to account takeover.

Parse Server versions from 9.0.0 before 9.10.0-alpha.5 and from 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 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 from 9.0.0 before 9.10.0-alpha.6 and from 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.

Vulnerability in Parse Server versions >= 9.0.0 before 9.10.0-alpha.4 and versions before 8.6.85 causes schema disclosure. Despite disabling public GraphQL introspection, variable coercion errors reveal 'Did you mean ...?' suggestions, allowing an unauthenticated attacker to recover hidden schema identifiers.

Parse Server versions >= 9.0.0, < 9.10.0-alpha.2 and <= 8.6.83 are affected by a stored XSS vulnerability. A malformed Content-Type (e.g., 'image//svg+xml') bypasses the file extension blocklist and is stored unchanged; on storage adapters like S3, GCS, or Azure, browsers fall back to MIME-sniffing and render HTML content, executing embedded scripts.

A vulnerability in Parse Server allows a LiveQuery subscriber to receive object field values they are not authorized to read. This occurs when a single save operation changes both an object field and the subscriber's ACL read access, causing incorrect handling of leave and enter events.

A vulnerability in Parse Server allows blocking the Node.js event loop by sending deeply nested $or, $and, and $nor query condition operators via REST API or LiveQuery. Processing such queries can lead to exponential execution time, preventing other requests from being handled.

A vulnerability in Parse Server allows bypassing the default file upload extension blocklist by uploading a file with a non-standard or compound extension and dangerous content type. This enables storage adapters like S3 and GCS to serve attacker-supplied active content, leading to stored cross-site scripting (XSS).

In Parse Server prior to versions 8.6.80 and 9.9.1-alpha.6, a vulnerability allowed reading the membership of a Relation field using the $relatedTo operator, even when that field was hidden from the client. This enabled unauthorized clients to enumerate objects linked through a protected relation.

Parse Server versions from 9.8.0 to before 9.9.1-alpha.5 have a vulnerability that allows the exposure of sensitive user data through the /login and /verifyPassword endpoints when MFA is enabled and access to the _User class is denied. When access to user data is denied, the server falls back to raw database rows, potentially exposing sensitive information such as MFA secrets and recovery codes.

Parse Server prior to versions 8.6.79 and 9.9.1-alpha.4 allowed bypassing the default file upload extension blocklist by appending a trailing dot to a filename. This enables attackers to upload files with dangerous MIME types, leading to potential XSS attacks.

Parse Server versions from 9.8.0 to before 9.9.1-alpha.3 have a vulnerability that allows bypassing the allowed API route list. External clients can issue sub-requests to routes not included in this list, creating a risk of unauthorized access.

Parse Server prior to versions 8.6.78 and 9.9.1-alpha.2 discloses schema metadata through GraphQL validation-error messages, allowing unauthenticated users to reconstruct class and field names.

Parse Server prior to versions 8.6.77 and 9.9.1-alpha.1 is vulnerable to an attack where an unauthenticated user can send a malicious HTTP request, leading to excessive CPU consumption on the server.

Parse Server is vulnerable to disclosure of protected session fields via the GET /sessions/me endpoint. This endpoint returns _Session fields that the server operator configured as protected, while other endpoints correctly strip them.

Vulnerability in Parse Server before versions 8.6.73 and 9.7.1-alpha.4 allowing file upload with a valid extension but mismatched Content-Type header. Some storage adapters (S3, GCS) serve the file with the provided Content-Type, potentially leading to attacks.

Parse Server before versions 8.6.71 and 9.7.1-alpha.1 allows file downloads via HTTP Range requests that bypass the afterFind(Parse.File) trigger and validators when the storage adapter supports streaming (e.g., default GridFS). This grants unauthorized access to protected files.

Parse Server prior to versions 8.6.63 and 9.7.0-alpha.7 returns unsanitized authentication data from the verify password endpoint, including MFA TOTP secrets, recovery codes, and OAuth tokens. An attacker who knows the user's password can extract the MFA secret and generate valid MFA codes.

In Parse Server before versions 8.6.70 and 9.7.0-alpha.18, an authenticated user with find class-level permission can bypass the protectedFields setting on LiveQuery subscriptions. By sending a subscription with $or, $and, or $nor as an array-like object, the protection is bypassed, allowing reading of protected fields.

Parse Server before versions 8.6.69 and 9.7.0-alpha.14 allows an authenticated user to bypass the immutability guard on session fields (expiresAt, createdWith) by sending a null value in a PUT request to the session update endpoint. This allows nullifying the session expiry, making the session valid indefinitely and bypassing configured session length policies.

Parse Server before versions 8.6.68 and 9.7.0-alpha.12 has a DoS vulnerability via GraphQL. By sending a crafted query with binary fan-out fragment spreads, an unauthenticated attacker can block the Node.js event loop for seconds, denying service to all concurrent users. This only affects deployments with requestComplexity.graphQLDepth or requestComplexity.graphQLFields enabled.

Parse Server prior to versions 8.6.66 and 9.7.0-alpha.10 does not respect the allowOrigin server option in the GraphQL API, unconditionally allowing cross-origin requests from any website. The REST API correctly enforces this restriction.

Parse Server before versions 8.6.65 and 9.7.0-alpha.9 has a LiveQuery vulnerability. When multiple clients subscribe to the same class, shared mutable objects modified by sensitive data filters can leak protected fields or authentication data to unauthorized clients. Also, afterEvent Cloud Code trigger modifications can leak to other subscribers.

In Parse Server before versions 8.6.64 and 9.7.0-alpha.8, an attacker with a valid authentication provider token and a single MFA recovery code or SMS one-time password can create multiple authenticated sessions by sending concurrent login requests to the authData endpoint. This defeats the single-use guarantee of MFA codes, allowing session persistence even after the legitimate user revokes detected sessions.

Parse Server before versions 8.6.1 and 9.1.0-alpha.3 has a Reflected Cross-Site Scripting (XSS) vulnerability in password reset and email verification HTML pages. The patch in versions 8.6.1 and 9.1.0-alpha.3 escapes user-controlled values.