Package Instance

Parse Server vulnerable to SQL Injection via dot-notation sub-key name in `Increment` operation on PostgreSQL
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.

Parse Server vulnerable to stored XSS via file upload of HTML-renderable file types
An attacker can upload a file with a file extension or content type that is not blocked by the default configuration of the Parse Server `fileUpload.fileExtensions` option. The file can contain malicious code, for example JavaScript in an SVG or XHTML file. When the file is accessed via its URL, the browser renders the file and executes the malicious code in the context of the Parse Server domain. This is a stored Cross-Site Scripting (XSS) vulnerability that can be exploited to steal session tokens, redirect users, or perform actions on behalf of other users.

Affected file extensions and content types include `.svgz`, `.xht`, `.xml`, `.xsl`, `.xslt`, and content types `application/xhtml+xml` and `application/xslt+xml` for extensionless uploads. Uploading of `.html`, `.htm`, `.shtml`, `.xhtml`, and `.svg` files was already blocked.

Parse Server has Regular Expression Denial of Service (ReDoS) via `$regex` query in LiveQuery
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.

Parse Server has a protected fields bypass via dot-notation in query and sort
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.

GraphQL API endpoint ignores CORS origin restriction
### 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

Parse Server affected by empty authData bypassing credential requirement on signup
### 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.

Parse Server has a protected fields bypass via LiveQuery subscription WHERE clause
An attacker can exploit LiveQuery subscriptions to infer the values of protected fields without directly receiving them. By subscribing with a WHERE clause that references a protected field (including via dot-notation or `$regex`), the attacker can observe whether LiveQuery events are delivered for matching objects. This creates a boolean oracle that leaks protected field values. The attack affects any class that has both `protectedFields` configured in Class-Level Permissions and LiveQuery enabled.