MongoDB .NET Driver EUVD-2026-108319

Exploitation requires ALL of: (1) the application uses the MongoDB .NET/C

driver in the affected range (2.10.0 up to, but not including, 3.13.0); (2) client-side field-level encryption (CSFLE) is configured and in use for sensitive fields; and (3) the process runs under a platform text-encoding configuration that causes the driver's internal name conversion to lose information, so the encryption layer cannot associate the operation with its configured encryption rules. The triggering mechanism beyond 'certain platform text-encoding configurations' is not described in the available sources. Limiting factors: the flaw only affects deployments that actually use CSFLE (not default MongoDB usage), only under the specific non-default text-encoding condition, and it produces no error - so there is no attacker-controlled payload, but also no runtime signal to detect the failure. Impact is confined to confidentiality of the written fields; no integrity or availability impact was observed.

This is a confidentiality-only flaw (CWE-838, inappropriate output encoding) where the MongoDB .NET/C

driver's client-side field-level encryption (CSFLE) silently fails to encrypt data under certain platform text-encoding configurations, persisting sensitive fields in plaintext without raising an error. The vendor CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:N/UI:N/VC:H/SC:H) scores 6.9 (Medium) and correctly captures the key signals: local attack vector, a required attack condition (AT:P, matching the 'under certain platform text-encoding configurations' precondition), and high confidentiality impact to both the vulnerable and a subsequent system (the datastore where plaintext lands). Exploitation status is weak: there is no CISA KEV listing, no EPSS score supplied, and no public exploit identified at time of analysis - the only references are the vendor fix release and JIRA tickets. The vuln.today decision label is 'this_month' (not act_now/emergency), consistent with a real-but-not-urgent confidentiality regression. This is genuinely a latent data-exposure defect rather than an attacker-driven RCE: the primary risk is that organizations relying on CSFLE for compliance or data-at-rest confidentiality may have unknowingly stored sensitive fields in cleartext, and there is no runtime error to alert them. Note the signals are internally consistent - Medium CVSS, no KEV, no POC, this_month priority all point to a non-urgent but real remediation item, with the caveat that undetected plaintext exposure may already have occurred historically.

An application using the affected driver (2.10.0 up to 3.13.0) with CSFLE configured runs on a platform whose text-encoding configuration triggers the lossy internal name conversion. A normal application user writes records containing fields designated for encryption; the driver fails to match the operation to its encryption rules and persists those fields in plaintext in MongoDB with no error raised. Anyone with read access to the datastore (DBA, backup, breach of the database tier) can then read the supposedly-encrypted data. No public exploit was identified at time of analysis; the issue manifests through normal writes rather than a crafted attack payload.