CVE-2026-118383: MongoDB Pre-Auth Replica Set Crash — Detection, Hardening, and Remediation Guide

MongoDB disclosed and patched a critical pre-authentication flaw tracked as CVE-2026-118383 that can turn an ordinary availability control — replica set failover — into an outage amplifier. Per the public summary, an unauthenticated attacker can send two requests that cause a MongoDB Server process to crash. The dangerous part is the trigger condition: the crash matters when the affected node is later selected to become primary while it is still behind on replication and lacks recent changes. In plain operational terms, the attacker does not need valid credentials, does not need to win the election immediately, and does not need to destroy data. They need network reachability to a replica set member and the right timing relative to replication lag and failover.

For defenders, this is not just a denial-of-service bug. It sits at the intersection of database availability, replication correctness, and election safety. If your organization runs internet-exposed, partner-exposed, flat-network, or weakly authenticated MongoDB replica sets, assume this flaw is operationally relevant until you prove otherwise. MongoDB released fixed versions earlier this week; the exact fixed version numbers and CVSS scoring were not included in the source summary, so confirm both against the official MongoDB security advisory before declaring exposure closed.

What Is at Risk

The affected component is MongoDB Server when deployed as a member of a replica set. The source item specifically describes affected servers as replica set members, which means standalone mongod instances are likely not the primary concern, and sharded clusters still inherit risk because each shard is typically backed by a replica set.

The business impact depends on architecture:

• High risk: internet-reachable mongod/mongos adjacent infrastructure, no security.authorization, broad bindIp such as 0.0.0.0, weak network ACLs, or secondaries with chronic replication lag.
• Moderate risk: internal-only replica sets where attackers already have foothold or where flat segmentation allows arbitrary workloads to reach TCP 27017.
• Lower but not zero risk: hardened clusters with authentication enforced, least-privilege network paths, low-lag secondaries, and monitored failover — still patch, because pre-auth crashes are cheap and repeatable.

A crash that lands before or during an election can produce failed failovers, repeated elections, rollback scenarios, application timeouts, and write inconsistency investigations. Even if MongoDB correctly prevents an unsafe primary from serving wrong data, the defensive burden shifts to your SOC to prove availability loss was not accompanied by data integrity damage.

Technical Analysis

Affected products and platforms

• Product: MongoDB Server
• Deployment mode: Replica set members; potential downstream impact to sharded clusters because shards are usually replica sets
• Platforms: Any supported MongoDB Server operating system is potentially relevant if the installed build is vulnerable
• CVE: CVE-2026-118383
• CVSS: Not provided in the referenced news summary; validate in the MongoDB advisory and your vulnerability scanner feed
• Exploitation requirements: Unauthenticated network access to the MongoDB listener, ability to send the two crafted requests, and a vulnerable server that may later be selected primary while replication-lagged

The source summary states MongoDB released fixed versions earlier this week, but it does not enumerate those versions. Do not guess version numbers from blog posts or scanner banners alone. Pull the exact fixed builds from the official MongoDB security advisory and map them to your package channel, container tag, Windows MSI, or tarball release train.

Defender-view attack chain

1. Reconnaissance: Attacker identifies reachable MongoDB endpoints through port scans, exposed cloud security groups, compromised internal hosts, certificate transparency, Shodan/Censys-style indexing, or application configuration leaks.
2. Pre-auth interaction: Attacker sends two requests to a vulnerable mongod without authenticating. The exact request structure is not in the public summary; defensively, treat any short pre-auth request burst followed by mongod termination as suspicious.
3. Crash: The target MongoDB process exits, asserts, aborts, or is restarted by systemd, Docker, Kubernetes, Windows Service Control Manager, or another supervisor.
4. Election timing: The replica set enters or continues an election. If the crashed/lagging node is later chosen as primary while missing recent changes, the failure mode described by CVE-2026-118383 becomes relevant.
5. Operational impact: Applications see primary instability, drivers retry, elections repeat, replication lag spikes, and SREs may fail over repeatedly while trying to restore service.

Exploitation status

As of the referenced item, there is no confirmed public proof-of-concept, no confirmed in-the-wild exploitation, and no CISA KEV listing mentioned in the summary. Treat it as a credible, low-complexity pre-auth availability flaw with severe clustering consequences, not as background noise. The absence of a public PoC is not a safety signal for a database control plane that can be reached by unauthenticated clients.

Immediate Priorities

1. Confirm whether any MongoDB listener is reachable from untrusted networks.
2. Inventory every replica set member, arbiter, hidden node, delayed secondary, and shard replica set.
3. Measure current replication lag and identify nodes that are eligible for election while stale.
4. Patch to the MongoDB fixed release listed in the vendor advisory.
5. Enforce authentication, least-privilege network access, TLS where appropriate, and election/lag guardrails.
6. Add detection for crash-plus-election sequences and pre-auth connection bursts preceding mongod restarts.

Detection & Response

The best high-fidelity signal is not a single packet pattern, because the public item does not disclose the crafted request bytes. The useful correlation is: unauthenticated or non-allowlisted connection burst to MongoDB -> mongod fatal/exit/restart -> replica set election or primary change -> replication lag/rollback symptoms. Tune allowlists for known application subnets, load balancers, automation, and MongoDB agents before deploying broadly.

---
title: MongoDB Server Fatal Crash or Abort on Linux
description: Detects MongoDB server crash, assertion, abort, or abnormal service termination messages that may indicate exploitation of CVE-2026-118383 or a malicious pre-auth crash.
references:
  - https://thehackernews.com/2026/11/critical-pre-auth-mongodb-flaw-cve-2026.html
author: Security Arsenal
date: 2026/11/05
status: experimental
logsource:
  product: linux
  service: syslog
detection:
  selection:
    Message|contains:
      - 'mongod'
      - 'MongoDB'
  condition: selection and (crash_terms or process_exit)
  crash_terms:
    Message|contains:
      - 'Fatal assertion'
      - 'Aborted'
      - 'segmentation fault'
      - 'signal 11'
      - 'signal 6'
      - 'Got signal'
      - 'terminate() called'
      - 'Invariant failure'
      - 'fatal'
  process_exit:
    Message|contains:
      - 'Main process exited'
      - 'Failed with result'
      - 'Start request repeated too quickly'
      - 'Unit entered failed state'
falsepositives:
  - Routine package upgrades or supervised restarts
  - Known maintenance windows
level: high
---
title: MongoDB Replica Set Election After Node Crash
description: Detects replica set election, primary transition, or state change messages following possible MongoDB instability. Correlate with mongod exits and non-allowlisted connections to TCP 27017.
references:
  - https://thehackernews.com/2026/11/critical-pre-auth-mongodb-flaw-cve-2026.html
author: Security Arsenal
date: 2026/11/05
status: experimental
logsource:
  product: linux
  service: syslog
detection:
  selection:
    Message|contains:
      - 'MongoDB'
      - 'mongod'
      - 'replset'
  election_terms:
    Message|contains:
      - 'election'
      - 'became primary'
      - 'transition to primary'
      - 'stepping down'
      - 'member is now in state'
      - 'ROLLBACK'
      - 'replication lag'
      - 'not primary'
      - 'term'
  condition: selection and election_terms
falsepositives:
  - Planned maintenance and controlled failover
  - Cloud VM reboots
level: medium
---
title: Non-Allowlisted Network Connection to MongoDB Port
description: Detects process-level network connections to MongoDB TCP 27017 or 27018 from hosts that may be unauthorized. Tune SourceIp and Initiated logic per environment and CMDB.
references:
  - https://thehackernews.com/2026/11/critical-pre-auth-mongodb-flaw-cve-2026.html
author: Security Arsenal
date: 2026/11/05
status: experimental
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationPort:
      - 27017
      - 27018
      - 27019
    Initiated: 'true'
  filter_known_image:
    Image|endswith:
      - '\mongod.exe'
      - '\mongos.exe'
      - '\Compass.exe'
      - '\Studio3T.exe'
      - '\java.exe'
      - '\node.exe'
  condition: selection and not filter_known_image
falsepositives:
  - Application servers and ETL jobs not yet in the CMDB
  - Backup and monitoring agents
level: medium

// MongoDB pre-auth crash + failover hunt: Linux Syslog and CommonSecurityLog ingestion
// Tune Lookback, AllowedAppSubnets, and KnownMongoNodes before production use.
let Lookback = 24h;
let MongoPorts = dynamic([27017,27018,27019]);
let AllowedAppSubnets = dynamic(["10.20.30.0/24","10.20.31.0/24"]);
let CrashEvents =
Syslog
| where TimeGenerated >= ago(Lookback)
| where Computer has_any ("mongo", "db") or ProcessName has_any ("mongod", "systemd")
| where SyslogMessage has_any ("Fatal assertion", "Aborted", "segmentation fault", "signal 11", "signal 6", "Main process exited", "Failed with result", "Start request repeated too quickly", "Invariant failure")
| project CrashTime=TimeGenerated, Computer, ProcessName, SyslogMessage, SeverityLevel;
let ElectionEvents =
Syslog
| where TimeGenerated >= ago(Lookback)
| where SyslogMessage has_any ("election", "became primary", "transition to primary", "stepping down", "member is now in state", "ROLLBACK", "replication lag", "not primary")
| project ElectionTime=TimeGenerated, Computer, SyslogMessage;
let SuspiciousConnections =
CommonSecurityLog
| where TimeGenerated >= ago(Lookback)
| where DestinationPort in (MongoPorts)
| where ipv4_is_private(SourceIP) == false
| extend SourceSubnet=strcat(tostring(split(SourceIP,".")[0]),".",tostring(split(SourceIP,".")[1]),".",tostring(split(SourceIP,".")[2]),".0/24")
| where SourceSubnet !in (AllowedAppSubnets)
| project ConnTime=TimeGenerated, SourceIP, DestinationIP, DestinationPort, DeviceAction, DeviceVendor, DeviceProduct;
CrashEvents
| join kind=leftouter (ElectionEvents) on Computer
| extend CrashToElectionMinutes = datetime_diff("minute", ElectionTime, CrashTime)
| join kind=leftouter (SuspiciousConnections) on $left.Computer == $right.DestinationIP
| extend ConnToCrashMinutes = datetime_diff("minute", CrashTime, ConnTime)
| where abs(CrashToElectionMinutes) <= 30 or abs(ConnToCrashMinutes) <= 15
| project Computer, CrashTime, CrashProcess=ProcessName, CrashMessage=SyslogMessage, ElectionTime, SourceIP, ConnTime, ConnToCrashMinutes, CrashToElectionMinutes
| order by CrashTime desc;

-- Velociraptor artifact: MongoDB exposure and instability triage
-- Collects mongod/mongos processes, listeners, and local MongoDB config authorization/bindIp evidence.
LET processes = SELECT Pid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)mongo' OR Exe =~ '(?i)mongo' OR CommandLine =~ '(?i)mongo';

LET listeners = SELECT Pid, Name, LocalAddress, LocalPort, RemoteAddress, RemotePort, Status
FROM netstat()
WHERE LocalPort in (27017, 27018, 27019) OR Exe =~ '(?i)mongo';

LET configs = SELECT FullPath, Size, Mtime,
  parse_string_with_regex(string=read_file(filename=FullPath), regex='(?i)(security:\\s*|authorization\\s*:|bindIp\\s*:|net\\s*:|port\\s*:|replSetName\\s*:)').g0 AS ConfigEvidence
FROM glob(globs=['/etc/mongod.conf', '/etc/mongodb.conf', 'C:/Program Files/MongoDB/Server/*/bin/mongod.cfg', 'C:/mongodb/mongod.cfg'])
WHERE FullPath =~ '(?i)mongo';

SELECT 'process' AS EvidenceType, Pid, Name, Exe, CommandLine, Username, CreateTime, NULL AS LocalAddress, NULL AS LocalPort, NULL AS ConfigEvidence, NULL AS FullPath
FROM processes
UNION ALL
SELECT 'listener' AS EvidenceType, Pid, Name, NULL AS Exe, NULL AS CommandLine, NULL AS Username, NULL AS CreateTime, LocalAddress, LocalPort, NULL AS ConfigEvidence, NULL AS FullPath
FROM listeners
UNION ALL
SELECT 'config' AS EvidenceType, NULL AS Pid, NULL AS Name, NULL AS Exe, NULL AS CommandLine, NULL AS Username, Mtime AS CreateTime, NULL AS LocalAddress, NULL AS LocalPort, ConfigEvidence, FullPath
FROM configs;

#!/usr/bin/env bash
# MongoDB CVE-2026-118383 exposure audit and guardrail check (audit-first; no auto-upgrade)
# Run as root or with sudo on each replica set member. Confirm fixed versions against the official MongoDB advisory.
set -euo pipefail

echo "== MongoDB package/version evidence =="
if command -v mongod >/dev/null 2>&1; then mongod --version || true; else echo "mongod not in PATH"; fi
if command -v rpm >/dev/null 2>&1; then rpm -qa | grep -Ei 'mongodb|mongo' || true; fi
if command -v dpkg >/dev/null 2>&1; then dpkg -l | grep -Ei 'mongodb|mongo' || true; fi

echo "== Listener exposure =="
(ss -ltnp 2>/dev/null || netstat -ltnp 2>/dev/null || true) | grep -E ':(27017|27018|27019)\b' || echo "No MongoDB default listeners found"

echo "== Config checks: auth, bindIp, TLS, replica set =="
for cfg in /etc/mongod.conf /etc/mongodb.conf; do
  [ -f "$cfg" ] || continue
  echo "--- $cfg ---"
  grep -Ein '^(\s*(security:|authorization:|bindIp:|net:|port:|tls:|ssl:|replication:|replSetName:))' "$cfg" || true
  if grep -Eiq '^\s*authorization:\s*(disabled|false)' "$cfg"; then echo "ALERT: authorization appears disabled in $cfg"; fi
  if grep -Eiq '^\s*bindIp:\s*0\.0\.0\.0' "$cfg"; then echo "ALERT: bindIp 0.0.0.0 found in $cfg"; fi
done

echo "== Recent crash and election evidence =="
if command -v journalctl >/dev/null 2>&1; then
  journalctl -u mongod -u mongodb --since "-24h" --no-pager 2>/dev/null | grep -Ei 'fatal|assert|abort|signal|exited|failed|election|primary|rollback|lag|stepping down' | tail -n 200 || true
fi
grep -Eih 'fatal|assert|abort|signal|election|primary|rollback|lag|stepping down' /var/log/mongodb/mongod.log 2>/dev/null | tail -n 200 || true

echo "== Replication lag and readiness (requires authenticated mongo shell) =="
cat <<'EOF'
Use mongosh with an appropriate privileged monitoring user:
  rs.status()
  rs.conf()
  db.adminCommand({ replSetGetStatus: 1 })
  db.printSecondaryReplicationInfo()
Check optimeDate/optime deltas, member health, election eligibility, hidden/delayed nodes, and whether any lagging eligible member can become primary.
EOF

echo "== Firewall examples: restrict MongoDB to application subnets only =="
cat <<'EOF'
# Examples only; adapt interface names, zones, and subnets before enforcing.
# firewalld:
#   firewall-cmd --permanent --new-zone=mongodb || true
#   firewall-cmd --permanent --zone=mongodb --add-source=10.20.30.0/24
#   firewall-cmd --permanent --zone=mongodb --add-source=10.20.31.0/24
#   firewall-cmd --permanent --zone=mongodb --add-port=27017/tcp
#   firewall-cmd --permanent --zone=mongodb --add-port=27018/tcp
#   firewall-cmd --reload
# ufw:
#   ufw allow from 10.20.30.0/24 to any port 27017 proto tcp
#   ufw deny 27017/tcp
EOF

echo "== Upgrade reminder =="
echo "Patch to the exact fixed MongoDB Server build listed in the official advisory for your major/minor release train; do not rely on this script to determine fixed-version sufficiency."

Response Playbook

When detection fires, do not treat it as a routine service restart.

1. Stabilize availability: Put the affected member into maintenance mode if appropriate, prevent repeated automated restarts from masking evidence, and ensure the current primary is healthy and current.
2. Freeze election risk: Temporarily reduce priority for lagging or unstable eligible members if your MongoDB operational runbook permits; do not leave a stale node as the preferred failover target.
3. Preserve evidence: Capture mongod logs, journald/service logs, supervisor logs, rs.status(), replSetGetStatus, serverStatus, currentOp, firewall logs, load balancer logs, and full packet capture if available.
4. Validate integrity: Check for rollback files, replication gaps, oplog anomalies, unexpected write loss, application-level reconciliation failures, and backup restore points.
5. Scope exposure: Query EDR, flow logs, cloud security groups, Kubernetes NetworkPolicies, and WAF/load balancer telemetry for all clients that reached TCP 27017/27018/27019 in the preceding window.
6. Contain: Block offending sources, tighten ACLs, enforce authentication, and rotate credentials if there is any chance unauthenticated access coexisted with credential material or exposed management paths.
7. Recover deliberately: Restart nodes under change control, verify they catch up on replication, confirm elections complete cleanly, and only then return them to normal priority.

Remediation

• Patch: Upgrade every affected MongoDB Server replica set member to the fixed version listed in the official MongoDB security advisory for CVE-2026-118383. Include arbiters where supported by your deployment guidance, hidden/delayed secondaries, DR replica sets, and shard replica sets. The news item says fixed versions were released earlier this week but does not list exact builds, so use MongoDB’s advisory and release notes as the source of truth.
• Remove unauthenticated reachability: Require authentication, bind MongoDB to specific interfaces, prohibit bindIp: 0.0.0.0 unless explicitly justified, and allow TCP 27017/27018/27019 only from known application, monitoring, and administrative subnets.
• Harden configuration: Enable security.authorization, use role-based access control, enforce TLS for client and intra-cluster traffic where supported, disable unused listeners, and avoid exposing mongos or config server paths beyond their intended consumers.
• Reduce dangerous failover conditions: Monitor replication lag, alert on eligible secondaries whose lag exceeds your recovery point objective, set priorities intentionally, consider hidden or delayed nodes for reporting rather than failover, and review votes, priority, electionTimeoutMillis, and catch-up behavior with your DBA team.
• Protect the control plane: Use security groups, host firewalls, Kubernetes NetworkPolicies, private endpoints, VPN/ZTNA for admin access, and explicit deny rules for internet-to-database traffic.
• Backups and integrity checks: Maintain tested backups and point-in-time recovery, snapshot before patching where supported, and define who can declare data integrity clean after rollback or failover anomalies.
• Patch governance: Add CVE-2026-118383 to emergency vulnerability workflows, verify scanner coverage for MongoDB package/container versions, and require closure evidence: installed fixed version, listener restriction proof, auth enabled proof, and a clean post-patch failover test.
• Deadlines: No CISA KEV deadline was present in the source summary. If CISA adds it, follow KEV dates for federal or aligned organizations; otherwise use internal critical-internet-facing SLAs, typically 24-72 hours for exposure reduction and immediate patching windows for reachable pre-auth database flaws.

Defensive Validation Checklist

• No MongoDB listener answers from the internet or untrusted segments.
• security.authorization is enabled and anonymous access fails.
• Replica set status shows healthy members, acceptable lag, and no unsafe stale eligible primary candidate.
• A controlled failover in staging completes without repeated elections, rollback surprises, or application-visible data loss.
• SIEM correlation fires on crash-plus-election and non-allowlisted MongoDB connection bursts.
• Vulnerability management closes the CVE only after version, configuration, and network evidence are attached.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub