Skip to main content
CVE-2026-25612VulnerabilityPublished

CVE-2026-25612: MongoDB Server · Unrestricted Externally Accessible Lock

Affects MongoDB ServerSource CVE Database V5

0

Not known to be exploited · CVSS 7.1 High · fixed in 8.2.4 : patch MongoDB Server soon.

Data as of 25 Oct 2026, 19:02 UTC

CVSS 4.0 base score
7.1High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.2% chance of exploitation in 30 days – higher than 13% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 8.2.4, 8.0.18, 7.0.29
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 10 Feb 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-25.

What to do

Upgrade MongoDB Server to 8.2.4, 8.0.18 or 7.0.29.

Affected software

ProductAffectedFixed in
MongoDB IncMongoDB ServerAffected
  • >=8.2 <8.2.4
  • >=8.0 <8.0.18
  • >=7.0 <7.0.29
Fixed in
  • 8.2.4
  • 8.0.18
  • 7.0.29

AI-suggested

1. Monitor MongoDB server logs and performance metrics closely to detect unusual lock contention or collection unavailability. 2. Limit the number of concurrent operations on collections known to cause lock collisions as a temporary workaround. 3. Review and optimize database schema design to minimize collection name collisions or resource encoding conflicts. 4. Implement rate limiting or throttling on database queries to reduce lock contention under high load. 5. Stay updated with MongoDB vendor advisories and apply patches promptly once released. 6. Consider deploying MongoDB in a high-availability cluster configuration to mitigate impact of localized unavailability. 7. Conduct thorough testing of database workloads in staging environments to identify potential lock collision scenarios before production deployment. 8. Engage with MongoDB support or security teams for guidance on interim fixes or configuration adjustments. 9. Use network segmentation and access controls to restrict exposure of MongoDB servers to trusted clients only, reducing risk of remote exploitation. 10. Prepare incident response plans specifically addressing database availability issues caused by locking conflicts.

Description

The internal locking mechanism of the MongoDB server uses an internal encoding of the resources in order to choose what lock to take. Collections may inadvertently collide with one another in this representation causing unavailability between them due to conflicting locks.

References

Community reviews

Loading reviews…