CVE-2026-114649 in C# Driver
Summary
by MITRE • 10/22/2026
The MongoDB C# Driver compares TLS client certificates by issuer and serial number only when deciding whether two clients can share cached connections. In an application that creates clients from certificates supplied by different users, a user who provides a certificate copying another user's issuer and serial number, without that user's private key, can be given connections authenticated with the other user's certificate. Database operations can then run under the other user's identity, affecting the confidentiality and integrity of data that identity can access.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability in question stems from a critical flaw in how the MongoDB C# Driver manages connection pooling for TLS-secured connections. In typical database driver implementations, maintaining separate cached connections per authenticated client is essential to ensure strict isolation between different users or service accounts. However, this specific implementation relies exclusively on comparing the issuer and serial number of TLS client certificates to determine if two clients are identical enough to share a pooled connection. This approach fundamentally misunderstands the nature of X.509 certificate authentication, where uniqueness is guaranteed not just by administrative identifiers like issuer and serial number, but critically by the possession of the corresponding private key during the TLS handshake process.
When an application creates multiple client instances from certificates supplied by different users, it expects each instance to operate under a distinct security context. The flaw allows a malicious actor or compromised service that possesses only the public certificate details—specifically the issuer and serial number—to be mistakenly associated with another user's active connection pool entry. Since the driver does not verify that the connecting entity actually holds the private key corresponding to the certificate presented in the cached session, it assumes identity based solely on these administrative fields. This creates a scenario where a new client instance can hijack an existing authenticated connection intended for a different principal.
The operational impact of this vulnerability is severe and directly affects both confidentiality and integrity within the database environment. An attacker who exploits this flaw can execute database operations under the identity of another user without possessing their private key or credentials. This effectively bypasses authentication controls, allowing unauthorized access to sensitive data that should be restricted by role-based access control policies. Furthermore, because actions are performed as the legitimate user, any modifications made through these hijacked connections will appear authentic in audit logs, potentially leading to integrity violations where malicious changes are indistinguishable from authorized ones. This undermines trust in the system's ability to enforce multi-tenant isolation and secure data boundaries.
From a classification perspective, this issue aligns with CWE-287, which describes Improper Authentication, as well as CWE-345 regarding Insufficient Verification of Data Authenticity. In terms of adversarial tactics, it relates to MITRE ATT&CK techniques involving credential access or lateral movement where an attacker impersonates another user account within a trusted system. The root cause lies in the assumption that certificate metadata is sufficient for identity binding without verifying cryptographic proof of ownership via private key validation during connection reuse decisions.
To mitigate this vulnerability, immediate updates to the MongoDB C# Driver are required to ensure that connection pooling logic incorporates full verification of client identity beyond just issuer and serial number fields. Developers should verify that the driver implementation strictly validates that the connecting entity possesses the private key associated with the certificate before allowing it to share a cached session. Until such patches are applied, applications relying on this driver for multi-user TLS authentication should consider disabling connection pooling or implementing custom logic to ensure strict separation of client contexts based on more robust identity verification mechanisms. Regular auditing of database access logs can also help detect anomalies indicative of such impersonation attempts, although prevention at the driver level remains the most effective defense strategy against this specific class of vulnerability.