Impact

Parse Server's internal tables, which store Relation field mappings such as role memberships, can be directly accessed via the REST API or GraphQL API by any client using only the application key. No master key is required.

An attacker can create, read, update, or delete records in any internal relationship table. Exploiting this allows the attacker to inject themselves into any Parse Role, gaining all permissions associated with that role, including full read, write, and delete access to classes protected by role-based Class-Level Permissions (CLP). Similarly, writing to any such table that backs a Relation field used in a pointerFields CLP bypasses that access control.

Patches

The fix blocks direct client access to internal relationship tables in Parse Server's role security enforcement. All create, find, get, update, and delete operations on these tables now require the master key or maintenance key.

Workarounds

There is no known workaround.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-5f92-jrq3-28rc - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.7 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.20

Impact

A vulnerability in Parse Server's query handling allows an authenticated or unauthenticated attacker to exfiltrate session tokens of other users by exploiting the redirectClassNameForKey query parameter. Exfiltrated session tokens can be used to take over user accounts.

The vulnerability requires the attacker to be able to create or update an object with a new relation field, which depends on the Class-Level Permissions of at least one class.

Patches

The fix applies the same security checks that normally protect class access after the query redirect, ensuring that queries redirected via redirectClassNameForKey are subject to the same restrictions as direct queries to the target class.

Workarounds

Set restrictive Class-Level Permissions to prevent clients from creating new fields on classes, specifically by disabling addField for public access and unauthenticated users. Note that this limits client functionality and does not fully eliminate the risk if a relation field pointing to a protected class already exists in the schema.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-6r2j-cxgf-495f - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.8 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.21

Impact

The Google, Apple, and Facebook authentication adapters use JWT verification to validate identity tokens. When the adapter's audience configuration option is not set (clientId for Google/Apple, appIds for Facebook), JWT verification silently skips audience claim validation. This allows an attacker to use a validly signed JWT issued for a different application to authenticate as any user on the target Parse Server.

- For Google and Apple, the vulnerability is exploitable when the server does not configure clientId. The adapters accepted this as valid and simply skipped audience validation. - For Facebook Limited Login, the vulnerability exists regardless of configuration. The adapter validated appIds only for Standard Login (Graph API), but the Limited Login JWT path never passed appIds as the audience to JWT verification.

Patches

The fix enforces clientId (Google/Apple) and appIds (Facebook) as mandatory and passes them to JWT verification for audience validation. While this is technically a breaking change for servers that omit these options, it is not a breaking change as per documentation — all three options are documented as required configuration.

Workarounds

- Google / Apple: Ensure clientId is set in the adapter configuration. When set, JWT verification correctly validates the audience claim even on unpatched versions. - Facebook Limited Login: There is no workaround. The unpatched adapter does not pass appIds to JWT audience validation, so the only mitigation is to upgrade.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-x6fw-778m-wr9v - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.11 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.10

Impact

An attacker can use a dot-notation field name in combination with the sort query parameter to inject SQL into the PostgreSQL database through an improper escaping of sub-field values in dot-notation queries. The vulnerability may also affect queries that use dot-notation field names with the distinct and where query parameters.

This vulnerability only affects deployments using a PostgreSQL database.

Patches

The fix escapes characters in dot-notation sub-field values that could allow a SQL breakout.

Workarounds

There is no known workaround.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-qpr4-jrj4-6f27 - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.2 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.28

Impact

A SQL injection vulnerability exists in the PostgreSQL storage adapter when processing Increment operations on nested object fields using dot notation (e.g., stats.counter). The amount value is interpolated directly into the SQL query without parameterization or type validation. An attacker who can send write requests to the Parse Server REST API can inject arbitrary SQL subqueries to read any data from the database, bypassing CLPs and ACLs.

MongoDB deployments are not affected.

Patches

The fix adds type validation to reject non-number values and parameterizes the value in the SQL query instead of interpolating it.

Workarounds

There is no known workaround.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-q3vj-96h2-gwvg - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.3 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.29

Impact

A SQL injection vulnerability exists in the PostgreSQL storage adapter when processing Increment operations on nested object fields using dot notation (e.g., stats.counter). The sub-key name is interpolated directly into SQL string literals without escaping. An attacker who can send write requests to the Parse Server REST API can inject arbitrary SQL via a crafted sub-key name containing single quotes, potentially executing commands or reading data from the database, bypassing CLPs and ACLs.

Only Postgres deployments are affected.

Patches

The fix escapes single quotes in the sub-key name before interpolating it into the SQL query, preventing breakout from SQL string literals.

Workarounds

There is no known workaround.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-gqpp-xgvh-9h7h - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.5 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.31

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

An unauthenticated attacker can forge a Google authentication token with alg: "none" to log in as any user linked to a Google account, without knowing their credentials. All deployments with Google authentication enabled are affected.

Patches

The fix hardcodes the expected RS256 algorithm instead of trusting the JWT header, and replaces the Google adapter's custom key fetcher with jwks-rsa which rejects unknown key IDs.

Workarounds

Disable Google authentication until you can upgrade.

References

- GitHub advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-4q3h-vp4r-prv2 - Fixed in Parse Server 9.3.1-alpha.4: https://github.com/parse-community/parse-server/releases/tag/9.3.1-alpha.4 - Fixed in Parse Server 8.6.3: https://github.com/parse-community/parse-server/releases/tag/8.6.3

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

An unauthenticated attacker can crash the Parse Server process by calling a Cloud Function endpoint with a prototype property name as the function name. The server recurses infinitely, causing a call stack size error that terminates the process.

Other prototype property names bypass Cloud Function dispatch validation and return HTTP 200 responses, even though no such Cloud Functions are defined. The same applies to dot-notation traversal.

All Parse Server deployments that expose the Cloud Function endpoint are affected.

Patches

The internal handler registries for Cloud Functions, Jobs, Triggers, and Validators have been changed to prevent prototype chain properties from being resolved.

Workarounds

Place a reverse proxy or WAF in front of Parse Server and block requests to Object.prototype property names.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-5j86-7r7m-p8h6 - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.1-alpha.2 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.13

Impact

The Keycloak authentication adapter does not validate the azp (authorized party) claim of Keycloak access tokens against the configured client-id. A valid access token issued by the same Keycloak realm for a different client application can be used to authenticate as any user on the Parse Server that uses the Keycloak adapter. This enables cross-application account takeover in multi-client Keycloak realms.

All Parse Server deployments that use the Keycloak authentication adapter with a Keycloak realm that has multiple client applications are affected.

Patches

The fix replaces the userinfo HTTP call with local JWT verification and enforces azp claim validation against the configured client-id.

Workarounds

None.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-48mh-j4p5-7j9v - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.5 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.18

Impact

The GraphQLConfig and Audience internal classes can be read, modified, and deleted via the generic /classes/GraphQLConfig and /classes/Audience REST API routes without master key authentication. This bypasses the master key enforcement that exists on the dedicated /graphql-config and /pushaudiences endpoints. An attacker can read, modify and delete GraphQL configuration and push audience data.

Patches

The fix adds the affected internal classes to the classesWithMasterOnlyAccess list, ensuring that the generic /classes/ routes enforce master key access consistently with the dedicated endpoints.

Workarounds

There is no known workaround.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-7xg7-rqf6-pw6c - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.12 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.25

Impact

The OAuth2 authentication adapter, when configured without the useridField option, only verifies that a token is active via the provider's token introspection endpoint, but does not verify that the token belongs to the user identified by authData.id. An attacker with any valid OAuth2 token from the same provider can authenticate as any other user.

This affects any Parse Server deployment that uses the generic OAuth2 authentication adapter (configured with oauth2: true) without setting the useridField option.

Patches

The vulnerability is fixed by defaulting useridField to sub, which is the standard subject identifier field defined by RFC 7662. The adapter now always validates the token's identity against the claimed user ID, even when useridField is not explicitly configured.

Workarounds

Set the useridField option to the appropriate field name for your OAuth2 provider (e.g. sub) in the Parse Server authentication configuration.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-fr88-w35c-r596 - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.9 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.22

Impact

A NoSQL injection vulnerability allows an unauthenticated attacker to inject MongoDB query operators via the token field in the password reset and email verification resend endpoints. The token value is passed to database queries without type validation and can be used to extract password reset and email verification tokens.

Any Parse Server deployment using MongoDB with email verification or password reset enabled is affected. When emailVerifyTokenReuseIfValid is configured, the email verification token can be fully extracted and used to verify a user's email address without inbox access.

Patches

Patches

The vulnerability is fixed by adding input type validation at the endpoint level.

Workarounds

There is no known workaround.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-vgjh-hmwf-c588 - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.1 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.14

Impact

An unauthenticated attacker can exhaust Parse Server resources (CPU, memory, database connections) through crafted queries that exploit the lack of complexity limits in the REST and GraphQL APIs.

All Parse Server deployments using the REST or GraphQL API are affected.

Patches

The vulnerability is fixed by introducing configurable request complexity limits via the requestComplexity server option with the following keys:

- subqueryDepth: Maximum nesting depth for $inQuery, $notInQuery, $select, $dontSelect - includeDepth: Maximum depth of dot-separated include paths - includeCount: Maximum number of include fields per query - graphQLDepth: Maximum depth of GraphQL field selections - graphQLFields: Maximum number of field selections in a GraphQL query

If the server options are not set their default values apply to fix the vulnerability. Requests using master key or maintenance key bypass these limits. Set any property to -1 to disable that specific limit.

Workarounds

There is no known workaround.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-cmj3-wx7h-ffvg - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.2 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.15

Impact

Class-level permissions (CLP) are not enforced for LiveQuery subscriptions. An unauthenticated or unauthorized client can subscribe to any LiveQuery-enabled class and receive real-time events for all objects, regardless of CLP restrictions.

All Parse Server deployments that use LiveQuery with class-level permissions are affected. Data intended to be restricted by CLP is leaked to unauthorized subscribers in real time.

Patches

The fix enforces CLP before creating the subscription and during event delivery.

Workarounds

Disable LiveQuery for classes that use CLP restrictions by removing them from the liveQuery.classNames server configuration.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-7ch5-98q2-7289 - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.3 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.16

Impact

The protectedFields class-level permission (CLP) can be bypassed using dot-notation in query WHERE clauses and sort parameters. An attacker can use dot-notation to query or sort by sub-fields of a protected field, enabling a binary oracle attack to enumerate protected field values.

This affects both MongoDB and PostgreSQL deployments.

Patches

The fix ensures that query WHERE clause keys and sort keys are checked against protected fields by extracting the root field from dot-notation paths. For example, a query on secretObj.apiKey is now correctly blocked when secretObj is a protected field.

Workarounds

None.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-r2m8-pxm9-9c4g - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.6 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.32

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

Parse Server's readOnlyMasterKey option allows access with master-level read privileges but is documented to deny all write operations. However, some endpoints incorrectly accept the readOnlyMasterKey for mutating operations. This allows a caller who only holds the readOnlyMasterKey to create, modify, and delete Cloud Hooks and to start Cloud Jobs, which can be used for data exfiltration.

Any Parse Server deployment that uses the readOnlyMasterKey option is affected. Note than an attacker needs to know the readOnlyMasterKey to exploit this vulnerability.

Patches

The fix adds authorization checks, rejecting mutating requests made with the readOnlyMasterKey.

Workarounds

There is no known workaround other than upgrading. If upgrading is not immediately possible, ensure the readOnlyMasterKey value is not shared with untrusted parties.

Resources

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-vc89-5g3r-cmhh - Fixed in Parse Server 9.4.1-alpha.3: https://github.com/parse-community/parse-server/releases/tag/9.4.1-alpha.3 - Fixed in Parse Server 8.6.4: https://github.com/parse-community/parse-server/releases/tag/8.6.4

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 readOnlyMasterKey can call POST /loginAs to obtain a valid session token for any user. This allows a read-only credential to impersonate arbitrary users with full read and write access to their data. Any Parse Server deployment that uses readOnlyMasterKey is affected.

Patches

The fix adds a check to the /logInAs handler.

Workarounds

There is no workaround other than not using readOnlyMasterKey.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-79wj-8rqv-jvp5 - Fix for Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.4 - Fix for Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.6

Impact

The Instagram authentication adapter allows clients to specify a custom API URL via the apiURL parameter in authData. This enables SSRF attacks and possibly authentication bypass if malicious endpoints return fake responses to validate unauthorized users.

Patches

Fixed by hardcoding the Instagram Graph API URL https://graph.instagram.com and ignoring client-provided apiURL values.

Workarounds

None.

Impact

A stored cross-site scripting (XSS) vulnerability allows any authenticated user to upload an SVG file containing JavaScript. The file is served inline with Content-Type: image/svg+xml and without protective headers, causing the browser to execute embedded scripts in the Parse Server origin. This can be exploited to steal session tokens from localStorage and achieve account takeover.

The default fileExtensions option blocks HTML file extensions but does not block SVG, which is a well-known XSS vector. All Parse Server deployments where file upload is enabled for authenticated users (the default) are affected.

Patches

The fix adds svg (case-insensitive) to the default file extension denylist. The default regex changes from ^(?![xXsS]?[hH][tT][mM][lL]?$) to ^(?!([xXsS]?[hH][tT][mM][lL]?|[sS][vV][gG])$).

Workarounds

Configure the fileExtensions option to explicitly block SVG uploads:

js { fileUpload: { fileExtensions: ['^(?!([xXsS]?[hH][tT][mM][lL]?|[sS][vV][gG])$)'] } }

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-hcj7-6gxh-24ww - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.4 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.17

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

A malicious client can subscribe to a LiveQuery with a crafted $regex pattern that causes catastrophic backtracking, blocking the Node.js event loop. This makes the entire Parse Server unresponsive, affecting all clients. Any Parse Server deployment with LiveQuery enabled is affected. The attacker only needs the application ID and JavaScript key, both of which are public in client-side apps.

This only affects LiveQuery subscription matching, which evaluates regex in JavaScript on the Node.js event loop. Normal REST and GraphQL queries are not affected because their regex is evaluated by the database engine.

Patches

Regex evaluation in LiveQuery subscription matching now runs in an isolated VM context with a configurable timeout via a new Parse Server option liveQuery.regexTimeout, with defaults 100 ms. A regex that exceeds the timeout is treated as non-matching.

The protection adds approximately 50 microseconds of overhead per regex evaluation. For most applications this is negligible, but it can add up if there is a very large number of LiveQuery subscriptions that use $regex on the same class. For example, 10,000 concurrent regex subscriptions would add approximately 500ms of processing time per object save event on that class. Set liveQuery.regexTimeout: 0 to disable the protection and use native regex evaluation without overhead.

Workarounds

Use the beforeSubscribe Cloud Code hook to reject any LiveQuery subscription that contains a $regex operator. Note that this also blocks the LiveQuery startsWith, endsWith, and contains query methods, as they use $regex internally.

js // Repeat for each class that is used with LiveQuery Parse.Cloud.beforeSubscribe('MyClass', request => { const where = request.query.where || {}; for (const value of Object.values(where)) { if (value?.$regex) { throw new Parse.Error(Parse.Error.OPERATIONFORBIDDEN, '$regex not allowed in LiveQuery subscriptions'); } } });

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-mf3j-86qx-cq5j - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.14 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.11

Impact

When multi-factor authentication (MFA) via TOTP is enabled for a user account, Parse Server generates two single-use recovery codes. These codes are intended as a fallback when the user cannot provide a TOTP token. However, recovery codes are not consumed after use, allowing the same recovery code to be used an unlimited number of times. This defeats the single-use design of recovery codes and weakens the security of MFA-protected accounts.

An attacker who obtains a single recovery code can repeatedly authenticate as the affected user without the code ever being invalidated.

Patches

The fix ensures that each recovery code is removed from the stored recovery code list after a successful login.

Workarounds

There is no known workaround.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-4hf6-3x24-c9m8 - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.7 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.33

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.