Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
117 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact When multi-factor authentication (MFA) via TOTP is enabled for a user account, Parse Server generates two single-use recovery codes. These codes are intended as a fallback when the user cannot provide a TOTP token. However, recovery codes are not consumed after use, allowing the same recovery code to be used an unlimited number of times. This defeats the single-use design of recovery codes and weakens the security of MFA-protected accounts. An attacker who obtains a single recovery code can repeatedly authenticate as the affected user without the code ever being invalidated. Patches The fix ensures that each recovery code is removed from the stored recovery code list after a successful login. Workarounds There is no known workaround. References - GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-4hf6-3x24-c9m8 - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.7 - Fix Parse Server 8:…
Recommended action: Upgrade to 9.6.0-alpha.7 (pre-release) or 8.6.33 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. Patches The fix ensures that query WHERE clause keys and sort keys are checked against protected fields by extracting the root field from dot-notation paths. For example, a query on secretObj.apiKey is now correctly blocked when secretObj is a protected field. Workarounds None. References - GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-r2m8-pxm9-9c4g - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.6 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.32
Recommended action: Upgrade to 9.6.0-alpha.6 (pre-release) or 8.6.32 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. Patches The fix escapes single quotes in the sub-key name before interpolating it into the SQL query, preventing breakout from SQL string literals. Workarounds There is no known workaround. References - GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-gqpp-xgvh-9h7h - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.5 - Fix Parse Server 8:…
Recommended action: Upgrade to 9.6.0-alpha.5 (pre-release) or 8.6.31 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. Patches The fix adds the missing file extensions and content types to the default value of the fileUpload.fileExtensions server option. Workarounds Configure the…
Recommended action: Upgrade to 9.6.0-alpha.4 (pre-release) or 8.6.30 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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 amount value is interpolated directly into the SQL query without parameterization or type validation. An attacker who can send write requests to the Parse Server REST API can inject arbitrary SQL subqueries to read any data from the database, bypassing CLPs and ACLs. MongoDB deployments are not affected. Patches The fix adds type validation to reject non-number values and parameterizes the value in the SQL query instead of interpolating it. Workarounds There is no known workaround. References - GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-q3vj-96h2-gwvg - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.3 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.29
Recommended action: Upgrade to 9.6.0-alpha.3 (pre-release) or 8.6.29 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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:…
Recommended action: Upgrade to 9.5.2-alpha.13 (pre-release) or 8.6.26 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 9.5.2-alpha.12 (pre-release) or 8.6.25 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 9.5.2-alpha.10 (pre-release) or 8.6.23 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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:…
Recommended action: Upgrade to 9.5.2-alpha.9 (pre-release) or 8.6.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 9.5.2-alpha.7 (pre-release) or 8.6.20 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 9.5.2-alpha.8 (pre-release) or 8.6.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 9.5.2-alpha.6 (pre-release) or 8.6.19 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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:…
Recommended action: Upgrade to 9.5.2-alpha.5 (pre-release) or 8.6.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: References - GitHub security advisory:…
Recommended action: Upgrade to 9.5.2-alpha.4 (pre-release) or 8.6.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 9.5.2-alpha.3 (pre-release) or 8.6.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 Requests using master key or maintenance key bypass these limits. Set any property to -1 to disable that specific limit. In versions 8.6.15 and 9.5.2-alpha.2, these limits were enabled by default. This unintentionally introduced a…
Recommended action: Upgrade to 9.5.2-alpha.2 (pre-release) or 8.6.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A NoSQL injection vulnerability allows an unauthenticated attacker to inject MongoDB query operators via the token field in the password reset and email verification resend endpoints. The token value is passed to database queries without type validation and can be used to extract password reset and email verification tokens. Any Parse Server deployment using MongoDB with email verification or password reset enabled is affected. When emailVerifyTokenReuseIfValid is configured, the email verification token can be fully extracted and used to verify a user's email address without inbox access. Patches Patches The vulnerability is fixed by adding input type validation at the endpoint level. Workarounds There is no known workaround. References - GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-vgjh-hmwf-c588 - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.1 - Fix Parse Server 8:…
Recommended action: Upgrade to 9.5.2-alpha.1 (pre-release) or 8.6.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An attacker can use a dot-notation field name in combination with the sort query parameter to inject SQL into the PostgreSQL database through an improper escaping of sub-field values in dot-notation queries. The vulnerability may also affect queries that use dot-notation field names with the distinct and where query parameters. This vulnerability only affects deployments using a PostgreSQL database. Patches The fix escapes characters in dot-notation sub-field values that could allow a SQL breakout. Workarounds There is no known workaround. References - GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-qpr4-jrj4-6f27 - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.2 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.28
Recommended action: Upgrade to 9.6.0-alpha.2 (pre-release) or 8.6.28 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An unauthenticated attacker can crash the Parse Server process by calling a Cloud Function endpoint with a prototype property name as the function name. The server recurses infinitely, causing a call stack size error that terminates the process. Other prototype property names bypass Cloud Function dispatch validation and return HTTP 200 responses, even though no such Cloud Functions are defined. The same applies to dot-notation traversal. All Parse Server deployments that expose the Cloud Function endpoint are affected. Patches The internal handler registries for Cloud Functions, Jobs, Triggers, and Validators have been changed to prevent prototype chain properties from being resolved. Workarounds Place a reverse proxy or WAF in front of Parse Server and block requests to Object.prototype property names. References - GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-5j86-7r7m-p8h6 - Fix Parse Server 9:…
Recommended action: Upgrade to 9.5.1-alpha.2 (pre-release) or 8.6.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The requestKeywordDenylist security control can be bypassed by placing any nested object or array before a prohibited keyword in the request payload. This is caused by a logic bug that stops scanning sibling keys after encountering the first nested value. Any custom requestKeywordDenylist entries configured by the developer are equally by-passable using the same technique. All Parse Server deployments are affected. The requestKeywordDenylist is enabled by default. Patches The fix replaces the recursive object scanner with an iterative stack-based traversal that processes all nested values without prematurely exiting the scan loop. This also eliminates a potential stack overflow on deeply nested payloads. Workarounds Use a Cloud Code beforeSave trigger to validate incoming data for prohibited keywords across all classes. References - GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-q342-9w2p-57fp - Fix Parse Server 9:…
Recommended action: Upgrade to 9.5.1-alpha.1 (pre-release) or 8.6.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 9.5.0-alpha.14 (pre-release) or 8.6.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 9.5.0-alpha.11 (pre-release) or 8.6.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 9.5.0-alpha.10 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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:…
Recommended action: Upgrade to 9.5.0-alpha.9 (pre-release) or 8.6.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 9.5.0-alpha.8 (pre-release) or 8.6.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.