CVE-2026-25610: 
MongoDB vulnerability analysis and mitigation

CVE-2026-25610 is a denial-of-service vulnerability in MongoDB that allows an authenticated user to crash the server by executing a $geoNear aggregation pipeline with certain invalid index hints. It affects MongoDB versions 7.0.0 through 7.0.28 and 8.0.0 through 8.0.12. The vulnerability was published on February 10, 2026, with a patch tracked under MongoDB's internal issue SERVER-99119. It carries a CVSS v3.1 base score of 6.5 (Medium) and a CVSS v4.0 base score of 7.1 (High) (Red Hat Advisory, MongoDB Jira).

The root cause is classified as CWE-617 (Reachable Assertion), meaning the server reaches an internal assertion failure when processing a $geoNear pipeline stage supplied with certain malformed or invalid index hints. An authenticated attacker with low privileges can trigger this condition remotely over the network by submitting a crafted aggregation query — no user interaction or elevated permissions are required. The assertion failure causes the MongoDB process to crash, resulting in a denial-of-service condition (Red Hat Advisory, MongoDB Jira).

Successful exploitation results in a complete loss of availability for the affected MongoDB instance, as the server process crashes and becomes unresponsive to legitimate clients and applications. There is no impact on confidentiality or data integrity — the vulnerability is purely a denial-of-service issue. Because any low-privilege authenticated database user can trigger the crash, the attack surface is broad in multi-tenant or shared database environments where multiple users have query access (Red Hat Advisory).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at this time (Red Hat Advisory). The EPSS score is approximately 0.04%, indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Authentication: Obtain valid credentials for a MongoDB instance running a vulnerable version (7.0.0–7.0.28 or 8.0.0–8.0.12). Low-privilege database user access is sufficient.
2. Identify a geospatial collection: Locate or create a collection with a geospatial index (e.g., a 2dsphere or 2d index) that can be targeted by a $geoNear pipeline stage.
3. Craft a malicious aggregation query: Construct an aggregation pipeline using $geoNear with an invalid or malformed hint parameter referencing a non-existent or incompatible index.
4. Submit the query: Execute the crafted aggregation pipeline against the target MongoDB instance using any MongoDB client (e.g., mongosh, a driver, or the MongoDB Compass GUI).
5. Trigger server crash: The invalid index hint causes MongoDB to reach an internal reachable assertion, crashing the server process and rendering the database unavailable (MongoDB Jira, Red Hat Advisory).

• Logs: MongoDB server logs showing an abrupt process termination or assertion failure message (e.g., Invariant failure or Assertion: ...) coinciding with a $geoNear aggregation query; repeated crash/restart cycles in the MongoDB service logs.
• Process: Unexpected termination of the mongod process; automatic restart by a process supervisor (e.g., systemd, init) following a crash.
• Network: Aggregation pipeline queries containing $geoNear with unusual or non-existent hint field values originating from a specific client IP, particularly if repeated in quick succession.
• Application: Downstream applications reporting sudden loss of database connectivity or connection timeout errors correlating with MongoDB process restarts.

MongoDB has released patched versions: 7.0.29 (for the 7.0.x branch) and 8.0.13 (for the 8.0.x branch). Administrators should upgrade to these versions immediately (MongoDB Jira). As a temporary workaround prior to patching, restrict database access to trusted users only, apply the principle of least privilege to limit which users can execute aggregation pipeline operations, and monitor for unusual $geoNear queries with suspicious index hints. Network-level controls (e.g., firewall rules, VPN) should be used to limit exposure of MongoDB instances to untrusted networks.