MongoDB Server Two-Phase Commit Protocol Vulnerability Leading to Data Inconsistencies

A post-authentication vulnerability has been identified in the network two-phase commit protocol used for cross-shard transactions in MongoDB Server. This flaw may cause logical data inconsistencies under specific, unpredictable conditions that last for a very short time. The issue arises when a transaction, initiated with the 'apiVersion' parameter, is left in a 'prepared' state on some shards after a failover event. The transaction coordination logic may then incorrectly interpret the situation as a successful commitment, leading to an inconsistent state across the affected shards. This vulnerability impacts MongoDB Server versions 8.0 prior to 8.0.16, 7.0 prior to 7.0.26, and 8.2 prior to 8.2.2.

Impact

Exploitation of this vulnerability can result in a partially committed transaction across shards, creating a logical inconsistency where clients observe conflicting transaction outcomes. In some cases, this can lead to persistent issues, such as blocking read and write operations on affected documents and causing unbounded growth of the oplog.

Reproduction

To reproduce this vulnerability, initiate a cross-shard transaction in MongoDB Server with the 'apiVersion' parameter set. During the two-phase commit process, induce a failover event on one of the shards. When the commit command is issued, the shard that experienced the failover may return an 'API Version Mismatch' error, causing the transaction to remain in the 'prepared' state. The transaction coordinator will mistakenly treat this error as a successful acknowledgment, leading to a situation where the transaction is considered committed on some shards but remains stuck in the prepared state on others.

Remediation

Users can manually intervene to commit or abort blocked prepared transactions, if the transaction's commit or abort state can be determined from other shards or from the client. However, if definitive data is unavailable, recovery cannot be guaranteed.