VulnerableCode Package Details - pkg:npm/parse-server@9.8.0-alpha.2

Search for packages

Vulnerability	Summary	Fixed by
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	9.9.0-alpha.2 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	9.8.0-alpha.7 Affected by 1 other vulnerability. This version is affected by these other vulnerabilities: {{ fixed_by_vuln.vulnerability_id }}
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.	9.8.0-alpha.6 Affected by 2 other vulnerabilities. This version is affected by these other vulnerabilities: {{ fixed_by_vuln.vulnerability_id }} {{ fixed_by_vuln.vulnerability_id }}

Vulnerability

Summary

Fixed by

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

9.9.0-alpha.2
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

9.8.0-alpha.7
Affected by 1 other vulnerability.

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.

9.8.0-alpha.6
Affected by 2 other vulnerabilities.

Vulnerability	Summary	Aliases
This package is not known to fix vulnerabilities.

Vulnerability

Summary

Aliases

This package is not known to fix vulnerabilities.

Date	Actor	Action	Vulnerability	Source	VulnerableCode Version
2026-06-06T08:26:18.236990+00:00	GitLab Importer	Affected by	VCID-jsgf-t1ga-x7eq	https://gitlab.com/gitlab-org/advisories-community/-/blob/main/npm/parse-server/CVE-2026-43930.yml	38.6.0
2026-06-06T07:50:48.516279+00:00	GitLab Importer	Affected by	VCID-kar5-6zet-aqad	https://gitlab.com/gitlab-org/advisories-community/-/blob/main/npm/parse-server/CVE-2026-39381.yml	38.6.0
2026-06-06T07:50:10.213313+00:00	GitLab Importer	Affected by	VCID-sd7z-5aa7-f7aw	https://gitlab.com/gitlab-org/advisories-community/-/blob/main/npm/parse-server/CVE-2026-39321.yml	38.6.0