MongoDB C# Driver EUVD-2026-108312

Exploitation requires a specific application coding pattern: the application must use the FindOneAndReplace operation AND construct the replacement document's top-level field names from untrusted, user-supplied input. The attacker must be an authenticated/low-privileged user of that application (PR:L) able to influence those field names. Limiting factors that reduce real-world risk: the injected operators only affect the single document already selected by the application's own filter (no mass or arbitrary-record modification), the impact is modification only (no read/disclosure, no availability loss), and applications that use fixed field names or validate/reject '$'-prefixed keys are not affected. The flaw is specific to FindOneAndReplace - the driver's other replace operations already reject such documents.

This is a moderate-severity NoSQL injection (CWE-943) with a genuinely narrow blast radius, best treated as a code-hygiene / defense-in-depth fix rather than an emergency. The MongoDB-assigned CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N, 5.3) is internally consistent with the description: integrity-only impact (VI:L), no confidentiality (VC:N) and no availability (VA:N) impact, and PR:L meaning the attacker must already be an authenticated/low-privileged user of the affected application. Critically, the server only applies the injected update operators to the single document already selected by the application's own filter, so the attacker cannot pivot to arbitrary records - the impact is bounded, which is why VI is Low rather than High and why there is no scope change. No EPSS score, no CISA KEV listing and no proof-of-concept were supplied; the vuln.today decision label is 'this_month', not act_now or emergency, and a vendor patch (v3.13.0) is available. Note one metadata conflict: the input Tag 'Information Disclosure' contradicts the CVSS vector's VC:N (no confidentiality impact) and the description, which describes unintended modification (integrity), not disclosure - the integrity framing should be treated as authoritative.

An application calls FindOneAndReplace and builds the replacement document's top-level fields from user-supplied names. An authenticated attacker supplies a field name beginning with a dollar sign (e.g. '$set' or '$inc'); because the C

Driver fails to reject it here (unlike its other replace operations), the MongoDB server interprets the input as update operators and modifies the document matched by the application's filter in ways the application never intended. No public exploit code is identified at time of analysis.