Search for packages
| purl | pkg:npm/parse-server@9.7.0-alpha.2 |
| Next non-vulnerable version | 9.9.0-alpha.2 |
| Latest non-vulnerable version | 9.9.1-alpha.2 |
| Risk | 4.5 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-5j87-2q5c-cqdf
Aliases: CVE-2026-34373 GHSA-q3p6-g7c4-829c |
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 |
Affected by 9 other vulnerabilities. |
|
VCID-82fj-6jd2-hqc1
Aliases: CVE-2026-34363 GHSA-m983-v2ff-wq65 |
LiveQuery protected field leak via shared mutable state across concurrent subscribers ### 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 independent copy. Additionally, a bug was fixed where master key LiveQuery clients could not receive events on classes with protected fields due to an incorrect type passed to the sensitive data filter. ### Workarounds There is no known workaround. ### Resources - GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-m983-v2ff-wq65 - Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10330 - Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10331 |
Affected by 10 other vulnerabilities. |
|
VCID-davb-xyy3-2qf1
Aliases: CVE-2026-35200 GHSA-vr5f-2r24-w5hc |
Parse Server: File upload Content-Type override via extension mismatch ### 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. |
Affected by 3 other vulnerabilities. |
|
VCID-f6mm-th5w-fug4
Aliases: CVE-2026-34532 GHSA-vpj2-qq7w-5qq6 |
parse-server has cloud function validator bypass via prototype chain traversal ### 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 handlers. Arrow functions do not have a `prototype` property and are not affected by this vulnerability. ### Resources - GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-vpj2-qq7w-5qq6 - Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10342 - Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10343 |
Affected by 8 other vulnerabilities. |
|
VCID-h8ut-tkq6-r7e2
Aliases: CVE-2026-34224 GHSA-w73w-g5xw-rwhf |
Parse Server has an MFA single-use token bypass via concurrent authData login requests ### 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. |
Affected by 11 other vulnerabilities. |
|
VCID-jsgf-t1ga-x7eq
Aliases: CVE-2026-43930 GHSA-jpq4-7fmq-q5fj |
parse-server: MFA SMS one-time password accepted twice under concurrent login ### 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](https://github.com/parse-community/parse-server/security/advisories/GHSA-2299-ghjr-6vjp) (TOTP recovery codes) and [GHSA-w73w-g5xw-rwhf](https://github.com/parse-community/parse-server/security/advisories/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 equality predicates on the original values of changed fields to the update WHERE clause. Concurrent writers racing the same single-use token now miss the WHERE condition and surface as `Invalid auth data`. ### Workarounds - Disable SMS MFA and use TOTP instead (TOTP tokens are time-window validated, not stored single-use). - Place a rate limiter on the `/login` endpoint to reduce concurrent-request burst capacity. ### Resources - GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-jpq4-7fmq-q5fj - Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10448 - Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10449 |
Affected by 0 other vulnerabilities. |
|
VCID-kar5-6zet-aqad
Aliases: CVE-2026-39381 GHSA-g4v2-qx3q-4p64 |
Parse Server's Endpoint `/sessions/me` bypasses `_Session` `protectedFields` ### 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 |
Affected by 1 other vulnerability. |
|
VCID-kpnd-nb3e-2ufx
Aliases: CVE-2026-34215 GHSA-wp76-gg32-8258 |
Parse Server exposes auth data via verify password endpoint ### 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. |
Affected by 12 other vulnerabilities. |
|
VCID-n8kv-67nw-xbaw
Aliases: CVE-2026-34574 GHSA-f6j3-w9v3-cq22 |
Parse Server has a session field immutability bypass via falsy-value guard ### 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`. |
Affected by 6 other vulnerabilities. |
|
VCID-r9jq-4te8-xkfb
Aliases: CVE-2026-34595 GHSA-mmg8-87c5-jrc2 |
Parse Server has a LiveQuery protected-field guard bypass via array-like logical operator value ### 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. |
Affected by 5 other vulnerabilities. |
|
VCID-sd7z-5aa7-f7aw
Aliases: CVE-2026-39321 GHSA-mmpq-5hcv-hf2v |
Parse Server has a login timing side-channel reveals user existence ### 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. |
Affected by 2 other vulnerabilities. |
|
VCID-w48t-hex5-qkcs
Aliases: CVE-2026-34784 GHSA-hpm8-9qx6-jvwv |
Parser Server's streaming file download bypasses afterFind file trigger authorization ### 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. |
Affected by 4 other vulnerabilities. |
|
VCID-ze79-p1vg-47fx
Aliases: CVE-2026-34573 GHSA-mfj6-6p54-m98c |
parse-server has GraphQL complexity validator exponential fragment traversal DoS ### 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: https://github.com/parse-community/parse-server/pull/10344 - Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10345 |
Affected by 7 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||