| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to versions 8.6.6 and 9.5.0-alpha.4, 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. This issue has been patched in versions 8.6.6 and 9.5.0-alpha.4. |
| Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to versions 8.6.4 and 9.4.1-alpha.3, 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. This issue has been patched in versions 8.6.4 and 9.4.1-alpha.3. |
| Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to versions 8.6.5 and 9.5.0-alpha.3, 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. This issue has been patched in versions 8.6.5 and 9.5.0-alpha.3. |
| Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to versions 8.6.7 and 9.5.0-alpha.6, 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. This issue has been patched in versions 8.6.7 and 9.5.0-alpha.6. |
| Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to versions 8.6.10 and 9.5.0-alpha.11, 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. This issue has been patched in versions 8.6.10 and 9.5.0-alpha.11. |
| Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. From version 9.3.1-alpha.3 to before version 9.5.0-alpha.10, 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. This issue has been patched in version 9.5.0-alpha.10. |
| Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to versions 8.6.9 and 9.5.0-alpha.9, 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 issue has been patched in versions 8.6.9 and 9.5.0-alpha.9. |
| Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to versions 8.6.8 and 9.5.0-alpha.8, 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 issue has been patched in versions 8.6.8 and 9.5.0-alpha.8. |
| Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to versions 8.6.3 and 9.1.1-alpha.4, 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. The fix in versions 8.6.3 and 9.1.1-alpha.4 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. As a workaround, dsable Google authentication until upgrading is possible. |
| Parse Dashboard is a standalone dashboard for managing Parse Server apps. In versions 7.3.0-alpha.42 through 9.0.0-alpha.7, the AI Agent API endpoint (POST `/apps/:appId/agent`) has multiple security vulnerabilities that, when chained, allow unauthenticated remote attackers to perform arbitrary read and write operations against any connected Parse Server database using the master key. The agent feature is opt-in; dashboards without an agent config are not affected. The fix in version 9.0.0-alpha.8 adds authentication, CSRF validation, and per-app authorization middleware to the agent endpoint. Read-only users are restricted to the `readOnlyMasterKey` with write permissions stripped server-side. A cache key collision between master key and read-only master key was also corrected. As a workaround, remove or comment out the agent configuration block from your Parse Dashboard configuration. |
| Parse Dashboard is a standalone dashboard for managing Parse Server apps. In versions 7.3.0-alpha.42 through 9.0.0-alpha.7, the AI Agent API endpoint (`POST /apps/:appId/agent`) does not enforce authorization. Authenticated users scoped to specific apps can access any other app's agent endpoint by changing the app ID in the URL. Read-only users are given the full master key instead of the read-only master key and can supply write permissions in the request body to perform write and delete operations. Only dashboards with `agent` configuration enabled are affected. The fix in version 9.0.0-alpha.8 adds per-app authorization checks and restricts read-only users to the `readOnlyMasterKey` with write permissions stripped server-side. As a workaround, remove the `agent` configuration block from your dashboard configuration. Dashboards without an `agent` config are not affected. |
| Parse Dashboard is a standalone dashboard for managing Parse Server apps. In versions 7.3.0-alpha.42 through 9.0.0-alpha.7, the AI Agent API endpoint (`POST /apps/:appId/agent`) lacks CSRF protection. An attacker can craft a malicious page that, when visited by an authenticated dashboard user, submits requests to the agent endpoint using the victim's session. The fix in version 9.0.0-alpha.8 adds CSRF middleware to the agent endpoint and embeds a CSRF token in the dashboard page. As a workaround, remove the `agent` configuration block from your dashboard configuration. Dashboards without an `agent` config are not affected. |
| Parse Dashboard is a standalone dashboard for managing Parse Server apps. In versions 7.3.0-alpha.42 through 9.0.0-alpha.7, the `ConfigKeyCache` uses the same cache key for both master key and read-only master key when resolving function-typed keys. Under specific timing conditions, a read-only user can receive the cached full master key, or a regular user can receive the cached read-only master key. The fix in version 9.0.0-alpha.8 uses distinct cache keys for master key and read-only master key. As a workaround, avoid using function-typed master keys, or remove the `agent` configuration block from your dashboard configuration. |
| Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. If the Parse Server option allowCustomObjectId: true is set, an attacker that is allowed to create a new user can set a custom object ID for that new user that exploits the vulnerability and acquires privileges of a specific role. This vulnerability is fixed in 6.5.9 and 7.3.0. |
| Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. In versions prior to 8.6.1 and 9.1.0-alpha.3, a Reflected Cross-Site Scripting (XSS) vulnerability exists in Parse Server's password reset and email verification HTML pages. The patch, available in versions 8.6.1 and 9.1.0-alpha.3, escapes user controlled values that are inserted into the HTML pages. No known workarounds are available. |
| Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to versions 8.6.2 and 9.1.1-alpha.1, 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. This is fixed in versions 8.6.2 and 9.1.1-alpha.1 by hardcoding the Instagram Graph API URL `https://graph.instagram.com` and ignoring client-provided `apiURL` values. No known workarounds are available. |
| Parse Server is an open source backend that can be deployed to any infrastructure that runs Node.js. In versions prior to 8.6.0-alpha.2, a GitHub CI workflow is triggered in a way that grants the GitHub Actions workflow elevated permissions, giving it access to GitHub secrets and write permissions which are defined in the workflow. Code from a fork or lifecycle scripts is potentially included. Only the repository's CI/CD infrastructure is affected, including any public GitHub forks with GitHub Actions enabled. This issue is fixed version 8.6.0-alpha.2 and commits 6b9f896 and e3d27fe. |
| Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to versions 6.5.5 and 7.0.0-alpha.29, calling an invalid Parse Server Cloud Function name or Cloud Job name crashes the server and may allow for code injection, internal store manipulation or remote code execution. The patch in versions 6.5.5 and 7.0.0-alpha.29 added string sanitation for Cloud Function name and Cloud Job name. As a workaround, sanitize the Cloud Function name and Cloud Job name before it reaches Parse Server. |
| parse-server is a Parse Server for Node.js / Express. This vulnerability allows SQL injection when Parse Server is configured to use the PostgreSQL database. The vulnerability has been fixed in 6.5.0 and 7.0.0-alpha.20.
|
| Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. The MongoDB `explain()` method provides detailed information about query execution plans, including index usage, collection scanning behavior, and performance metrics. Prior to version 8.5.0-alpha.5, Parse Server permits any client to execute explain queries without requiring the master key. This exposes database schema structure and field names, index configurations and query optimization details, query execution statistics and performance metrics, and potential attack vectors for database performance exploitation. In version 8.5.0-alpha.5, a new `databaseOptions.allowPublicExplain` configuration option has been introduced that allows to restrict `explain` queries to the master key. The option defaults to `true` for now to avoid a breaking change in production systems that depends on public `explain` availability. In addition, a security warning is logged when the option is not explicitly set, or set to `true`. In a future major release of Parse Server, the default will change to `false`. As a workaround, implement middleware to block explain queries from non-master-key requests, or monitor and alert on explain query usage in production environments. |
