Parse Server vulnerabilities

Parse Server before 8.6.109 and 9.0.0 before 9.10.6-alpha.1 returns stored field values in object update responses without checking read access. Clients whose class-level permissions or object ACLs allow update but not read can see object data, including atomic operation results, Cloud Code trigger-set values, and whole parent fields under dot notation in certain conditions.

Parse Server from 9.7.0 before 9.10.5-alpha.10 contains an authorization flaw that applies _Installation updates addressed by object ID to the installation named in the X-Parse-Installation-Id header. When protectedFieldsTriggerExempt is enabled, attackers knowing another installation's object ID can make a beforeSave trigger process that installation's protected fields while writing elsewhere.

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 from 9.7.0 before 9.10.5-alpha.7 contains an information disclosure vulnerability that allows clients to receive protected field values written by beforeSave triggers using dot notation keys. When protectedFieldsSaveResponseExempt is set to false, clients with create or update permission can read values a trigger writes beneath a protected field in the same request.

Parse Server before 8.6.108 and 9.0.0 before 9.10.5-alpha.9 contains a prototype pollution vulnerability because user-controlled keys are expanded into objects without own-property checks. Clients with class write access can send dot notation field keys or ACL entry names matching built-in object members to corrupt built-in functions, causing all requests to fail until server restart.

Parse Server before 8.6.106 and 9.0.0 before 9.10.5-alpha.7 mishandles dot notation keys with null or undefined values when building the saved object, so a write is stored but returns an error and skips afterSave triggers and LiveQuery events. A client with write access can exploit this to evade audit logging, notifications, and derived data updates.

Parse Server before 8.6.107 and 9.0.0 before 9.10.5-alpha.8 returns the stored value of a field reverted by a beforeSave trigger in object update responses, even to clients without read access to that object or field. An authenticated client able to update an object whose beforeSave trigger reverts a field, via revert() or a constant: true validator, can read protected values, including its own account's raw MFA authData when protectedFieldsTriggerExempt is enabled.

Parse Server before 8.6.105 and 9.0.0 before 9.10.5-alpha.6 does not validate the owning object reference in $relatedTo relation queries, so supplying a query operator instead of an object ID bypasses the owning-object ACL check. A client with read access to at least one object of the owning class can disclose which readable objects are linked to owning objects it cannot read.

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.

Parse Server before 8.6.100 and 9.0.0 before 9.10.4-alpha.3 does not reject reserved internal field names in client object writes, allowing clients to store or clear internal fields. Attackers can write a reserved field that makes reads of an object fail on MongoDB, disrupting queries on that class for all users, or clear their own account lockout state and password history to bypass lockout and password policies.

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 before 8.6.98 and 9.0.0 before 9.10.3-alpha.1 does not enforce the create and addField class-level permissions of the _Session class when creating sessions. An authenticated user or anyone holding that user's session token can send POST requests to /sessions or /classes/_Session to create additional sessions and add fields to _Session; these sessions are not revoked when the original session is logged out.

Parse Server before 8.6.99 and 9.0.0 before 9.10.3-alpha.2 evaluates checks against the target account during a user update before authorizing the caller, and reflects their outcome in the response. An unauthorized caller, with or without a session, can confirm guessed usernames or emails and, when passwordPolicy.maxPasswordHistory or doNotAllowUsername is set, guessed current or previous passwords, bypassing account lockout.

Parse Server before 8.6.97 and 9.0.0 before 9.10.2-alpha.6 does not handle errors raised while sending verification or password reset emails, causing the server process to exit. A client holding only the public application keys can sign up, request a verification email, or request a password reset while the mail provider rejects, rate limits, or is unavailable, crashing the server.

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.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 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 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.

In Parse Server prior to 8.6.76 and 9.9.0-alpha.2, a race condition in the MFA SMS one-time password (OTP) login path allows two concurrent /login requests with the same OTP to both succeed and receive valid session tokens, breaking the single-use property of the OTP. Exploitation requires the attacker to already possess the victim's password and intercept the active SMS OTP and race the legitimate login, so the practical attack surface is narrow.

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.

Parse Server is an open source backend. Prior to 9.8.0-alpha.6 and 8.6.74, the login endpoint response time differs measurably depending on whether the submitted username or email exists. When a user is not found the server responds immediately, while an existing user with a wrong password triggers a bcrypt comparison adding latency. This timing difference allows an unauthenticated attacker to enumerate valid usernames.

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.