CVE-2026-1847: 
MongoDB vulnerability analysis and mitigation

CVE-2026-1847 is a Denial of Service vulnerability in MongoDB replica sets caused by improper resource allocation when inserting certain large documents. When such documents are inserted into a replica set, secondary nodes become unable to fetch the oplog from the primary, stalling replication and potentially causing server crashes. Affected versions include MongoDB 7.0.0–7.0.28, 8.0.0–8.0.17, and 8.2.0–8.2.3. The vulnerability was published on February 10, 2026, with a patch reference tracked as SERVER-113532. It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 7.1 (High) (Red Hat Advisory, MongoDB Jira).

The root cause is classified as CWE-770 (Allocation of Resources Without Limits or Throttling). When a sufficiently large document is inserted into a MongoDB replica set, the oplog entry generated for that operation exceeds a threshold that secondary nodes cannot handle when attempting to fetch it from the primary. This causes the replication pipeline to stall and ultimately crash the secondary. The attack vector is network-based, requires low privileges (an authenticated user with write access), no user interaction, and low attack complexity (Red Hat Advisory, MongoDB Jira).

Successful exploitation results in complete availability loss across the MongoDB replica set — secondary nodes crash and replication halts, leaving the deployment in a degraded or non-functional state. There is no confidentiality or integrity impact; the vulnerability is purely a Denial of Service condition. In production environments relying on replica sets for high availability and read scaling, this could cause significant service disruption and data access outages (Red Hat Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.04%, indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires authenticated network access with at least low-level write privileges to the MongoDB instance (Red Hat Advisory, MongoDB Jira).

1. Reconnaissance: Identify MongoDB replica set deployments running vulnerable versions (7.0.0–7.0.28, 8.0.0–8.0.17, or 8.2.0–8.2.3) accessible over the network.
2. Authentication: Obtain or use existing low-privilege credentials with write access to a database on the target replica set.
3. Craft large document: Prepare a document that is sufficiently large to trigger the oplog allocation issue — this involves constructing a BSON document near or at the maximum document size limit (16 MB).
4. Insert document: Use the MongoDB client or driver to insert the crafted large document into a collection on the primary node of the replica set.
5. Trigger replication failure: The oplog entry for the large document causes secondary nodes to fail when attempting to fetch it from the primary, stalling replication.
6. Achieve DoS: Secondary nodes crash, replication halts across the replica set, resulting in availability loss for the deployment (MongoDB Jira, Red Hat Advisory).

• Logs: MongoDB logs on secondary nodes showing repeated errors fetching or applying oplog entries from the primary; error messages referencing oplog cursor failures or replication stalls in mongod.log.
• Process: Secondary mongod processes crashing or restarting unexpectedly; replica set status (rs.status()) showing secondaries in RECOVERING or DOWN state.
• Network: Unusual insertion of very large documents (near 16 MB) by a low-privilege user account, visible in MongoDB audit logs if auditing is enabled.
• Replication Metrics: Sudden spike in replication lag on secondaries followed by complete replication halt; monitoring alerts from tools like MongoDB Ops Manager or Prometheus exporters indicating secondary node unavailability.

MongoDB has released patched versions addressing this vulnerability: 7.0.29 or later for the 7.0 branch, 8.0.18 or later for the 8.0 branch, and 8.2.4 or later for the 8.2 branch. Administrators should upgrade to the appropriate patched version as the primary remediation. As an interim measure, restrict write privileges to trusted users only and monitor replica set replication health for anomalies. Implementing authentication controls to limit which users can insert large documents can reduce exposure (MongoDB Jira, Red Hat Advisory).

Red Hat has published a security advisory tracking this CVE, and Tenable has released a Nessus detection plugin (ID 298783) for identifying vulnerable MongoDB installations. No significant public researcher commentary or social media discussion has been observed beyond standard vulnerability database aggregation (Red Hat Advisory, Tenable Plugin).