Impact

An unauthenticated attacker can take over any user account that was created with an authentication provider that does not validate the format of the user identifier (e.g. anonymous authentication). By sending a crafted login request, the attacker can cause the server to perform a pattern-matching query instead of an exact-match lookup, allowing the attacker to match an existing user and obtain a valid session token for that user's account. Both MongoDB and PostgreSQL database backends are affected. Any Parse Server deployment that allows anonymous authentication (enabled by default) is vulnerable.

Patches

The fix enforces that the user identifier in authentication data is a string before using it in a database query. Non-string values are rejected with a validation error.

Workarounds

There is no known workaround.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-5fw2-8jcv-xh87 - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.12 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.38

Impact

Parse Server's built-in OAuth2 auth adapter exports a singleton instance that is reused directly across all OAuth2 provider configurations. Under concurrent authentication requests for different OAuth2 providers, one provider's token validation may execute using another provider's configuration, potentially allowing a token that should be rejected by one provider to be accepted because it is validated against a different provider's policy.

Deployments that configure multiple OAuth2 providers via the oauth2: true flag are affected.

Patches

The fix ensures that a new adapter instance is created for each provider instead of reusing the singleton, so each provider's configuration is isolated.

Workarounds

There is no known workaround. If only a single OAuth2 provider is configured, the race condition cannot occur.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-2cjm-2gwv-m892 - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.11 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.37

Impact

An unauthenticated attacker can crash the Parse Server process by sending a single request with deeply nested query condition operators. This terminates the server and denies service to all connected clients.

Patches

A depth limit for query condition operator nesting has been added via the requestComplexity.queryDepth server option. The option is disabled by default to avoid a breaking change. To mitigate, upgrade and set the option to a value appropriate for your app.

Workarounds

None.

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

An attacker who is allowed to upload files can bypass the file extension filter by appending a MIME parameter (e.g. ;charset=utf-8) to the Content-Type header. This causes the extension validation to fail matching against the blocklist, allowing active content to be stored and served under the application's domain. In addition, certain XML-based file extensions that can render scripts in web browsers are not included in the default blocklist.

This can lead to stored XSS attacks, compromising session tokens, user credentials, or other sensitive data accessible via the browser's local storage.

Patches

The fix strips MIME parameters from the Content-Type header before validating the file extension against the blocklist. The default blocklist has also been extended to include additional XML-based extensions (xsd, rng, rdf, rdf+xml, owl, mathml, mathml+xml) that can render active content in web browsers.

Note that the fileUpload.fileExtensions option is intended to be configured as an allowlist of file extensions that are valid for a specific application, not as a denylist. The default denylist is provided only as a basic default that covers most common problematic extensions. It is not intended to be an exhaustive list of all potentially dangerous extensions. Developers should not rely on the default value, as new extensions that can render active content in browsers might emerge in the future.

Workarounds

Configure the fileUpload.fileExtensions option to use an allowlist of only the file extensions that your application needs, rather than relying on the default blocklist.

Impact

Remote clients can crash the Parse Server process by calling a cloud function endpoint with a crafted function name that traverses the JavaScript prototype chain of a registered cloud function handler, causing a stack overflow.

Patches

The fix restricts property lookups during cloud function name resolution to own properties only, preventing prototype chain traversal from stored function handlers.

Workarounds

There is no known workaround.

Impact

When a Parse.Cloud.afterLiveQueryEvent trigger is registered for a class, the LiveQuery server leaks protected fields and authData to all subscribers of that class. Fields configured as protected via Class-Level Permissions (protectedFields) are included in LiveQuery event payloads for all event types (create, update, delete, enter, leave).

Any user with sufficient CLP permissions to subscribe to the affected class can receive protected field data of other users, including sensitive personal information and OAuth tokens from third-party authentication providers.

Patches

The vulnerability was caused by a reference detachment bug. When an afterEvent trigger is registered, the LiveQuery server converts the event object to a Parse.Object for the trigger, then creates a new JSON copy via toJSONwithObjects(). The sensitive data filter was applied to the Parse.Object reference, but the unfiltered JSON copy was sent to clients. The fix ensures that the JSON copy is assigned back to the response object before filtering, so the filter operates on the actual data sent to clients.

Workarounds

Remove all Parse.Cloud.afterLiveQueryEvent trigger registrations. Without an afterEvent trigger, the reference detachment does not occur and protected fields are correctly filtered.

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

A remote attacker can crash the Parse Server by subscribing to a LiveQuery with an invalid regular expression pattern. The server process terminates when the invalid pattern reaches the regex engine during subscription matching, causing denial of service for all connected clients.

Patches

The fix validates regular expression patterns at subscription time, rejecting invalid patterns before they are stored. Additionally, a defense-in-depth try-catch prevents any subscription matching error from crashing the server process.

Workarounds

Disable LiveQuery if it is not needed.

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 authenticated user calling GET /users/me receives unsanitized auth data, including sensitive credentials such as MFA TOTP secrets and recovery codes. The endpoint internally uses master-level authentication for the session query, and the master context leaks through to the user data, bypassing auth adapter sanitization. An attacker who obtains a user's session token can extract MFA secrets to generate valid TOTP codes indefinitely.

Patches

The /users/me endpoint now queries the session and user data separately, using the caller's authentication context for the user query so that all security layers apply correctly.

Workarounds

There is no known workaround.

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

Any Parse Server deployment that uses the GraphQL API is affected. The GraphQL WebSocket endpoint for subscriptions does not pass requests through the Express middleware chain that enforces authentication, introspection control, and query complexity limits. An attacker can connect to the WebSocket endpoint and execute GraphQL operations without providing a valid application or API key, access the GraphQL schema via introspection even when public introspection is disabled, and send arbitrarily complex queries that bypass configured complexity limits.

Patches

The unfinished GraphQL WebSocket subscription feature has been removed, including the createSubscriptions method and the subscriptions-transport-ws dependency. GraphQL subscriptions were never functional in Parse Server as the schema did not define any subscription types.

Workarounds

Block WebSocket upgrade requests to the GraphQL subscriptions path (by default /subscriptions) at the network level, for example using a reverse proxy or load balancer rule.

Impact

A user can sign up without providing credentials by sending an empty authData object, bypassing the username and password requirement. This allows the creation of authenticated sessions without proper credentials, even when anonymous users are disabled.

Patches

The fix ensures that empty or non-actionable authData is treated the same as absent authData for the purpose of credential validation on new user creation. Username and password are now required when no valid auth provider data is present.

Workarounds

Use a Cloud Code beforeSave trigger on the User class to reject signups where authData is empty and no username/password is provided.

Impact

The OAuth2 authentication adapter does not correctly validate app IDs when appidField and appIds are configured. During app ID validation, a malformed value is sent to the token introspection endpoint instead of the user's actual access token. Depending on the introspection endpoint's behavior, this could either cause all OAuth2 logins to fail, or allow authentication from disallowed app contexts if the endpoint returns valid-looking data for the malformed request.

Deployments using the OAuth2 adapter with appidField and appIds configured are affected.

Patches

The fix corrects the parameter alignment in the OAuth2 adapter's app ID validation method to match the expected interface, ensuring the correct access token is sent to the introspection endpoint.

Workarounds

There is no known workaround.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-69xg-f649-w5g2 - Fix in Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.13 - Fix in Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.39

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

An attacker can bypass the default request keyword denylist protection and the class-level permission for adding fields by sending a crafted request that exploits prototype pollution in the deep copy mechanism. This allows injecting fields into class schemas that have field addition locked down, and can cause permanent schema type conflicts that cannot be resolved even with the master key.

Patches

The vulnerable third-party deep copy library has been replaced with a built-in deep clone mechanism that handles prototype properties safely, allowing the existing denylist check to correctly detect and reject the prohibited keyword.

Workarounds

None.

Vulnerability Independence

This vulnerability is not caused by or dependent on a vulnerability in a third-party dependency.

The third-party deepcopy library that was replaced in the fix has no known CVE or security advisory regarding this. The library functions as designed. It is not vulnerable.

The vulnerability is in parse-server's own request processing logic. Parse-server's security-critical keyword denylist check runs after the deep copy step in the request pipeline. The deep copy step strips proto properties as a normal part of its cloning behavior, which means the denylist check never sees the prohibited key. This allows an attacker to bypass both the denylist protection and class-level permissions for adding fields, resulting in schema poisoning.

The root cause is parse-server's reliance on a cloning mechanism that alters the shape of the data before the security check can inspect it. This is a logic flaw in parse-server's security pipeline, not a vulnerability in a dependency. Replacing the cloning mechanism was the fix for parse-server's own bug.

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 authenticated user can overwrite server-generated session fields (sessionToken, expiresAt, createdWith) when creating a session object via POST /classes/Session. This allows bypassing the server's session expiration policy by setting an arbitrary far-future expiration date. It also allows setting a predictable session token value.

Patches

The session creation endpoint now filters out server-generated fields from user-supplied data, preventing them from being overwritten.

Workarounds

Add a beforeSave trigger on the Session class to validate and reject or strip any user-supplied values for sessionToken, expiresAt, and createdWith.

Impact

The password reset mechanism does not enforce single-use guarantees for reset tokens. When a user requests a password reset, the generated token can be consumed by multiple concurrent requests within a short time window. An attacker who has intercepted a password reset token can race the legitimate user's password reset request, causing both requests to succeed. This may result in the legitimate user believing their password was changed successfully while the attacker's password takes effect instead.

All Parse Server deployments that use the password reset feature are affected.

Patches

The password reset token is now atomically validated and consumed as part of the password update operation. The database query that updates the password includes the reset token as a condition, ensuring that only one concurrent request can successfully consume the token. Subsequent requests using the same token will fail because the token has already been cleared.

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.