CVE-2025-12893 Overview
MongoDB Server improperly validates Extended Key Usage (EKU) extensions during TLS handshakes on Windows and Apple platforms. Clients presenting certificates that specify extendedKeyUsage without clientAuth can still authenticate successfully to MongoDB servers on Windows and macOS. MongoDB servers on macOS also accept egress TLS connections to servers presenting certificates missing extendedKeyUsage = serverAuth. Linux systems enforce the expected validation behavior correctly.
The flaw is categorized under [CWE-295] Improper Certificate Validation. It affects MongoDB Server v7.0 before 7.0.26, v8.0 before 8.0.16, and v8.2 before 8.2.2.
Critical Impact
Certificates issued for non-authentication purposes may be accepted for TLS client or server authentication, weakening certificate-based access controls in mixed-platform MongoDB deployments.
Affected Products
- MongoDB Server v7.0 prior to 7.0.26 (Windows and Apple platforms)
- MongoDB Server v8.0 prior to 8.0.16 (Windows and Apple platforms)
- MongoDB Server v8.2 prior to 8.2.2 (Windows and Apple platforms)
Discovery Timeline
- 2025-11-25 - CVE-2025-12893 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2025-12893
Vulnerability Analysis
The vulnerability resides in MongoDB Server's TLS certificate validation logic on Windows and Apple operating systems. The X.509 Extended Key Usage extension restricts the purposes for which a certificate key may be used. RFC 5280 requires that when EKU is present, the certificate must be rejected for purposes not listed.
MongoDB fails to enforce this constraint on non-Linux platforms. A certificate presenting extendedKeyUsage values such as codeSigning or emailProtection, but omitting clientAuth, is still accepted for ingress TLS client authentication on both Windows and Apple builds. On Apple builds, the server component similarly accepts peer certificates without serverAuth during outbound TLS connections.
The impact is limited by the attacker prerequisites. An adversary must possess a valid, trust-anchored certificate whose EKU set excludes authentication usages. This condition typically arises where an internal certificate authority issues purpose-restricted certificates that operators assume cannot be used to authenticate to database services.
Root Cause
MongoDB delegates certificate chain validation to platform-native TLS libraries: Schannel on Windows and Secure Transport on Apple. The server does not perform an explicit post-validation check to confirm that clientAuth or serverAuth is present in the peer certificate's EKU extension. Linux builds using OpenSSL apply this check correctly through X509_check_purpose.
Attack Vector
Exploitation requires network access to a MongoDB TLS endpoint and possession of a certificate signed by a CA trusted by the server. The attacker presents the misissued or repurposed certificate during the TLS handshake. If validation succeeds, the attacker gains an authenticated TLS session mapped to the certificate subject, potentially satisfying MONGODB-X509 authentication requirements.
No working exploit code has been published. Refer to the MongoDB Jira Issue #SERVER-105783 for vendor-supplied technical details.
Detect Identity Attacks the Moment Authentication Fails
Singularity™ Identity surfaces credential misuse, lateral movement, and privilege escalation in real time, so you can contain the breach before it spreads.
Stop Identity AttacksDetection Methods for CVE-2025-12893
Indicators of Compromise
- Successful MONGODB-X509 authentication events in MongoDB audit logs originating from certificate subjects that should not have database access.
- TLS session establishment from client certificates whose EKU extension excludes 1.3.6.1.5.5.7.3.2 (clientAuth).
- Outbound TLS connections from MongoDB processes on macOS to peers presenting certificates without 1.3.6.1.5.5.7.3.1 (serverAuth).
Detection Strategies
- Inventory certificates trusted by MongoDB deployments and identify any lacking authentication-purpose EKU values that could satisfy the flawed validation path.
- Enable MongoDB auditing with --auditDestination and correlate authenticate events against expected certificate subject distinguished names.
- Perform periodic TLS handshake testing against MongoDB endpoints using a certificate with a non-authentication EKU to confirm whether the vulnerable behavior is present.
Monitoring Recommendations
- Forward MongoDB audit and TLS handshake logs to a centralized analytics platform for review of X.509 authentication anomalies.
- Alert on new or unexpected certificate subjects successfully authenticating to production database clusters.
- Track MongoDB Server versions across Windows and macOS hosts to identify instances still running vulnerable releases.
How to Mitigate CVE-2025-12893
Immediate Actions Required
- Upgrade MongoDB Server to 7.0.26, 8.0.16, or 8.2.2 or later, depending on the deployed release branch.
- Audit certificate authorities trusted by MongoDB TLS listeners on Windows and macOS hosts and remove any CAs that issue certificates without strict EKU discipline.
- Rotate any client certificates suspected of being usable through the flawed validation path.
Patch Information
MongoDB has released fixed versions 7.0.26, 8.0.16, and 8.2.2 that enforce EKU validation on Windows and Apple platforms consistent with the Linux behavior. Consult the MongoDB Jira Issue #SERVER-105783 for release notes and upgrade guidance.
Workarounds
- Migrate MongoDB Server instances that terminate TLS to Linux hosts, where EKU validation functions correctly, until patches are applied.
- Restrict the CA trust store used by MongoDB to a dedicated internal CA that issues only certificates with the correct clientAuth or serverAuth EKU values.
- Enforce network-level access controls that limit which clients can reach MongoDB TLS ports, reducing the population of certificates that could be presented.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
