Which versions of MongoDB Server are affected by CVE-2026-18691?

MongoDB Server's replica-set and sharded-cluster deployments are vulnerable to credential downgrade attacks that expose internal cluster authentication credentials, allowing attackers with…. A patch is available.

How to fix or mitigate CVE-2026-18691?

Within 24 hours: audit all MongoDB deployments to identify which use replica sets or sharded clusters and document network exposure of cluster member communication. Within 7 days: implement network segmentation to isolate cluster member-to-member traffic from adjacent network segments; enable MongoDB audit logging for internal cluster authentication attempts; and document current cluster keyfile configurations. Within 30 days: monitor vendor communications for patch availability (subscribe to MongoDB security advisories for SERVER-130264 resolution); establish a staging environment to validate and test patches immediately upon release; and prepare a tested patch deployment procedure for critical production clusters.

MongoDB Server CVE-2026-18691

Q: What is the CVSS score of CVE-2026-18691?

CVE-2026-18691 has a CVSS 4.0 base score of 9.0 (Critical). CVSS vector: CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.2%.

EUVD-2026-56921 CRITICAL

Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade') (CWE-757)

2026-08-11 mongodb

GHSA-jx4v-jf9c-3rh7

Information Disclosure MongoDB Mongodb Server

9.0

CVSS 4.0 · Vendor: mongodb

Severity by source

Vendor (mongodb) PRIMARY

9.0 CRITICAL

CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

8.3 HIGH

Adjacent access to inter-node traffic (AV:A) with conditional downgrade success (AC:H), no auth needed (PR:N); recovered superuser credential crosses into full cluster control (S:C) with total C/I/A impact.

3.1 AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H

4.0 AV:A/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Primary rating from Vendor (mongodb).

CVSS VectorVendor: mongodb

Attack Vector

Adjacent

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Patch available

Aug 11, 2026 - 20:19 EUVD

Analysis Generated

Aug 11, 2026 - 20:17 vuln.today

CVE Published

Aug 11, 2026 - 18:46 cve.org

CRITICAL 9.0

DescriptionCVE.org

An issue in MongoDB Server's intra-cluster connection setup could allow a party with suitable network access to influence which authentication mechanism is used when one replica set member connects to another. Under certain conditions, this could cause the cluster's shared internal credential to be transmitted in a less-protected form, potentially allowing that credential to be recovered. If recovered, the credential could be used to authenticate as the internal superuser to nodes in the deployment.

AnalysisAI

Credential exposure in MongoDB Server's replica-set/sharded-cluster internal authentication allows an adjacent-network attacker to force an authentication-mechanism downgrade during intra-cluster member-to-member connection setup, causing the shared internal keyfile/cluster credential to be sent in a weaker form that can be recovered. Any party with recovered credentials can authenticate as the internal superuser (__system) and gain full control of every node in the deployment. Reported by MongoDB (SERVER-130264); no public exploit identified at time of analysis and it is not listed in CISA KEV.

Technical ContextAI

MongoDB replica-set members and sharded-cluster nodes authenticate to one another using a shared internal credential - either a keyfile-derived secret or x.509 certificate - negotiated over the wire when one member opens a connection to another. This flaw is CWE-757 (Selection of Less-Secure Algorithm During Negotiation, i.e. an algorithm/mechanism downgrade): an on-path or suitably positioned party can influence which SASL/auth mechanism is selected for that internal handshake, steering it toward a mechanism (e.g. a challenge-response scheme like SCRAM-SHA-1 or an otherwise less-protected exchange) that leaks enough material to recover the shared secret. Because the recovered credential maps to the __system internal superuser role, the exposure is not a single-node issue but a cluster-wide trust compromise. The affected component per CPE is cpe:2.3:a:mongodb:mongodb_server across unspecified versions.

RemediationAI

Upgrade MongoDB Server to the patched release identified in MongoDB's advisory - consult https://jira.mongodb.org/browse/SERVER-130264 for the exact fixed versions, as no specific patched version number is provided in the available data (No vendor-released patch version independently confirmed at time of analysis). As compensating controls until patched: enforce TLS/x.509 for intra-cluster (member) authentication rather than keyfile-only SCRAM so the handshake is not downgradeable to a recoverable form; isolate cluster inter-node traffic onto a dedicated, trusted management network or VPN and firewall the replication/config-server ports (default 27017/27018/27019) so no untrusted party has adjacent access to the member-to-member channel; and rotate the internal keyfile/cluster credential after patching in case it was already exposed. Trade-off: switching internal auth to x.509 requires certificate provisioning and a coordinated rolling restart, and network re-segmentation may disrupt existing client/monitoring connectivity, so stage these changes.