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

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

Parse Server's rate limiting middleware is applied at the Express middleware layer, but the batch request endpoint (/batch) processes sub-requests internally by routing them directly through the Promise router, bypassing Express middleware including rate limiting. An attacker can bundle multiple requests targeting a rate-limited endpoint into a single batch request to circumvent the configured rate limit.

Any Parse Server deployment that relies on the built-in rate limiting feature is affected.

Patches

The fix adds a pre-flight check in the batch request handler that counts the number of sub-requests targeting each rate-limited path and rejects the entire batch request if any path's count exceeds its configured requestCount.

Note that this is a server-level rate limit that counts sub-requests within a single batch request. Requests already consumed in the current time window by previous individual or batch requests are not counted against the batch, so the effective limit may be higher when combining individual and batch requests. For comprehensive rate limiting protection, use a reverse proxy or WAF.

Workarounds

Use a reverse proxy or web application firewall (WAF) to enforce rate limiting before requests reach Parse Server.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-775h-3xrc-c228 - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.10 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.23

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

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

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

The validation for protected fields only checks top-level query keys. By wrapping a query constraint on a protected field inside a logical operator, the check is bypassed entirely. This allows any authenticated user to query on protected fields to extract field values.

All Parse Server deployments have default protected fields and are vulnerable.

Patches

The fix adds recursive validation of sub-queries with logical operators, consistent with the existing recursive validation patterns.

Workarounds

Use a beforeFind trigger on affected classes to manually inspect the query for protected field references in logical operator sub-queries and reject the request.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-72hp-qff8-4pvv - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.6 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.19

Impact

The LDAP authentication adapter is vulnerable to LDAP injection. User-supplied input (authData.id) is interpolated directly into LDAP Distinguished Names (DN) and group search filters without escaping special characters. This allows an attacker with valid LDAP credentials to manipulate the bind DN structure and to bypass group membership checks. This enables privilege escalation from any authenticated LDAP user to a member of any restricted group.

The vulnerability affects Parse Server deployments that use the LDAP authentication adapter with group-based access control.

Patches

The vulnerability is fixed by escaping user input before interpolation into DN strings (per RFC 4514) and LDAP filter strings (per RFC 4515).

Workarounds

There is no known workaround.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-7m6r-fhh7-r47c - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.13 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.26

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