parse-server: Transactional batch request can roll back or block writes of other clients

Impact

A transactional batch request sent by any client can interfere with database writes of other clients that run at the same time. On PostgreSQL, a MongoDB replica set or a MongoDB sharded cluster, these writes become part of the batch's database transaction and are rolled back if the batch fails, although those clients received a success response. On a standalone MongoDB, these writes fail while the batch is in progress. On PostgreSQL, the request can also leave a database transaction open indefinitely, holding its locks and database connection, and cause subsequent write requests of all clients to fail. This affects deployments that set the Parse Server option masterKey to a function, register a Cloud Code validator with rateLimit after the server has started, or set Parse.Server at runtime.

Patches

Each request now always uses its own database controller, which holds the state of a transactional batch. Loading the master key no longer writes request-scoped configuration to the server-wide configuration cache, and a transaction cannot be started while another one is active on the same database controller.

Workarounds

Set the Parse Server option masterKey to a string instead of a function, and do not register Cloud Code validators with rateLimit or set Parse.Server after the server has started.

References

• GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-jhh9-hrgh-c9gv
• Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10713
• Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10716