CVE-2026-1847: Replica Set Replication DOS Vulnerability

CVE-2026-1847 Overview

CVE-2026-1847 is a Resource Exhaustion vulnerability in MongoDB that affects replica set configurations. Inserting certain large documents into a replica set can cause secondary nodes to fail when attempting to fetch the oplog from the primary. This vulnerability can stall replication within the replica set, ultimately leading to server crash and denial of service conditions.

Critical Impact

This vulnerability can cause complete replication failure in MongoDB replica sets, potentially resulting in data inconsistency and service unavailability across the database cluster.

Affected Products

• MongoDB Server (replica set configurations)
• MongoDB deployments utilizing oplog replication

Discovery Timeline

• 2026-02-10 - CVE CVE-2026-1847 published to NVD
• 2026-02-10 - Last updated in NVD database

Technical Details for CVE-2026-1847

Vulnerability Analysis

This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The core issue stems from MongoDB's handling of exceptionally large documents during oplog replication in replica set environments.

When a large document is inserted into the primary node, it gets recorded in the oplog (operations log). Secondary nodes in the replica set continuously fetch and apply operations from the primary's oplog to maintain data synchronization. However, certain large documents can cause the oplog fetch mechanism to fail on secondary nodes, preventing them from processing subsequent operations.

The replication stall creates a cascading failure scenario where secondary nodes fall behind and eventually become unable to catch up with the primary. In severe cases, this can trigger server crashes, leaving the replica set in an inconsistent state.

Root Cause

The root cause is improper resource allocation during oplog document processing. MongoDB does not adequately enforce limits or throttling when handling oversized documents in the replication stream, allowing resource exhaustion to occur on secondary nodes. This represents a failure to properly validate and constrain document sizes in the context of oplog fetching operations.

Attack Vector

The attack vector is network-based and requires low privileges to execute. An authenticated attacker with write access to a MongoDB replica set can craft and insert specially designed large documents. The attack exploits the following conditions:

1. The attacker must have write permissions to a collection in the replica set
2. The inserted document must be large enough to trigger the oplog fetch failure
3. Secondary nodes must be actively replicating from the primary

Once the malicious document is inserted, the replication failure occurs automatically as secondaries attempt to synchronize, requiring no further attacker interaction.

Detection Methods for CVE-2026-1847

Indicators of Compromise

• Unexpected replication lag between primary and secondary nodes exceeding normal thresholds
• Secondary nodes reporting oplog fetch errors or timeouts in MongoDB logs
• Sudden increases in document sizes being inserted into collections
• Server crash events on secondary replica set members following write operations

Detection Strategies

• Monitor MongoDB replication lag metrics using rs.printSlaveReplicationInfo() or monitoring tools
• Configure alerting on oplog fetch failures and replication state changes
• Implement document size validation at the application layer before database insertion
• Review MongoDB server logs for error patterns related to oplog processing failures

Monitoring Recommendations

• Enable detailed logging for replication operations on all replica set members
• Set up automated alerts when replication lag exceeds defined thresholds
• Monitor system resource utilization (memory, CPU) on secondary nodes during replication
• Track document size distributions in write-heavy collections

How to Mitigate CVE-2026-1847

Immediate Actions Required

• Review and enforce document size limits at the application layer before insertion
• Monitor replica set health and replication status for any anomalies
• Implement write concerns that verify replication to secondaries before acknowledging writes
• Consider temporarily restricting write access to sensitive collections while assessing exposure

Patch Information

MongoDB has tracked this issue in their Jira system. Refer to the MongoDB Jira Issue SERVER-113532 for the latest patch information, affected versions, and remediation guidance. Organizations should apply vendor-provided updates as soon as they become available.

Workarounds

• Implement application-level validation to reject documents exceeding safe size thresholds
• Use MongoDB's maxBsonObjectSize parameter awareness in client applications
• Configure oplog size appropriately to handle temporary replication delays
• Deploy additional monitoring to detect and alert on replication anomalies early

# Configuration example - Monitor replica set status
mongo --eval "rs.status()" --quiet

# Check replication lag on secondaries
mongo --eval "rs.printSlaveReplicationInfo()"

# Review oplog size and utilization
mongo --eval "db.getReplicationInfo()"