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 Parse Server's file upload validation uses the `fileUpload.fileExtensions` option (enabled by default with a blocklist) to reject files that browsers may render as active content, mitigating stored cross-site scripting (XSS). When an uploaded file's extension is not recognized by the `mime` package, Parse Server preserves the client-supplied `Content-Type` and passes it to the storage adapter. A malformed `Content-Type` that is not a valid `type/subtype` media type — for example `image` (no subtype), `image/` (empty subtype), or `image//svg+xml` (invalid token) — bypassed the blocklist and was 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 `Content-Type` and falls back to MIME-sniffing the file content; a file whose body begins with HTML markup is then rendered as HTML, executing any embedded script in the application's origin.…
Recommended action: Upgrade to 9.10.0-alpha.2 (pre-release) or 8.6.84 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 Parse Server LiveQuery subscriber can receive object field values they are not authorized to read when a single save changes both an object field and the subscriber's ACL read access to that object. When such a save removes the subscriber's read access, the resulting leave event still carries the post-update object body, disclosing the new field values the subscriber is no longer permitted to read. The symmetric case applies to the enter event: when a save grants read access, the event includes the pre-grant object state the subscriber was not previously permitted to read. The disclosure is bounded to the single object affected by that save and is delivered only to the subscriber whose access changed. Applications that combine content changes with access-control changes in the same save on LiveQuery-enabled classes are affected. Patches Parse Server now verifies the subscriber's authorization for the specific object state included in leave and enter events. For a leave…
Recommended action: Upgrade to 9.9.1-alpha.13 (pre-release) or 8.6.83 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 default fileUpload.fileExtensions blocklist is intended to prevent uploading files that browsers render as active content (such as HTML and SVG), which can be used to perform stored cross-site scripting (XSS) attacks against other users. The blocklist could be bypassed by uploading a file whose extension is not an exact match of a blocked extension (for example a non-standard or compound extension) together with a dangerous content type. On storage adapters that persist and serve the uploaded content type (such as S3 and GCS), the file is then served with the attacker-supplied content type, enabling stored XSS against users who open the file URL. This affects the default configuration, in which authenticated users are allowed to upload files. The default GridFS/filesystem adapter sets the X-Content-Type-Options: nosniff response header, which mitigates browser rendering on that adapter, but the upload restriction itself is still bypassed. This is an…
Recommended action: Upgrade to 9.9.1-alpha.11 (pre-release) or 8.6.81 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 relation query using the $relatedTo operator could read the membership of a Relation field even when that field was hidden from the requesting client by protectedFields, and even when the object owning the relation was not readable by the client under its ACL or class-level permissions. The request requires only the public API credentials that Parse clients normally carry — no user session, master key, or Cloud Code is needed. As a result, an unauthenticated client who knows or obtains the owning object's objectId could enumerate the objects linked through a protected relation, or combine the operator with an objectId constraint to use it as a membership oracle — confirming whether a specific object is linked to a private parent. This affects applications that rely on protectedFields or object ACLs to keep Relation membership confidential, such as private group memberships, block lists, or account-to-resource associations. Patches The relation query path now authorizes…
Recommended action: Upgrade to 9.9.1-alpha.6 (pre-release) or 8.6.80 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 9.9.1-alpha.5 (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 default file upload extension blocklist can be bypassed by appending a trailing dot to a filename whose extension would otherwise be blocked (e.g. poc.svg.). The trailing dot causes the extension parser to extract an empty string, which short-circuits the blocklist check, and the attacker-controlled Content-Type is forwarded to the storage adapter unchanged. Storage adapters that persist and serve the provided Content-Type (such as S3 or GCS) then serve the file with an active type such as image/svg+xml, enabling stored XSS when a victim opens the file URL. The default GridFS adapter is not affected because it sets X-Content-Type-Options: nosniff on responses. Patches A filename ending in a dot is now treated as extensionless. When the parser produces an empty extension, the request handler falls back to validating the Content-Type subtype against the configured extension blocklist, matching the path that already catches truly extensionless uploads with a dangerous…
Recommended action: Upgrade to 9.9.1-alpha.4 (pre-release) or 8.6.79 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 routeAllowList server option restricts external client access to a configured list of REST API routes. The check is only enforced as Express middleware against the outer HTTP request URL, so the /batch handler dispatches each sub-request to the internal router without re-running the allow-list check. An external caller whose outer route matches batch can issue batch sub-requests to any REST API route that the operator omitted from the allow-list. Authentication, ACL, CLP, and other inner-route authorization controls still apply — only the operator-configured route firewall is bypassed. Patches routeAllowList is now re-enforced for each batch sub-request inside the batch handler before dispatch, mirroring the existing per-sub-request rate-limit enforcement pattern. The path-normalization and regex-match logic was extracted into a shared helper used by both the outer middleware and the batch handler. Master and maintenance keys bypass the per-sub-request check on the same…
Recommended action: Upgrade to 9.9.1-alpha.3 (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 Parse Server is vulnerable to denial of service. A remote attacker can send a single, small query (~1 KB) containing deeply nested query condition operators. Parse Server processes the nested structure with exponential time complexity, which blocks the Node.js event loop and makes the server unresponsive to all clients for the duration of processing. A single request can occupy the event loop for many seconds, and the request is repeatable. The issue affects the REST API and LiveQuery query handling and is reachable in the default configuration. Exploitation requires only the public application identifier; no user authentication is needed. Patches The internal query-traversal helper that previously re-walked nested arrays — causing exponential-time processing of nested $or/$and/$nor operators — was corrected to traverse queries in linear time. Additionally, the optional requestComplexity.queryDepth limit was generalized so that nested logical operators are counted even when…
Recommended action: Upgrade to 9.9.1-alpha.12 (pre-release) or 8.6.82 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 GraphQL endpoint discloses schema metadata to unauthenticated callers through Did you mean ...? suggestions embedded in GraphQL validation-error messages. An unauthenticated caller who knows only the public application id can iteratively send malformed queries to reconstruct class names, field names, argument names, mutation names, and input-object fields. This bypasses the IntrospectionControlPlugin enforced when graphQLPublicIntrospection: false (the default) and defeats the schema-hiding goal of prior advisories GHSA-48q3-prgv-gm4w and GHSA-q5q9-2rhp-33qw. Schema disclosure aids reconnaissance for downstream authorization probing but does not by itself leak object data or authentication material. Patches A new SchemaSuggestionsControlPlugin Apollo plugin strips the Did you mean ...? suffix from GraphQL validation-error messages during validationDidStart, which runs before any introspection gate. The plugin applies only when graphQLPublicIntrospection: false…
Recommended action: Upgrade to 9.9.1-alpha.2 (pre-release) or 8.6.78 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 who knows a publicly-known Parse Application ID can submit a single HTTP request whose client SDK version field contains adversarial input that triggers polynomial backtracking in a request-header parser. The parsing runs before session authentication and before rate limiting on every /parse/ request, so the request consumes seconds to minutes of synchronous CPU on a Node.js worker before any access control evaluates it. A small number of concurrent requests can saturate a worker; a single large request via the body-field variant can pin a worker for minutes. Production deployments running the default configuration are affected. Patches The client SDK version capture and parsing have been removed entirely. The Parse JS SDK compatibility table defines a strict version-pinned contract between Parse Server and the Parse JS SDK; server-side adaptation to client SDK version is an obsolete pattern that contradicts that contract. The vulnerable parser, the…
Recommended action: Upgrade to 9.9.1-alpha.1 (pre-release) or 8.6.77 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 race condition in the MFA SMS one-time password (OTP) login path allows two concurrent /login requests carrying the same OTP to both succeed and both receive valid session tokens, breaking the single-use property of the OTP. The vulnerability requires the attacker to already possess the victim's password and intercept the active SMS OTP (e.g. via SIM swap, network mirror, or phishing relay) and to race the legitimate login request, so the practical attack surface is narrow. This advisory is the same class of incomplete fix as GHSA-2299-ghjr-6vjp (TOTP recovery codes) and GHSA-w73w-g5xw-rwhf (MFA recovery in authData-only login). Those previous fixes added optimistic locking only for array-typed authData fields; SMS MFA stores the OTP as a string, so the guard skipped it. Patches The optimistic lock has been generalized to cover primitive (string, number, boolean) and array authData fields. The lock is implemented as a shared helper applyAuthDataOptimisticLock that adds…
Recommended action: Upgrade to 9.9.0-alpha.2 (pre-release) or 8.6.76 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 GET /sessions/me endpoint returns Session fields that the server operator explicitly configured as protected via the protectedFields server option. Any authenticated user can retrieve their own session's protected fields with a single request. The equivalent GET /sessions and GET /sessions/:objectId endpoints correctly strip protected fields. Patches The GET /sessions/me handler now re-fetches the session with the caller's auth context after validating the session token, ensuring protectedFields and CLP apply consistently with other session endpoints. Workarounds None. References - GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-g4v2-qx3q-4p64 - Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10406 - Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10407
Recommended action: Upgrade to 9.8.0-alpha.7 (pre-release) or 8.6.75 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 login endpoint response time differs measurably depending on whether the submitted username or email exists in the database. When a user is not found, the server responds immediately. When a user exists but the password is wrong, a bcrypt comparison runs first, adding significant latency. This timing difference allows an unauthenticated attacker to enumerate valid usernames. Patches A dummy bcrypt comparison is now performed when no user is found, normalizing response timing regardless of user existence. Additionally, accounts without a stored password (e.g. OAuth-only) now also run a dummy comparison to prevent the same timing oracle. Workarounds Configure rate limiting on the login endpoint to slow automated enumeration. This reduces throughput but does not eliminate the timing signal for individual requests.
Recommended action: Upgrade to 9.8.0-alpha.6 (pre-release) or 8.6.74 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 file can be uploaded with a filename extension that passes the file extension allowlist (e.g., .txt) but with a Content-Type header that differs from the extension (e.g., text/html). The Content-Type is passed to the storage adapter without consistency validation. Storage adapters that store and serve the provided Content-Type (such as S3 or GCS) serve the file with the mismatched Content-Type. The default GridFS adapter is not affected because it derives Content-Type from the filename at serving time. Patches The file upload now derives the Content-Type from the filename extension, overriding any user-provided Content-Type when the file has an extension. Workarounds Configure the storage adapter or CDN to derive Content-Type from the filename extension instead of using the stored Content-Type.
Recommended action: Upgrade to 9.7.1-alpha.4 (pre-release) or 8.6.73 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact File downloads via HTTP Range requests bypass the afterFind(Parse.File) trigger and its validators on storage adapters that support streaming (e.g. the default GridFS adapter). This allows access to files that should be protected by afterFind trigger authorization logic or built-in validators such as requireUser. Patches The streaming file download path now executes the afterFind(Parse.File) trigger before sending any data. Authentication is resolved from the session token header so that trigger validators can distinguish authenticated from unauthenticated requests. Workarounds Use beforeFind(Parse.File) instead of afterFind(Parse.File) for file access authorization. The beforeFind trigger runs on all download paths including streaming.
Recommended action: Upgrade to 9.7.1-alpha.1 (pre-release) or 8.6.71 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 authenticated user with find class-level permission can bypass the protectedFields class-level permission setting on LiveQuery subscriptions. By sending a subscription with a $or, $and, or $nor operator value as a plain object with numeric keys and a length property (an "array-like" object) instead of an array, the protected-field guard is bypassed. The subscription event firing acts as a binary oracle, allowing the attacker to infer whether a protected field matches a given test value. Patches The fix validates that $or, $and, and $nor operator values are arrays in the LiveQuery subscription handler, the query depth checker, and the protected-field guard. As defense in depth, the LiveQuery query evaluator also rejects non-array values for these operators. Workarounds There is no known workaround.
Recommended action: Upgrade to 9.7.0-alpha.16 (pre-release) or 8.6.70 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 authenticated user can bypass the immutability guard on session fields (expiresAt, createdWith) by sending a null value in a PUT request to the session update endpoint. This allows nullifying the session expiry, making the session valid indefinitely and bypassing configured session length policies. Patches The truthiness-based guard checks were replaced with key-presence checks that reject any value for protected session fields, including null. Workarounds There is no known workaround. A beforeSave trigger on Session could be used to reject null values for expiresAt and createdWith.
Recommended action: Upgrade to 9.7.0-alpha.14 (pre-release) or 8.6.69 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 GraphQL query complexity validator can be exploited to cause a denial-of-service by sending a crafted query with binary fan-out fragment spreads. A single unauthenticated request can block the Node.js event loop for seconds, denying service to all concurrent users. This only affects deployments that have enabled the requestComplexity.graphQLDepth or requestComplexity.graphQLFields configuration options. Patches The fix replaces the per-branch fragment traversal with memoized fragment computation, reducing the traversal from exponential O(2^N) to linear O(N) time. Additionally, early termination aborts the traversal as soon as configured limits are exceeded. Workarounds Disable GraphQL complexity limits by setting requestComplexity.graphQLDepth and requestComplexity.graphQLFields to -1 (the default). Resources - GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-mfj6-6p54-m98c - Fix Parse Server 9:…
Recommended action: Upgrade to 9.7.0-alpha.12 (pre-release) or 8.6.68 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 bypass Cloud Function validator access controls by appending .prototype.constructor to the function name in the URL. When a Cloud Function handler is declared using the function keyword and its validator is a plain object or arrow function, the trigger store traversal resolves the handler through its own prototype chain while the validator store fails to mirror this traversal, causing all access control enforcement to be skipped. This allows unauthenticated callers to invoke Cloud Functions that are meant to be protected by validators such as requireUser, requireMaster, or custom validation logic. Patches The trigger store traversal now verifies that each intermediate node is a legitimate store object before continuing traversal. If the traversal encounters a non-store value such as a function handler, it stops and returns an empty store, preventing prototype chain escape. Workarounds Use arrow functions instead of the function keyword for Cloud Function…
Recommended action: Upgrade to 9.7.0-alpha.11 (pre-release) or 8.6.67 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 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
Recommended action: Upgrade to 9.7.0-alpha.10 (pre-release) or 8.6.66 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 multiple clients subscribe to the same class via LiveQuery, the event handlers process each subscriber concurrently using shared mutable objects. The sensitive data filter modifies these shared objects in-place, so when one subscriber's filter removes a protected field, subsequent subscribers may receive the already-filtered object. This can cause protected fields and authentication data to leak to clients that should not see them, or cause clients that should see the data to receive an incomplete object. Additionally, when an afterEvent Cloud Code trigger is registered, one subscriber's trigger modifications can leak to other subscribers through the same shared mutable state. Any Parse Server deployment using LiveQuery with protected fields or afterEvent triggers is affected when multiple clients subscribe to the same class. Patches The fix deep-clones the shared objects at the start of each subscriber's processing callback, ensuring each subscriber works on an…
Recommended action: Upgrade to 9.7.0-alpha.9 (pre-release) or 8.6.65 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 who possesses a valid authentication provider token and a single MFA recovery code or SMS one-time password can create multiple authenticated sessions by sending concurrent login requests via the authData login endpoint. This defeats the single-use guarantee of MFA recovery codes and SMS one-time passwords, allowing session persistence even after the legitimate user revokes detected sessions. Patches The fix adds optimistic locking to the authData login path, ensuring that concurrent database updates for the same user fail when the original MFA token array has already been modified by another request. Workarounds There is no known workaround.
Recommended action: Upgrade to 9.7.0-alpha.8 (pre-release) or 8.6.64 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 verify password endpoint returns unsanitized authentication data, including MFA TOTP secrets, recovery codes, and OAuth access tokens. An attacker who knows a user's password can extract the MFA secret to generate valid MFA codes, defeating multi-factor authentication protection. Patches The verify password endpoint now sanitizes authentication data through auth adapter hooks before returning the response, consistent with login and user retrieval endpoints. Workarounds There is no known workaround.
Recommended action: Upgrade to 9.7.0-alpha.7 (pre-release) or 8.6.63 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 authenticated user calling GET /users/me receives unsanitized auth data, including sensitive credentials such as MFA TOTP secrets and recovery codes. The endpoint internally uses master-level authentication for the session query, and the master context leaks through to the user data, bypassing auth adapter sanitization. An attacker who obtains a user's session token can extract MFA secrets to generate valid TOTP codes indefinitely. Patches The /users/me endpoint now queries the session and user data separately, using the caller's authentication context for the user query so that all security layers apply correctly. Workarounds There is no known workaround.
Recommended action: Upgrade to 9.6.0-alpha.55 (pre-release) or 8.6.61 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 who obtains a user's password and a single MFA recovery code can reuse that recovery code an unlimited number of times by sending concurrent login requests. This defeats the single-use design of recovery codes. The attack requires the user's password, a valid recovery code, and the ability to send concurrent requests within milliseconds. Patches The login handler now uses optimistic locking when updating auth data that contains consumed single-use tokens. If a concurrent request has already modified the recovery array, the update fails and the login is rejected. Workarounds There are no known workarounds.
Recommended action: Upgrade to 9.6.0-alpha.54 (pre-release) or 8.6.60 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.