CVE-2026-109954 in Parse Server
Summary
by MITRE • 10/13/2026
Parse Server 5.4.0 before 8.6.96 and 9.0.0 before 9.10.2-alpha.5 shares transactional batch state across concurrent requests, letting any client's transactional batch request interfere with other clients' database writes. On PostgreSQL or MongoDB replica sets and sharded clusters, other clients' acknowledged writes are rolled back if the batch fails, and PostgreSQL transactions can remain open indefinitely, causing subsequent writes to fail.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/13/2026
Parse Server versions 5.4.0 through 8.6.95 and 9.0.0 through 9.10.2-alpha.5 contain a critical concurrency flaw related to the management of transactional batch operations. The vulnerability stems from an improper sharing of transactional state across concurrent requests within the server architecture. In a properly secured system, each client request should maintain isolated session and transaction contexts to prevent interference between independent users or processes. However, in these affected versions, the internal mechanisms handling database transactions do not correctly isolate the state associated with batched operations. This design oversight allows data intended for one specific transactional context to leak into another, creating a scenario where multiple concurrent requests can inadvertently interact with shared resources that should remain distinct.
The operational impact of this flaw is severe and manifests differently depending on the underlying database engine in use. For environments utilizing PostgreSQL or MongoDB replica sets and sharded clusters, the consequences are particularly damaging due to how these systems handle transactional integrity. When a client submits a batch request involving multiple write operations wrapped in a single transaction, any failure within that batch triggers a rollback of all writes associated with it. Due to the state sharing vulnerability, this rollback mechanism does not strictly limit itself to the failing client's data. Instead, it can inadvertently roll back acknowledged and committed writes from other concurrent clients who were operating under separate transactions. This results in significant data loss for unaffected users, as their successful database operations are erased by a failure originating from an unrelated request.
In PostgreSQL deployments specifically, the vulnerability introduces additional stability risks beyond immediate data rollback. The flawed state management can cause PostgreSQL transactions to remain open indefinitely without being properly closed or committed. An open transaction holds locks on database rows and tables for extended periods, which blocks other operations attempting to access those resources. This leads to a denial of service condition where subsequent write attempts from legitimate clients fail because they are blocked by the lingering lock held by the orphaned transaction. Over time, this can exhaust available connection pools or cause widespread latency spikes across the application, effectively rendering the database unusable for new writes until the stuck transactions are manually resolved or timed out at a higher level.
From a security classification perspective, this vulnerability aligns with CWE-362, which describes concurrent execution using shared resources with inadequate synchronization. The root cause is fundamentally a race condition where thread safety and request isolation mechanisms fail to enforce strict boundaries between different client sessions. Furthermore, the ability of one authenticated user's actions to disrupt or corrupt the data integrity of other users falls under the scope of CWE-697, incorrect coordination during concurrency. In terms of adversarial tactics, this flaw could be leveraged in an ATT&CK context as a method for Denial of Service (T1499) by intentionally triggering batch failures to lock resources, or potentially as part of data manipulation strategies if the rollback behavior can be precisely controlled to target specific records belonging to other tenants.
Mitigation requires immediate upgrading to Parse Server version 8.6.96 or later for the legacy branch and version 9.10.2-alpha.5 or later for the current development line, where these concurrency issues have been addressed through improved isolation of transactional contexts. For organizations unable to upgrade immediately due to dependency constraints, implementing a reverse proxy with strict rate limiting can help mitigate the volume of concurrent requests that might trigger the race condition. Additionally, configuring database-level timeouts and monitoring for long-running transactions in PostgreSQL environments can provide some operational resilience against the lock-holding behavior described above. Application-layer changes such as reducing batch sizes or avoiding complex multi-write transactional batches during peak concurrency periods may also reduce the likelihood of triggering the vulnerability until a permanent patch is applied.