CVE-2026-5170: MongoDB Server DoS Vulnerability

CVE-2026-5170 Overview

A denial of service vulnerability exists in MongoDB Server that allows a user with limited cluster access privileges to crash a mongod process during a specific operational window. The vulnerability can be triggered when a cluster is being promoted from a replica set to a sharded cluster, creating a brief but exploitable attack surface that could take down the primary node of the replica set.

Critical Impact

An authenticated attacker with limited privileges can cause a denial of service by crashing the primary MongoDB server during cluster promotion operations, potentially disrupting database availability and dependent applications.

Affected Products

• MongoDB Server v8.2 versions prior to 8.2.2
• MongoDB Server v8.0 versions prior to 8.0.18
• MongoDB Server v7.0 versions prior to 7.0.31

Discovery Timeline

• 2026-03-30 - CVE-2026-5170 published to NVD
• 2026-04-02 - Last updated in NVD database

Technical Details for CVE-2026-5170

Vulnerability Analysis

This vulnerability is classified under CWE-617 (Reachable Assertion), indicating that the flaw stems from an assertion condition that can be reached by an attacker during specific operational states. The vulnerability manifests during the transitional phase when a MongoDB replica set is being converted to a sharded cluster architecture.

The attack requires network access and low-privilege authentication to the cluster. The complexity of exploitation is considered high due to the limited and unpredictable timing window during which the vulnerability can be triggered. However, if successfully exploited, the impact on availability is significant, potentially causing complete service disruption of the primary database node.

Root Cause

The root cause lies in a reachable assertion within the MongoDB server code that can be triggered by a user with limited privileges during the cluster promotion process. When the replica set is transitioning to a sharded cluster configuration, certain state conditions are not properly validated, allowing an assertion to be triggered that results in an abnormal process termination.

The assertion check does not adequately account for edge cases where a user with constrained privileges issues specific commands during this transitional window. This causes the mongod process to crash rather than gracefully handling the unexpected state.

Attack Vector

The attack vector is network-based and requires authenticated access to the MongoDB cluster with at least minimal privilege actions. The attacker must be able to interact with the cluster during the specific window when promotion from a replica set to a sharded cluster is occurring.

The exploitation scenario involves the following conditions:

• The attacker has authenticated network access to the MongoDB cluster
• The cluster is in the process of being promoted from replica set to sharded cluster
• The attacker issues commands that trigger the assertion during this transitional state

Due to the limited and unpredictable nature of this timing window, the attack cannot be reliably reproduced on demand, making it a race condition-style vulnerability. However, in environments where cluster promotions are planned or recurring, the attack window becomes more predictable.

Detection Methods for CVE-2026-5170

Indicators of Compromise

• Unexpected mongod process crashes coinciding with cluster promotion operations
• Assertion failure messages in MongoDB logs containing references to sharded cluster initialization
• Multiple rapid connection attempts from low-privilege users during administrative operations
• Unusual command patterns from authenticated users during maintenance windows

Detection Strategies

• Monitor MongoDB logs for assertion failures and unexpected process terminations during cluster topology changes
• Implement alerting for mongod process crashes that correlate with replica set to sharded cluster promotion events
• Review audit logs for suspicious command patterns from users with limited privileges during cluster administration
• Deploy SentinelOne Singularity to detect anomalous process behavior and unexpected terminations

Monitoring Recommendations

• Enable MongoDB audit logging to capture all authentication and command activities during cluster operations
• Configure process monitoring to alert on unexpected mongod process terminations
• Implement network monitoring to track connection patterns during scheduled maintenance windows
• Use SentinelOne's real-time behavioral AI to identify exploitation attempts targeting database services

How to Mitigate CVE-2026-5170

Immediate Actions Required

• Upgrade MongoDB Server v8.2 to version 8.2.2 or later
• Upgrade MongoDB Server v8.0 to version 8.0.18 or later
• Upgrade MongoDB Server v7.0 to version 7.0.31 or later
• Restrict cluster access to only essential administrative users during promotion operations
• Schedule cluster promotions during low-traffic periods with appropriate access controls in place

Patch Information

MongoDB has released security patches addressing this vulnerability. Organizations should upgrade to the following fixed versions:

• MongoDB Server 8.2: Upgrade to version 8.2.2 or later
• MongoDB Server 8.0: Upgrade to version 8.0.18 or later
• MongoDB Server 7.0: Upgrade to version 7.0.31 or later

For detailed information on the fix, refer to the MongoDB Issue Tracker Entry.

Workarounds

• Temporarily revoke cluster access from non-essential users during replica set to sharded cluster promotion operations
• Implement strict network segmentation to limit access to MongoDB instances during administrative operations
• Use firewall rules to restrict authenticated connections during planned cluster topology changes
• Consider delaying cluster promotions until patches can be applied in maintenance windows

# Configuration example - Restrict user access during cluster promotion
# Temporarily revoke non-essential user roles before cluster promotion
mongosh --eval "db.revokeRolesFromUser('limitedUser', [{ role: 'read', db: 'admin' }])"

# After successful cluster promotion, restore access
mongosh --eval "db.grantRolesToUser('limitedUser', [{ role: 'read', db: 'admin' }])"