Is there a patch available for CVE-2026-43930?

Yes, a patch is available for CVE-2026-43930. Update the affected software to the latest version immediately.

Parse Server CVE-2026-43930

Q: What is the CVSS score of CVE-2026-43930?

CVE-2026-43930 has a CVSS 4.0 base score of 2.1 (Low). CVSS vector: CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

LOW

Race Condition (CWE-362)

2026-05-05 https://github.com/parse-community/parse-server

GHSA-jpq4-7fmq-q5fj

Race Condition Information Disclosure

2.1

CVSS 4.0 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

2.1 LOW

CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

High

Privileges Required

High

User Interaction

None

Scope

Lifecycle Timeline

CVSS changed

May 12, 2026 - 14:22 NVD

2.1 (LOW)

Source Code Evidence Fetched

May 05, 2026 - 21:02 vuln.today

Analysis Generated

May 05, 2026 - 21:02 vuln.today

DescriptionGitHub Advisory

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 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

AnalysisAI

Race condition in Parse Server MFA SMS one-time password validation allows two concurrent login requests using the same OTP to both succeed and receive valid session tokens, breaking the single-use property of SMS-based multi-factor authentication. The vulnerability affects Parse Server versions 8.x before 8.6.76 and 9.x before 9.9.0-alpha.2, requires the attacker to already possess the victim's password and intercept the active SMS OTP via SIM swap, network interception, or phishing relay, then race a legitimate login request. This represents an incomplete fix of a prior optimistic locking vulnerability that affected only array-typed authData fields; SMS OTP storage as a string was not covered by the original guard.

Technical ContextAI

Parse Server implements multi-factor authentication using authData fields stored in the user record. The vulnerability stems from a race condition in the /login endpoint's concurrent request handling of single-use credentials. The root cause (CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization) arose from incomplete optimistic locking logic that only guarded array-typed authData fields (TOTP recovery codes) but failed to cover primitive string fields where SMS OTP tokens are stored. The fix generalizes the optimistic lock mechanism via a shared applyAuthDataOptimisticLock helper function that adds equality predicates on original authData field values to the update WHERE clause. When concurrent requests race the same single-use token, the second request's WHERE clause will no longer match the modified record (token field removed by first request), causing the update to fail and surface as Invalid auth data error. The lock applies to primitive types (string, number, boolean) and arrays but skips Date and nested objects due to JSON serialization differences between MongoDB and PostgreSQL adapters.

RemediationAI

Upgrade Parse Server immediately to version 8.6.76 (for the 8.x branch) or 9.9.0-alpha.2 or later (for the 9.x branch) to apply the vendor-released patch that generalizes optimistic locking to all primitive and array authData fields. Detailed patches are available in pull requests https://github.com/parse-community/parse-server/pull/10448 (Parse Server 9) and https://github.com/parse-community/parse-server/pull/10449 (Parse Server 8). As immediate workarounds if upgrading is not immediately feasible: disable SMS MFA enrollment and direct users to TOTP-based MFA instead (TOTP tokens are time-window validated rather than stored single-use, eliminating the race condition), or place a rate limiter on the /login endpoint to reduce concurrent-request burst capacity and make racing attacks impractical (note that rate limiting does not eliminate the race, only reduces its feasibility). The TOTP workaround is preferred because it removes the underlying single-use storage design weakness entirely.