Parse Server CVE-2026-109954

Exploitation requires a Parse Server deployment (5.4.0-8.6.95 or 9.0.0-9.10.2-alpha.4) actually using transactional batch requests, AND a database backend that supports transactions - PostgreSQL, or MongoDB configured as a replica set or sharded cluster; standalone MongoDB without transactions is not in scope. Triggering the flaw further depends on concurrent requests from multiple clients so the shared batch state collides (the AT:P / race-condition timing requirement), meaning it is not reliably exploitable with a single isolated request. No authentication is required (PR:N) and the API is reachable over the network (AV:N), but the limiting factors are the transaction-capable backend, active use of the batch feature, and the need to win a concurrency race.

This is a genuine-but-niche integrity/availability flaw rather than a classic high-impact RCE. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) rates it 8.3 (High): network-reachable and unauthenticated (PR:N), but carrying an Attack Requirement (AT:P) that reflects the race-condition timing/concurrency precondition - exploitation is not deterministic on a single request. Impact is integrity-low (VI:L) and availability-high (VA:H) with NO confidentiality impact (VC:N), consistent with the described effect: other clients' acknowledged writes being rolled back and PostgreSQL transactions remaining open indefinitely (a denial-of-service on writes). No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no evidence of active or at-scale exploitation at this time - the score is driven by the unauthenticated network vector and availability impact, not by demonstrated exploitability. NOTE A CONFLICT: the input Tags include 'Information Disclosure', but the CVSS vector explicitly sets VC:N (no confidentiality impact) and the description describes write rollback/transaction exhaustion, not data leakage - treat the disclosure characterization as unverified. Overall: a real priority only for Parse Server deployments actually using transactional batches on PostgreSQL or MongoDB replica sets/sharded clusters; otherwise lower real-world risk.

An attacker (or even a benign high-concurrency client) on a Parse Server instance backed by PostgreSQL or a MongoDB replica set/sharded cluster issues transactional batch requests concurrently with other clients. Because batch state is shared across requests, the attacker's failing batch rolls back other clients' already-acknowledged writes and can leave PostgreSQL transactions open indefinitely, causing subsequent writes to fail. No public exploit code was identified at the time of analysis.