CVE-2026-114648 in C# Driver
Summary
by MITRE • 10/22/2026
The MongoDB C# Driver does not neutralize dot and dollar characters in dictionary keys, field names and array-filter identifiers used in LINQ queries before placing them into the field paths it sends to the server. An application user whose input reaches these positions can redirect a query or update to fields the application did not name, which can expose other users' documents and widen updates beyond the intended data. Certain values can also write malformed fields that leave stored documents unreadable by the application until they are repaired.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The MongoDB C# Driver contains a critical server-side query injection vulnerability arising from insufficient input validation when processing LINQ queries. Specifically, the driver fails to neutralize or escape dot and dollar characters within dictionary keys, field names, and array-filter identifiers before these values are incorporated into the BSON documents sent to the database server. In standard MongoDB operations, the dot character is used as a path separator for nested fields, while the dollar sign denotes operators that modify query behavior. When an attacker can control input destined for these specific positions in a LINQ expression, they can inject arbitrary characters that alter the structure of the resulting command. This flaw allows malicious actors to redirect queries or update operations away from the intended target fields and toward other locations within the document hierarchy or even across different documents if access controls are misconfigured.
The operational impact of this vulnerability is severe, primarily affecting data confidentiality and integrity. By injecting dot characters into field names, an attacker can traverse nested structures to read sensitive information stored in sub-fields that were not explicitly targeted by the application logic. This effectively bypasses intended scope limitations, exposing other users' documents or private data fields to unauthorized access. Furthermore, the ability to inject dollar signs allows for operator injection, which can widen updates beyond the intended data set. For instance, an attacker might manipulate update operations to overwrite multiple fields simultaneously or apply operators that alter document structure in unintended ways. This leads to a significant breach of data integrity and confidentiality, as the application's security model relies on the assumption that field names are treated strictly as literal strings rather than query syntax components.
Beyond unauthorized access and modification, this vulnerability poses a risk to system availability through data corruption. Certain injected values can result in malformed fields being written to the database. These corrupted documents may become unreadable by the application because they no longer conform to expected schemas or contain invalid BSON structures. This forces administrators to manually repair or restore affected records from backups, leading to operational downtime and increased maintenance overhead. The inability of the application to parse these specific entries effectively disrupts normal business processes that depend on accurate data retrieval and presentation.
To mitigate this vulnerability, immediate patching of the MongoDB C# Driver is required to ensure that all user-supplied input used in LINQ queries undergoes rigorous sanitization or escaping before being serialized into BSON. Developers should also implement strict allow-list validation for any dynamic field names or keys derived from user input, ensuring that only alphanumeric characters and safe delimiters are permitted where appropriate. Additionally, applying the principle of least privilege to database accounts can limit the blast radius if an injection occurs by restricting write permissions on sensitive collections. Regular security audits focusing on data access patterns and query construction logic will help identify similar weaknesses in other parts of the application stack.
This vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection), specifically server-side code or command injection via input manipulation, as well as CWE-78 Improper Neutralization of Special Elements used in an OS Command where the database query language is treated similarly to a shell command. In terms of offensive security frameworks, this maps to ATT&CK technique T1059 Command and Scripting Interpreter, specifically through indirect execution via database drivers, and potentially T1190 Exploit Public-Facing Application if the vulnerable endpoint is accessible over the network. The core issue remains the failure to treat user input as data rather than executable syntax during query construction.