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

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

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

The readOnlyMasterKey can be used to create and delete files via the Files API (POST /files/:filename, DELETE /files/:filename). This bypasses the read-only restriction which violates the access scope of the readOnlyMasterKey.

Any Parse Server deployment that uses readOnlyMasterKey and exposes the Files API is affected. An attacker with access to the readOnlyMasterKey can upload arbitrary files or delete existing files.

Patches

The fix adds permission checks to both the file upload and file delete handlers.

Workarounds

There is no workaround other than not using readOnlyMasterKey, or restricting network access to the Files API endpoints.

References - GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-xfh7-phr7-gr2x - Fix for Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.3 - Fix for Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.5

Impact

A malformed $regex query parameter (e.g. [abc) causes the database to return a structured error object that is passed unsanitized through the API response. This leaks database internals such as error messages, error codes, code names, cluster timestamps, and topology details. The vulnerability is exploitable by any client that can send query requests, depending on the deployment's permission configuration.

Patches

The fix sanitizes database error objects so that only a generic "An internal server error occurred" message is returned to clients, while the detailed error is logged server-side. The fix respects the enableSanitizedErrorResponse server option.

Workarounds

There is no workaround other than upgrading. The error leakage occurs in the query execution layer and cannot be mitigated through server configuration or client-side changes.

Resources

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-9cp7-3q5w-j92g - Fix in Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.6 - Fix in Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.7

Impact

When graphQLPublicIntrospection is disabled, type queries nested inside inline fragments (e.g. ... on Query { type(name:"User") { name } }) bypass the introspection control, allowing unauthenticated users to perform type reconnaissance. schema introspection is not affected.

Patches

The check was changed from a flat iteration over root-level selections to a recursive walk of all selection sets, detecting type inside inline fragments at any depth.

Workarounds

Require master key authentication at the network layer (e.g. reverse proxy) for the GraphQL endpoint.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-q5q9-2rhp-33qw - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.10

Impact

The PagesRouter static file serving route is vulnerable to a path traversal attack that allows unauthenticated reading of files outside the configured pagesPath directory. The boundary check uses a string prefix comparison without enforcing a directory separator boundary. An attacker can use path traversal sequences to access files in sibling directories whose names share the same prefix as the pages directory (e.g. pages-secret starts with pages).

This affects any Parse Server deployment with the pages feature enabled (pages.enableRouter: true). Exploitation requires a sibling directory of pagesPath whose name begins with the same string as the pages directory name.

Patches

The fix enforces a path separator boundary in the check, ensuring resolved paths must be strictly inside the pagesPath directory.

Workarounds

Ensure the pagesPath directory has no sibling directories whose names begin with the same prefix. For example, if pagesPath is /srv/pages, ensure no directory like /srv/pages-backup or /srv/pagesold exists alongside it.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-hm3f-q6rw-m6wh - Fix for Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.8 - Fix for Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.8

Impact

The file metadata endpoint (GET /files/:appId/metadata/:filename) does not enforce beforeFind / afterFind file triggers. When these triggers are used as access-control gates, the metadata endpoint bypasses them entirely, allowing unauthorized access to file metadata.

This affects any deployment that relies on Parse.Cloud.beforeFind(Parse.File, ...) to restrict file access. Only file metadata (user-defined key-value pairs set via addMetadata) is exposed; file content remains protected.

Patches

The metadata handler now runs beforeFind and afterFind triggers and returns HTTP 403 when a trigger denies access.

Workarounds

Disable the metadata endpoint by overriding the route with a middleware that rejects all requests:

js // Add before mounting Parse Server app.get('/parse/files/:appId/metadata/:filename', (req, res) => { res.status(403).json({ error: 'Forbidden' }); });

Adjust the path prefix (/parse) to match your mountPath.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-hwx8-q9cg-mqmc - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.9 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.9