CVE-2026-82075: MongoDB Sharded-Cluster Router DOS Vulnerability

CVE-2026-82075 Overview

CVE-2026-82075 is an uncontrolled resource consumption weakness [CWE-770] in the request-handling path of the MongoDB sharded-cluster router process. An unauthenticated client with network access to a router port can supply connection-monitoring parameters that force the server to consume CPU without rate limiting. The condition degrades or denies service to legitimate clients. Confidentiality and integrity remain intact; only availability is affected. The flaw requires no authentication, no elevated privileges, and no user interaction, making the router process reachable by any network-adjacent attacker a viable denial-of-service target.

Critical Impact
An unauthenticated, network-based attacker can exhaust router CPU and deny MongoDB sharded-cluster availability to legitimate clients.

Affected Products

MongoDB sharded-cluster router process (mongos)
Specific affected versions are tracked in MongoDB Jira Issue SERVER-132650
Refer to the vendor advisory for the authoritative list of impacted builds

Discovery Timeline

2026-09-08 - CVE-2026-82075 published to NVD
2026-09-08 - Last updated in NVD database

Technical Details for CVE-2026-82075

Vulnerability Analysis

The vulnerability resides in the request-handling path of mongos, the router process that fronts a MongoDB sharded cluster. Clients can submit connection-monitoring parameters that the router accepts and processes before authenticating the caller. Because the processing path lacks bounds and rate limiting, an attacker can trigger disproportionate CPU work per request. Sustained request volume starves scheduling capacity available to legitimate client sessions.

The issue is classified under [CWE-770] Allocation of Resources Without Limits or Throttling. It is a pure availability defect: no data is read, altered, or leaked. Impact is amplified in shared cluster designs where a single router services many application tenants. The absence of authentication before parameter processing removes the primary mitigation an operator would rely on for pre-auth safety.

Root Cause

The root cause is missing enforcement of resource quotas and rate limits on connection-monitoring inputs handled early in the request pipeline. Untrusted values control the amount of CPU work performed per request, allowing amplification through repeated invocation.

Attack Vector

Exploitation is remote and unauthenticated. An attacker who can reach a mongos listener port sends crafted connection-monitoring parameters at a sustained rate. The router expends CPU cycles processing each request, blocking or slowing responses to legitimate clients. See the MongoDB Jira Issue SERVER-132650 advisory for vendor technical details. No verified public exploit code is available.

Detection Methods for CVE-2026-82075

Indicators of Compromise

Sustained high CPU utilization on mongos processes without corresponding query workload growth
Elevated volumes of pre-authentication connections from a small set of source addresses
Rising client-side timeouts, connection resets, and driver retry storms against affected routers
Application logs showing degraded query latency across multiple tenants sharing the router tier

Detection Strategies

Correlate mongos CPU saturation with connection counts from unauthenticated sources to identify DoS patterns
Alert on abnormal ratios of connection-monitoring requests to authenticated operations
Baseline normal mongos request rates per source IP and flag deviations exceeding the baseline

Monitoring Recommendations

Ingest mongos process metrics (CPU, connection counts, op latency) into a centralized telemetry pipeline
Enable MongoDB audit logging and forward events to a SIEM for correlation with network telemetry
Monitor edge firewall and load-balancer logs for connection floods targeting router ports (default 27017)

How to Mitigate CVE-2026-82075

Immediate Actions Required

Restrict network reachability of mongos router ports to trusted application subnets using firewalls or security groups
Place rate limiting in front of the router tier at the load balancer or network firewall to cap per-source connection rates
Track the MongoDB Jira Issue SERVER-132650 ticket for the fixed-version announcement and schedule an upgrade window

Patch Information

MongoDB tracks remediation for this issue under SERVER-132650. Consult that ticket and the MongoDB security advisories for the authoritative list of fixed builds. Upgrade all mongos router instances in each sharded cluster to a patched release once available.

Workarounds

Block mongos ports from untrusted networks and require access through a bastion, VPN, or private link
Deploy connection rate limiting and concurrent-connection caps at the network layer in front of routers
Scale router capacity horizontally so that saturation of a single mongos does not deny the cluster
Monitor CPU thresholds on router hosts and automate isolation or restart of saturated nodes

bash

# Example: restrict mongos port 27017 to a trusted application subnet with iptables
iptables -A INPUT -p tcp --dport 27017 -s 10.20.0.0/16 -j ACCEPT
iptables -A INPUT -p tcp --dport 27017 -j DROP

# Example: cap concurrent connections per source with iptables connlimit
iptables -A INPUT -p tcp --syn --dport 27017 \
  -m connlimit --connlimit-above 50 --connlimit-mask 32 -j REJECT