Improper X.509 certificate validation in MongoDB Inc. MongoDB Enterprise Kubernetes Operator can grant unauthorized MongoDB access

X.509 certificates generated by the MongoDB Enterprise Kubernetes Operator may allow an attacker with access to the Kubernetes cluster improper access to MongoDB instances. Customers who do not use X.509 authentication, and those who do not use the Operator to generate their X.509 certificates are unaffected. This issue affects MongoDB Enterprise Kubernetes Operator version 1.0, MongoDB Enterprise Kubernetes Operator version 1.1, MongoDB Enterprise Kubernetes Operator version 1.2 versions prior to 1.2.4, MongoDB Enterprise Kubernetes Operator version 1.3 versions prior to 1.3.1, 1.2, 1.4 versions prior to 1.4.4.

The affected scope is limited to MongoDB Enterprise Kubernetes Operator deployments that use X.509 authentication and certificates generated by the Operator.

• MongoDB Enterprise Kubernetes Operator 1.0: affected.
• MongoDB Enterprise Kubernetes Operator 1.1: affected.
• Branch 1.2.0 through 1.2.4: affected. MongoDB's release source identifies 1.2.5 as fixed.
• Branch 1.3.0 through 1.3.1: affected. The inspected evidence does not establish a specific fixed release for the 1.3 branch.
• Branch 1.4.0 through 1.4.4: affected. MongoDB's release source identifies 1.4.5 as fixed.
• Customers who do not use X.509 authentication or do not use the Operator to generate X.509 certificates are stated to be unaffected.

The affected component is the X.509 certificate generation logic in MongoDB Enterprise Kubernetes Operator. Generated certificates may fail to enforce the intended trust relationship, allowing a certificate to be used for improper access to MongoDB instances; this is classified as CWE-295, Improper Certificate Validation. The attacker must already have access to the Kubernetes cluster, the deployment must use X.509 authentication, and the certificates must have been generated by the Operator. The record does not identify the certificate field, trust chain, or validation decision that is mishandled, so the precise implementation defect remains unknown. The available assessments differ between network and adjacent-network reachability, so the practical access path depends on the cluster topology and the attacker's Kubernetes access.

The attacker must have access to the Kubernetes cluster and target a deployment that uses X.509 authentication with certificates generated by MongoDB Enterprise Kubernetes Operator. The supplied data indicates low privileges and no user interaction, but it does not define the minimum Kubernetes permissions required. Available assessments differ on whether the path is network or adjacent network, so reachability depends on deployment configuration. The supplied evidence does not establish active exploitation or a public exploit; the actual exploitation status remains unknown.

The confirmed technical outcome is that X.509 certificates generated by the Operator may enable improper access to MongoDB instances. Exposure of MongoDB data is supported by the record. The CNA assessment indicates possible integrity impact, but another assessment does not confirm it, so modification capability should not be assumed without checking the certificate and database permissions. The scope is assessed as unchanged, and no availability impact is established. Organisational consequences depend on the data held by the instances, the privileges granted through the certificates, and the ability to isolate the Kubernetes cluster.

The flaw may expose data in MongoDB instances to which the affected certificates provide access. The CNA assessment also treats unauthorized data modification as possible, while another assessment limits the stated impact to confidentiality, so integrity risk should be evaluated against the certificate's actual permissions and MongoDB configuration. No availability impact is established in the record. Operational consequences may include access investigation, data validation, and replacement of the affected Operator or certificates under a supported remediation plan.

1. Identify the MongoDB Enterprise Kubernetes Operator version, whether X.509 authentication is enabled, and the source that generated the certificates in use.
2. For the 1.2 branch, upgrade to 1.2.5, which MongoDB's release source identifies as fixed.
3. For the 1.4 branch, upgrade to 1.4.5, which MongoDB's release source identifies as fixed.
4. For 1.0, 1.1, and the 1.3 branch, the inspected evidence does not identify a specific fixed release. Obtain a MongoDB-supported upgrade path before making a change.
5. If the deployment does not use X.509 authentication or does not use the Operator to generate certificates, document that exclusion while confirming the configuration has not changed unexpectedly.
6. The record and inspected sources do not provide a separate mitigation beyond confirming the exposure conditions and using a release explicitly identified as fixed.

1. Inventory all MongoDB Enterprise Kubernetes Operator deployments and compare the running version with the affected and fixed branches listed in affected_summary.
2. Determine whether MongoDB deployments use X.509 authentication.
3. Determine whether the X.509 certificates in use were generated by MongoDB Enterprise Kubernetes Operator.
4. Review Kubernetes permissions for principals that can access the cluster, especially permissions to read, use, or modify Secrets and MongoDB-related resources.
5. As a precaution, review Kubernetes audit logs and MongoDB audit or authentication logs for unexpected X.509 sessions or access. These are defensive monitoring checks, not confirmed indicators of compromise.
6. The absence of suspicious events does not prove safety; version and authentication-source checks are the primary exposure tests.