Parse Server before 4.10.0 contains a supply chain vulnerability where incorrect version tags were pushed to the repository linking to unreviewed code in a personal fork. Attackers could exploit this by specifying affected version tags in dependency declarations to execute unreviewed and potentially malicious code.
Impact
An attacker who possesses 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 via the authData login endpoint. This defeats the single-use guarantee of MFA recovery codes and SMS one-time passwords, allowing session persistence even after the legitimate user revokes detected sessions.
Patches
The fix adds optimistic locking to the authData login path, ensuring that concurrent database updates for the same user fail when the original MFA token array has already been modified by another request.
Workarounds
There is no known workaround.
Impact
When multiple clients subscribe to the same class via LiveQuery, the event handlers process each subscriber concurrently using shared mutable objects. The sensitive data filter modifies these shared objects in-place, so when one subscriber's filter removes a protected field, subsequent subscribers may receive the already-filtered object. This can cause protected fields and authentication data to leak to clients that should not see them, or cause clients that should see the data to receive an incomplete object.
Additionally, when an afterEvent Cloud Code trigger is registered, one subscriber's trigger modifications can leak to other subscribers through the same shared mutable state.
Any Parse Server deployment using LiveQuery with protected fields or afterEvent triggers is affected when multiple clients subscribe to the same class.
Patches
The fix deep-clones the shared objects at the start of each subscriber's processing callback, ensuring each subscriber works on an independent copy. Additionally, a bug was fixed where master key LiveQuery clients could not receive events on classes with protected fields due to an incorrect type passed to the sensitive data filter.
Workarounds
There is no known workaround.
Resources
- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-m983-v2ff-wq65 - Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10330 - Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10331
Impact
The GraphQL API endpoint does not respect the allowOrigin server option and unconditionally allows cross-origin requests from any website. This bypasses origin restrictions that operators configure to control which websites can interact with the Parse Server API. The REST API correctly enforces the configured allowOrigin restriction.
Patches
The GraphQL API endpoint now uses the same CORS middleware as the REST API, ensuring the allowOrigin and allowHeaders server options are consistently enforced across all endpoints.
Workarounds
There is no known workaround other than upgrading.
Resources
- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-q3p6-g7c4-829c - Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10334 - Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10335
Impact
A file can be uploaded with a filename extension that passes the file extension allowlist (e.g., .txt) but with a Content-Type header that differs from the extension (e.g., text/html). The Content-Type is passed to the storage adapter without consistency validation. Storage adapters that store and serve the provided Content-Type (such as S3 or GCS) serve the file with the mismatched Content-Type. The default GridFS adapter is not affected because it derives Content-Type from the filename at serving time.
Patches
The file upload now derives the Content-Type from the filename extension, overriding any user-provided Content-Type when the file has an extension.
Workarounds
Configure the storage adapter or CDN to derive Content-Type from the filename extension instead of using the stored Content-Type.
Impact
The GET /sessions/me endpoint returns Session fields that the server operator explicitly configured as protected via the protectedFields server option. Any authenticated user can retrieve their own session's protected fields with a single request. The equivalent GET /sessions and GET /sessions/:objectId endpoints correctly strip protected fields.
Patches
The GET /sessions/me handler now re-fetches the session with the caller's auth context after validating the session token, ensuring protectedFields and CLP apply consistently with other session endpoints.
Workarounds
None.
References
- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-g4v2-qx3q-4p64 - Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10406 - Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10407
Impact
The verify password endpoint returns unsanitized authentication data, including MFA TOTP secrets, recovery codes, and OAuth access tokens. An attacker who knows a user's password can extract the MFA secret to generate valid MFA codes, defeating multi-factor authentication protection.
Patches
The verify password endpoint now sanitizes authentication data through auth adapter hooks before returning the response, consistent with login and user retrieval endpoints.
Workarounds
There is no known workaround.
Impact
An attacker can bypass Cloud Function validator access controls by appending .prototype.constructor to the function name in the URL. When a Cloud Function handler is declared using the function keyword and its validator is a plain object or arrow function, the trigger store traversal resolves the handler through its own prototype chain while the validator store fails to mirror this traversal, causing all access control enforcement to be skipped.
This allows unauthenticated callers to invoke Cloud Functions that are meant to be protected by validators such as requireUser, requireMaster, or custom validation logic.
Patches
The trigger store traversal now verifies that each intermediate node is a legitimate store object before continuing traversal. If the traversal encounters a non-store value such as a function handler, it stops and returns an empty store, preventing prototype chain escape.
Workarounds
Use arrow functions instead of the function keyword for Cloud Function handlers. Arrow functions do not have a prototype property and are not affected by this vulnerability.
Resources
- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-vpj2-qq7w-5qq6 - Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10342 - Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10343
Impact
The GraphQL query complexity validator can be exploited to cause a denial-of-service by sending a crafted query with binary fan-out fragment spreads. A single unauthenticated request can block the Node.js event loop for seconds, denying service to all concurrent users. This only affects deployments that have enabled the requestComplexity.graphQLDepth or requestComplexity.graphQLFields configuration options.
Patches
The fix replaces the per-branch fragment traversal with memoized fragment computation, reducing the traversal from exponential O(2^N) to linear O(N) time. Additionally, early termination aborts the traversal as soon as configured limits are exceeded.
Workarounds
Disable GraphQL complexity limits by setting requestComplexity.graphQLDepth and requestComplexity.graphQLFields to -1 (the default).
Resources
- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-mfj6-6p54-m98c - Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10344 - Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10345
Impact
An authenticated user can 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.
Patches
The truthiness-based guard checks were replaced with key-presence checks that reject any value for protected session fields, including null.
Workarounds
There is no known workaround. A beforeSave trigger on Session could be used to reject null values for expiresAt and createdWith.
Impact
An authenticated user with find class-level permission can bypass the protectedFields class-level permission setting on LiveQuery subscriptions. By sending a subscription with a $or, $and, or $nor operator value as a plain object with numeric keys and a length property (an "array-like" object) instead of an array, the protected-field guard is bypassed. The subscription event firing acts as a binary oracle, allowing the attacker to infer whether a protected field matches a given test value.
Patches
The fix validates that $or, $and, and $nor operator values are arrays in the LiveQuery subscription handler, the query depth checker, and the protected-field guard. As defense in depth, the LiveQuery query evaluator also rejects non-array values for these operators.
Workarounds
There is no known workaround.
Impact
File downloads via HTTP Range requests bypass the afterFind(Parse.File) trigger and its validators on storage adapters that support streaming (e.g. the default GridFS adapter). This allows access to files that should be protected by afterFind trigger authorization logic or built-in validators such as requireUser.
Patches
The streaming file download path now executes the afterFind(Parse.File) trigger before sending any data. Authentication is resolved from the session token header so that trigger validators can distinguish authenticated from unauthenticated requests.
Workarounds
Use beforeFind(Parse.File) instead of afterFind(Parse.File) for file access authorization. The beforeFind trigger runs on all download paths including streaming.
Impact
An attacker can use this prototype pollution sink to trigger a remote code execution through the MongoDB BSON parser.
Patches
Prevent prototype pollution in MongoDB database adapter.
Workarounds
Disable remote code execution through the MongoDB BSON parser.
Credits
- Discovered by hir0ot working with Trend Micro Zero Day Initiative - Fixed by dbythy - Reviewed by mtrezza
References
- https://github.com/parse-community/parse-server/security/advisories/GHSA-462x-c3jw-7vr6 - https://github.com/advisories/GHSA-prm5-8g2m-24gg
Impact
A compromised Parse Server Cloud Code Webhook target endpoint allows an attacker to use prototype pollution to bypass the Parse Server requestKeywordDenylist option.
Patches
Improved keyword detection.
Workarounds
None.
Collaborators
Mikhail Shcherbakov, Cristian-Alexandru Staicu and Musard Balliu working with Trend Micro Zero Day Initiative
References
- https://github.com/parse-community/parse-server/security/advisories/GHSA-93vw-8fm5-p2jf
Impact
Keywords that are specified in the Parse Server option requestKeywordDenylist can be injected via Cloud Code Webhooks or Triggers. This will result in the keyword being saved to the database, bypassing the requestKeywordDenylist option.
Patches
Improved keyword detection.
Workarounds
Configure your firewall to only allow trusted servers to make request to the Parse Server Cloud Code Webhooks API, or block the API completely if you are not using the feature.
Collaborators
Mikhail Shcherbakov, Cristian-Alexandru Staicu and Musard Balliu working with Trend Micro Zero Day Initiative
References - https://github.com/parse-community/parse-server/security/advisories/GHSA-xprv-wvh7-qqqx
Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to version 4.10.4, for regular (non-LiveQuery) queries, the session token is removed from the response, but for LiveQuery payloads it is currently not. If a user has a LiveQuery subscription on the Parse.User class, all session tokens created during user sign-ups will be broadcast as part of the LiveQuery payload. A patch in version 4.10.4 removes session tokens from the LiveQuery payload. As a workaround, set user.acl(new Parse.ACL()) in a beforeSave trigger to make the user private already on sign-up.
Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to version 4.10.3, Parse Server crashes when if a query request contains an invalid value for the explain option. This is due to a bug in the MongoDB Node.js driver which throws an exception that Parse Server cannot catch. There is a patch for this issue in version 4.10.3. No workarounds aside from upgrading are known to exist.
Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Developers can use the REST API to signup users and also allow users to login anonymously. Prior to version 4.5.1, when an anonymous user is first signed up using REST, the server creates session incorrectly. Particularly, the authProvider field in Session class under createdWith shows the user logged in creating a password. If a developer later depends on the createdWith field to provide a different level of access between a password user and anonymous user, the server incorrectly classified the session type as being created with a password. The server does not currently use createdWith to make decisions about internal functions, so if a developer is not using createdWith directly, they are not affected. The vulnerability only affects users who depend on createdWith by using it directly. The issue is patched in Parse Server version 4.5.1. As a workaround, do not use the createdWith Session field to make decisions if one allows anonymous login.
Impact
A race condition in the MFA SMS one-time password (OTP) login path allows two concurrent /login requests carrying the same OTP to both succeed and both receive valid session tokens, breaking the single-use property of the OTP. The vulnerability requires the attacker to already possess the victim's password and intercept the active SMS OTP (e.g. via SIM swap, network mirror, or phishing relay) and to race the legitimate login request, so the practical attack surface is narrow.
This advisory is the same class of incomplete fix as GHSA-2299-ghjr-6vjp (TOTP recovery codes) and GHSA-w73w-g5xw-rwhf (MFA recovery in authData-only login). Those previous fixes added optimistic locking only for array-typed authData fields; SMS MFA stores the OTP as a string, so the guard skipped it.
Patches
The optimistic lock has been generalized to cover primitive (string, number, boolean) and array authData fields. The lock is implemented as a shared helper applyAuthDataOptimisticLock that adds equality predicates on the original values of changed fields to the update WHERE clause. Concurrent writers racing the same single-use token now miss the WHERE condition and surface as Invalid auth data.
Workarounds
- Disable SMS MFA and use TOTP instead (TOTP tokens are time-window validated, not stored single-use). - Place a rate limiter on the /login endpoint to reduce concurrent-request burst capacity.
Resources
- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-jpq4-7fmq-q5fj - Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10448 - Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10449
Impact
The login endpoint response time differs measurably depending on whether the submitted username or email exists in the database. When a user is not found, the server responds immediately. When a user exists but the password is wrong, a bcrypt comparison runs first, adding significant latency. This timing difference allows an unauthenticated attacker to enumerate valid usernames.
Patches
A dummy bcrypt comparison is now performed when no user is found, normalizing response timing regardless of user existence. Additionally, accounts without a stored password (e.g. OAuth-only) now also run a dummy comparison to prevent the same timing oracle.
Workarounds
Configure rate limiting on the login endpoint to slow automated enumeration. This reduces throughput but does not eliminate the timing signal for individual requests.
Impact
An attacker can send an unauthenticated HTTP request with a deeply nested query containing logical operators to permanently hang the Parse Server process. The server becomes completely unresponsive and must be manually restarted. This is a bypass of the fix for CVE-2026-32944.
Patches
The query condition nesting depth is now validated before the query enters the transformation pipeline, preventing deeply nested structures from being recursively processed before the existing depth guard can fire.
Workarounds
None.
Impact
An attacker with master key access can execute arbitrary SQL statements on the PostgreSQL database by injecting SQL metacharacters into field name parameters of the aggregate $group pipeline stage or the distinct operation. This allows privilege escalation from Parse Server application-level administrator to PostgreSQL database-level access.
Only Parse Server deployments using PostgreSQL are affected. MongoDB deployments are not affected.
Patches
Field names in the aggregate $group.id object values and distinct dot-notation parameters are now validated to only contain alphanumeric characters and underscores, preventing SQL injection via the :raw interpolation used in the PostgreSQL storage adapter.
Workarounds
No workaround. Upgrade to a patched version.
Impact
The Pages route and legacy PublicAPI route for resending email verification links return distinguishable responses depending on whether the provided username exists and has an unverified email. This allows an unauthenticated attacker to enumerate valid usernames by observing different redirect targets. The existing emailVerifySuccessOnInvalidEmail configuration option, which is enabled by default and protects the API route against this, did not apply to these routes.
Patches
The email verification resend routes now respect the emailVerifySuccessOnInvalidEmail option. When set to true (the default), both routes redirect to the success page regardless of the outcome, preventing user enumeration.
Workarounds
There is no known workaround to prevent the information disclosure other than upgrading.
Impact
An authentication bypass vulnerability allows an attacker to log in as any user who has linked a third-party authentication provider, without knowing the user's credentials. The attacker only needs to know the user's provider ID to gain full access to their account, including a valid session token.
This affects Parse Server deployments where the server option allowExpiredAuthDataToken is set to true. The default value is false.
Patches
Auth providers are now always validated on login, regardless of the allowExpiredAuthDataToken setting. The option allowExpiredAuthDataToken has been deprecated and will be removed in a future major version.
Workarounds
Set allowExpiredAuthDataToken to false (the default) or remove the option from the server configuration.
Impact
Parse Server's LiveQuery WebSocket interface does not enforce Class-Level Permission (CLP) pointer permissions (readUserFields and pointerFields). Any authenticated user can subscribe to LiveQuery events and receive real-time updates for all objects in classes protected by pointer permissions, regardless of whether the pointer fields on those objects point to the subscribing user. This bypasses the intended read access control, allowing unauthorized access to potentially sensitive data that is correctly restricted via the REST API.
Patches
The LiveQuery server now enforces pointer permissions on each event. After the existing check passes (which defers pointer permissions by design), the fix checks whether any configured pointer field on the object points to the subscribing user. Events for objects that don't match are silently skipped, consistent with how ACL mismatches are handled.
Workarounds
Use ACLs on individual objects to restrict read access instead of relying solely on CLP pointer permissions. ACLs are enforced by LiveQuery.
Impact
An attacker can subscribe to LiveQuery with a watch parameter targeting a protected field. Although the protected field value is properly stripped from event payloads, the presence or absence of update events reveals whether the protected field changed, creating a binary oracle. For boolean protected fields, the timing of change events is equivalent to knowing the field value.
Patches
The watch parameter is now validated against protected fields at subscription time, mirroring the existing validation for the where clause. Subscriptions that include protected fields in watch are rejected with a permission error. Master key connections are exempt.
Workarounds
None.
Impact
Parse Server's LiveQuery component does not enforce the requestComplexity.queryDepth configuration setting when processing WebSocket subscription requests. An attacker can send a subscription with deeply nested logical operators, causing excessive recursion and CPU consumption that degrades or disrupts service availability.
Deployments are affected when the LiveQuery WebSocket endpoint is reachable by untrusted clients.
Patches
The fix adds query condition depth validation to the LiveQuery subscription handler, enforcing the same requestComplexity.queryDepth limit that already protects REST API queries.
Workarounds
There is no known workaround other than upgrading.
Impact
An authenticated user can overwrite server-generated session fields such as expiresAt and createdWith when updating their own session via the REST API. This allows bypassing the server's configured session lifetime policy, making a session effectively permanent.
Patches
The fix blocks authenticated users from setting expiresAt and createdWith fields when updating a session. Master key and maintenance key operations are not affected.
Workarounds
There is no known workaround other than upgrading.
Resources
- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-jc39-686j-wp6q - Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10263 - Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10264
Impact
An unauthenticated attacker can cause Denial of Service by sending authentication requests with arbitrary, unconfigured provider names. The server executes a database query for each unconfigured provider before rejecting the request, and since no database index exists for unconfigured providers, each request triggers a full collection scan on the user database. This can be parallelized to saturate database resources.
Patches
The fix validates that an authentication provider is configured before executing any database query. Requests with unconfigured providers are now rejected immediately without querying the database.
Workarounds
There is no known workaround other than upgrading.
Impact
An attacker who obtains a user's password and a single MFA recovery code can reuse that recovery code an unlimited number of times by sending concurrent login requests. This defeats the single-use design of recovery codes. The attack requires the user's password, a valid recovery code, and the ability to send concurrent requests within milliseconds.
Patches
The login handler now uses optimistic locking when updating auth data that contains consumed single-use tokens. If a concurrent request has already modified the recovery array, the update fails and the login is rejected.
Workarounds
There are no known workarounds.