Skip to main content

June 2026 Security Release (Updated)

The article below is a substantial update over the original version published on June 10th, 2026. It has been specifically updated to address the additional urgent release of CVE-2026-11933 on June 11th.

Written by Vasile

At MongoDB, security is our top priority. Our security team continuously monitors for, and addresses, potential vulnerabilities and attempted misuse to ensure the integrity and safety of your environments. Below, we first share what you need to know to enhance your protection of your use of MongoDB products. We also explain why we have done two back-to-back security releases, and how MongoDB thinks about patching predictability and security.


New Security Fixes

Today, we're providing an important update regarding a set of recently remediated vulnerabilities in MongoDB Server. On June 11th, this article was updated to address the additional urgent release of CVE-2026-11933.

MongoDB customers should update to the latest release (MongoDB Server versions 8.3.4, 8.2.11, 8.0.26, and 7.0.37) that addresses each of the security advisories ("CVEs") we issued on June 9th and June 11th, 2026. These are all listed below. There are 2 situations that require additional action.

  • Additional action needed: MongoDB customers who have enabled LDAP (LDAP is not enabled by default) should:

    1. Upgrade to a patched release, and

    2. Change the associated LDAP bind credentials. Details are below.

  • Additional action needed: MongoDB customers running specific builds of 8.3.0, 8.3.1, or 8.3.2 should:

    1. Upgrade to a patched release (8.3.4) and

    2. MongoDB Server EA customers should change the keyfile. Details are below.

The CVE released on June 11th, CVE-2026-11933, does not require any additional action beyond patching.

Who is Affected and What Action is Suggested

For MongoDB Atlas Customers:

Action Required:

  • Please allow all maintenance to complete (if you have deferred any), and then

  • If you are using LDAP, you should change your LDAP credentials to mitigate any risk of those credentials being misused.

    • To do this, first a set a new bind username and password, then apply it. Once you have confirmed LDAP logins are working as expected, you can remove the old bind account details.

For Enterprise Advanced/Self-Managed Customers using LDAP:

Action Required:

  • First upgrade to a patched version that covers all the June releases.

  • Once running a patched version, you should change your LDAP credentials to mitigate any risk of those credentials being misused.

For Enterprise Advanced/Self-Managed Customers on MongoDB Server 8.3 < 8.3.4:

Action Required:

  • Customers on MongoDB Server 8.3 should upgrade to the latest version of MongoDB Server (8.3.4 or higher). After this you should change your keyfiles only if upgrading from versions 8.3.0, 8.3.1, or 8.3.2.

You can download these versions from the MongoDB downloads page. We strongly recommend that you plan for this upgrade as soon as possible.

How to Prioritize This Update

We recommend that all customers upgrade to a supported patched release:

  • 15 security advisories (listed below) are patched in our June releases; you should upgrade to the latest minor release to address each of these.

    • The patched versions of MongoDB Server are 8.3.4, 8.2.11, 8.0.26, and 7.0.37.

  • Users of version 8.3.0 - 8.3.2 should also change the keyfile after upgrading to 8.3.4, as described above. If you have already upgraded to 8.3.3 and changed the keyfile, you don’t need to change the keyfile again.

  • Users of LDAP should replace the bind username/password after upgrading, as described above.

Prioritize an accelerated upgrade and keyfile update if:

  • Untrusted parties may have access to your MongoDB logs or your LDAP credentials grant access to sensitive LDAP data or operations.

You can plan this as part of your standard patch cycle if:

  • Database log file access is limited to a small number of trusted internal administrators and tightly controlled service accounts.

  • You have strong access controls and monitoring in place.

As with any security patch, customers should consider their specific environment, access controls, and risk posture when assessing potential impact and deciding how quickly to apply these patches and credential changes. We have no indication that any data breach has occurred. The action requested here is part of MongoDB's commitment to continuously improve our software and protect our customers.

List of Security Advisories (CVEs)

The following are the security advisories (CVEs) included in the June 9th and June 11th MongoDB Server releases. Each is denoted with their “CVSS” score; please see our advice about CVSS scores.

  1. CVE-2026-9735: CVSS Score v3.1: 5.5/10, CVSS Score v4.0: 6.8/10

  2. CVE-2026-9740: CVSS Score v3.1: 7.5/10, CVSS Score v4.0: 8.7/10

  3. CVE-2026-9741: CVSS Score v3.1: 6.5/10, CVSS Score v4.0: 7.1/10

  4. CVE-2026-9742: CVSS Score v3.1: 7.5/10, CVSS Score v4.0: 8.2/10

  5. CVE-2026-9743: CVSS Score v3.1: 6.5/10, CVSS Score v4.0: 7.1/10

  6. CVE-2026-9746: CVSS Score v3.1: 6.5/10, CVSS Score v4.0: 7.1/10

  7. CVE-2026-9747: CVSS Score v3.1: 6.5/10, CVSS Score v4.0: 7.1/10

  8. CVE-2026-9748: CVSS Score v3.1: 6.5/10, CVSS Score v4.0: 7.1/10

  9. CVE-2026-9749: CVSS Score v3.1: 6.5/10, CVSS Score v4.0: 7.1/10

  10. CVE-2026-9750: CVSS Score v3.1: 5.6/10, CVSS Score v4.0: 4.1/10

  11. CVE-2026-9751: CVSS Score v3.1: 5.5/10, CVSS Score v4.0: 6.8/10

  12. CVE-2026-9752: CVSS Score v3.1: 6.5/10, CVSS Score v4.0: 7.1/10

  13. CVE-2026-9753: CVSS Score v3.1: 8.1/10, CVSS Score v4.0: 7.2/10

  14. CVE-2026-9754: CVSS Score v3.1: 6.5/10, CVSS Score v4.0: 7.1/10

  15. CVE-2026-11933: CVSS Score v3.1: 8.8/10, CVSS Score v4.0: 8.7/10 (Added on June 11th)

Our Commitment to Security and Ease of Software Updates

We have heard two messages clearly from customers as we, and the industry, increase our rate of security fixes in the Age of AI: (1) please make it easy for me to patch, and (2) please get security fixes out to me quickly. Our back-to-back security fixes (June 9th and June 11th) demonstrate both of these in action. The 14 security fixes released on June 9th are part of our new, predictable cadence to release security fixes on a monthly basis.

As mentioned earlier, MongoDB’s security team continuously monitors for, and addresses, potential vulnerabilities and attempted misuse. On June 10th, MongoDB monitored an industry-wide security development which convinced us to move rapidly to release another new version of MongoDB Server. This is our commitment to your protection in action: when we see that an urgent release is necessary, we move quickly while prioritizing the operational safety and stability of your Atlas clusters and EA deployments.

When we need to urgently release a new version of MongoDB Server, we use well-practiced standard operating procedures to release minimalist changes (minimizing the number of changes over the software that customers are already using in Atlas or on-prem) that are thoroughly tested and carefully reviewed.

When we create our release plans, we are working backwards from the Atlas and MongoDB Enterprise Advanced customer experiences of having these patches land in your software stack. Not all security fixes are urgent (in fact, most are not) so we batch them up whenever the security and operational risk assessments support batching (hence the batch in the June 9th release). When the security risk is sufficiently high, we have demonstrated our commitment to moving quickly to protect customers (i.e., the June 11th release).

MongoDB Enterprise Advanced customers with robust internal automation, testing, and qualification are finding it straightforward to adapt to the increasing rate of security fixes in the industry. In Atlas, MongoDB takes care of the MongoDB Server deployments for you, minimizing the amount customers need to think about patching.

MongoDB is dedicated to protecting your data and ensuring the reliability of our services. We will continue to adopt the latest security and AI-based techniques to further harden our products. We thank you for your continued trust.

Did this answer your question?