Parse Server versions <= 8.6.87 and >= 9.0.0 < 9.10.1-alpha.7 contain an authentication bypass in the built-in LDAP authentication adapter. The adapter forwarded the client-supplied password to the directory without verifying that a password had been supplied, and treated any non-error response from the directory as proof of authentication. A zero-length credential turns an LDAP simple bind into the unauthenticated authentication mechanism described in RFC 4513 section 5.1.2, which some directories (including Active Directory in its default configuration) answer with success while mapping the connection to anonymous. As a result, an unauthenticated attacker who knows a directory username can obtain a valid session token for that account, resulting in account takeover. Only deployments that enable the LDAP authentication adapter are affected, and deployments whose directory refuses unauthenticated simple bind (such as a stock OpenLDAP configuration) are not exploitable. The issue is fixed in 8.6.88 and 9.10.1-alpha.7, which require the password to be a non-empty string and reject the request before contacting the directory.

Parse Server versions >= 9.0.0 before 9.10.0-alpha.5 and >= 8.2.2 before 8.6.86 return GraphQL validation error messages that name required custom input fields even when public introspection is disabled (graphQLPublicIntrospection: false, the default). A client holding only the public application id — with no user session, master key, or maintenance key — can trigger validation errors to learn the names of required (non-null) custom fields on classes it already references by name, partially defeating the schema-hiding intent of disabling public introspection. No stored data, credentials, optional field names, unreferenced class names, or Cloud Code function names are exposed.

Parse Server versions >= 9.0.0 before 9.10.0-alpha.6 and >= 8.2.2 before 8.6.87 disclose Pointer and Relation target class names through GraphQL validation and input-coercion error messages when public schema introspection is disabled (graphQLPublicIntrospection: false, the default). Because these errors are produced before authentication, authorization, or any resolver runs, an unauthenticated client possessing only the public application ID can trigger errors on Pointer or Relation fields to reconstruct hidden schema class names, partially defeating the schema-hiding protection. Only schema metadata (class names) is exposed; no object data, credentials, or user records are disclosed.

Parse Server versions >= 9.0.0 before 9.10.0-alpha.4 and versions before 8.6.85 contain a schema disclosure vulnerability. When the GraphQL API is mounted with public introspection disabled (graphQLPublicIntrospection: false, the default), schema-derived 'Did you mean ...?' suggestions were still returned in GraphQL error messages produced during variable coercion, which were not covered by the introspection-hardening control (that only handled validation errors). An unauthenticated caller possessing only the public application id can iteratively recover hidden schema identifiers — including registered Cloud Code function names and Parse class and field names — by submitting queries or mutations whose variables contain near-miss enum values or input-object field names. This is a follow-up bypass of GHSA-8cph-rgr4-g5vj. The issue is fixed in 9.10.0-alpha.4 and 8.6.85.

Parse Server is affected by a stored cross-site scripting (XSS) vulnerability in versions >= 9.0.0, < 9.10.0-alpha.2 and <= 8.6.83. When an uploaded file's extension is not recognized by the mime package, Parse Server preserves the client-supplied Content-Type. A malformed Content-Type that is not a valid type/subtype media type (e.g., 'image', 'image/', or 'image//svg+xml') bypasses the fileUpload.fileExtensions blocklist and is stored unchanged. On storage adapters that persist and serve the uploaded Content-Type (such as Amazon S3, Google Cloud Storage, or Azure Blob Storage), a browser cannot parse the malformed value and falls back to MIME-sniffing; a file whose body begins with HTML is rendered as HTML, executing embedded script in the application's origin against other users who open the file URL. The default GridFS storage adapter is not affected. Fixed in 9.10.0-alpha.2 and 8.6.84.

Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.9.1-alpha.13 and 8.6.83, a LiveQuery subscriber could receive object field values they were not authorized to read when a single save changed both an object field and the subscriber's ACL read access, because leave and enter events included the wrong object state. This issue is fixed in versions 9.9.1-alpha.13 and 8.6.83.

Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.9.1-alpha.12 and 8.6.82, deeply nested $or, $and, and $nor query condition operators in the REST API or LiveQuery query handling could trigger exponential-time processing in the internal query-traversal helper and block the Node.js event loop. This issue is fixed in versions 9.9.1-alpha.12 and 8.6.82.

Parse Server before 4.10.0 was affected by a supply chain incident in which incorrect version tags were pushed to the official repository pointing to an unreviewed personal fork of a contributor with write access. No releases were published with these tags; a project was exposed only if it defined a git-based dependency referencing one of the affected tags (for example, parse-server#4.9.3). The code behind the tags was not reviewed or approved, and although no malicious code was identified, the introduction of security vulnerabilities could not be ruled out.

Parse Server before 4.10.0 contains a supply chain vulnerability where incorrect version tags were pushed to the repository linking to unreviewed code in a personal fork. Attackers could exploit this by specifying affected version tags in dependency declarations to execute unreviewed and potentially malicious code.

Impact

Apps that enable MFA and deny get on the User class via Class-Level Permissions could expose sensitive user data through the /login and /verifyPassword endpoints.

These endpoints re-fetch the user through the access-controlled query pipeline (CLP, protectedFields, auth-adapter sanitizers) before responding. When that re-fetch was denied by the User get permission, the server fell back to the raw database row, exposing raw authData (including MFA TOTP secrets and recovery codes) and fields hidden by protectedFields (when protectedFieldsOwnerExempt is false).

/verifyPassword is the most severe: with only a username and password (no session or MFA token), an attacker who knows a victim's password could retrieve their MFA secret and recovery codes, defeating the second factor.

Only Parse Server 9.8.0 and later are affected; 8.x and earlier are not. Master and maintenance key requests are unaffected, as they bypass these controls by design.

Patches

On a denied re-fetch, /login and /verifyPassword no longer fall back to the raw row; they return only the user's identity (plus the session token for /login). Master and maintenance key callers still receive the full record.

Workarounds

None that preserve the intended User get restriction. Upgrade to a patched version.

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

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

The 3rd party authentication handling of Parse Server allows the authentication credentials of some specific authentication providers to be used across multiple Parse Server apps. For example, if a user signed up using the same authentication provider in two unrelated Parse Server apps, the credentials stored by one app can be used to authenticate the same user in the other app. Note that this only affects Parse Server apps that specifically use an affected 3rd party authentication provider for user authentication, for example by setting the Parse Server option auth to configure a Parse Server authentication adapter. See the 3rd party authentication docs for more information on which authentication providers are affected.

Patches

The fix of this vulnerability requires to upgrade Parse Server to a version that includes the bug fix, as well as upgrade the client app to send a secure payload, which is different from the previous insecure payload. To accommodate a gradual rollout of the client app update, affected Parse Server authentication adapters now offer an enableInsecureAuth option to accept both insecure and secure payloads from clients apps. See the 3rd party authentication docs for how to migrate from insecure to secure authentication.

Workarounds

None.

References - GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-837q-jhwx-cmpv - Parse Server documentation for 3rd party authentication providers: https://docs.parseplatform.org/parse-server/guide/#oauth-and-3rd-party-authentication - Bug fix in Parse Server 7: https://github.com/parse-community/parse-server/pull/9668 - Bug fix in Parse Server 8: https://github.com/parse-community/parse-server/pull/9667