CVE-2026-82065: MongoDB Server Persistent DOS Vulnerability

CVE-2026-82065 Overview

CVE-2026-82065 is a persistent denial of service vulnerability in the MongoDB Server storage engine integration layer. An authenticated user with collection creation privileges can supply malformed storage configuration options that pass initial validation. Once written to durable metadata, these values trigger a fatal assertion failure when diagnostic operations later read the metadata. The corrupted state survives server restarts and replicates to other cluster members, forcing manual operator intervention. The issue is classified under CWE-617: Reachable Assertion.

Critical Impact
A low-privileged authenticated user can permanently disable a MongoDB cluster by persisting invalid storage options that crash nodes on read, propagating the failure across replica set members.

Affected Products

MongoDB Server (storage engine integration layer)
MongoDB replica set and sharded cluster deployments
Refer to MongoDB JIRA Issue SERVER-131420 for specific affected versions

Discovery Timeline

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

Technical Details for CVE-2026-82065

Vulnerability Analysis

The vulnerability resides in the code path that accepts user-supplied storage engine configuration options during collection creation. MongoDB permits callers with collection creation privileges to specify storage-level parameters that the server persists into internal catalog metadata. The write path performs insufficient validation on these values, admitting inputs that are syntactically acceptable but semantically invalid for the storage engine.

The failure surfaces later, when diagnostic operations such as catalog inspection or internal consistency checks parse the persisted metadata. The parsing logic reaches a state that violates an internal invariant, triggering a fatal assertion. The mongod process terminates, and any node that reads the corrupted metadata repeats the crash.

Because the poisoned metadata is durable and part of the replicated catalog, replica set secondaries and other cluster members receive the same corrupt state and fail identically. Restarting the affected process does not recover the cluster, and operators must intervene directly to remove or rewrite the offending metadata.

Root Cause

The root cause is a missing validation boundary between the user-facing collection creation API and the durable storage catalog. The server trusts caller-supplied storage options far enough to persist them, but the storage engine layer that later consumes those options enforces stricter invariants through assertions rather than through defensive error handling.

Attack Vector

An attacker requires network access to the MongoDB Server and authenticated credentials with collection creation privileges. The attacker issues a collection creation command containing crafted storage engine options. The command succeeds, the malformed values are persisted, and the cluster degrades when subsequent diagnostic reads occur. No user interaction is required. Full technical details are tracked in MongoDB JIRA Issue SERVER-131420.

Detection Methods for CVE-2026-82065

Indicators of Compromise

Repeated mongod process crashes with fatal assertion messages referencing storage engine metadata parsing
Replica set secondaries entering FATAL state shortly after applying oplog entries related to collection creation
Unexpected create commands from non-administrative accounts containing custom storageEngine option blocks

Detection Strategies

Audit MongoDB command logs for create and createIndexes operations that specify uncommon storageEngine option values, especially from low-privileged accounts
Correlate cluster-wide crash events across replica set members to distinguish this issue from single-node hardware failures
Review recent grants of createCollection or equivalent role privileges preceding cluster instability

Monitoring Recommendations

Alert on mongod fatal assertion codes and abnormal process exits across all replica set members
Ingest MongoDB audit logs into a centralized data lake and normalize create command payloads for anomaly review
Monitor replica set member state transitions to detect cascading FATAL conditions consistent with poisoned metadata replication

How to Mitigate CVE-2026-82065

Immediate Actions Required

Restrict collection creation privileges to trusted administrative accounts and remove createCollection from broadly assigned custom roles
Enable MongoDB auditing for schema-modifying commands so malformed storage option payloads are captured for review
Track the fix status in MongoDB JIRA Issue SERVER-131420 and plan upgrades to a patched build once released

Patch Information

MongoDB tracks remediation in SERVER-131420. Consult the linked issue and MongoDB release notes for the specific server versions that include the validation fix. Apply the fix to primaries and all replica set members before re-enabling broad collection creation privileges.

Workarounds

Revoke collection creation rights from application and analytics service accounts that do not require them
Add an application-layer or proxy filter that rejects create commands containing storageEngine option blocks from untrusted callers
Maintain tested backups and a documented catalog repair runbook so poisoned metadata can be excised without prolonged outage

bash

# Configuration example: restrict collection creation to an admin role
use admin
db.revokeRolesFromUser("app_service", [
  { role: "readWrite", db: "appdb" }
])
db.grantRolesToUser("app_service", [
  { role: "read", db: "appdb" },
  { role: "insertOnly", db: "appdb" }
])