MongoDB C Driver CVE-2026-120684

Exploitation requires the legacy GridFS file-handling code path of the MongoDB C Driver to be in use, plus an authenticated database user holding ordinary write access to a shared GridFS storage area (PR:L). The attacker must arrange conditions (CVSS AT:P) under which a separate application later appends to the affected file and writes the uninitialized process memory into records the same user can read - so the attack is not fully attacker-controlled and depends on application append behavior. Limiting factors: requires valid low-privilege authentication, a shared storage area the attacker can both write and read, applications using the vulnerable legacy GridFS append path, and the specific affected C Driver version; the disclosed content is whatever happens to be in process memory, so the leak of sensitive data such as credentials is opportunistic rather than guaranteed.

This is a moderate, authenticated information-disclosure issue rather than an urgent widespread threat. The MongoDB-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N) scores 6.0 and the signals are internally consistent: network reachable but requiring an authenticated database user with low privileges (PR:L) and an attack requirement (AT:P) - meaning the attacker must arrange specific conditions that are not fully under their control, which is why this is not a simple point-and-shoot flaw. Confidentiality impact is High (uninitialized process memory, potentially including credentials, can leak) while integrity and availability are untouched (VI:N/VA:N). No EPSS score, no CISA KEV listing, and no public exploit were provided; the only reference is a MongoDB Jira ticket, not a proof-of-concept. The vuln.today decision label is 'this_month', not act_now/emergency, consistent with a real but non-critical priority. The main caveat: exploitation depends on a specific legacy GridFS usage pattern and a cooperating application append path, so real-world exploitability is narrower than the CWE-908 'memory disclosure including credentials' description alone might suggest - the leak is probabilistic and depends on what happens to reside in process memory. No key signals conflict, but the absence of EPSS and any fixed-version data limits precision.

A database user who holds ordinary write access to a shared GridFS storage area crafts file-handling conditions so that the legacy GridFS code path stores uninitialized C Driver process memory as file content. When an application later appends to that file, the leaked memory - potentially including credentials from the application's process - is written into records the same user is permitted to read, exposing it. No public exploit identified at time of analysis; the only reference is a MongoDB Jira issue.