May 12th, 2026 Patch Release Additional Information - CVE-2026-8053

At MongoDB, security is our top priority. Our security team continuously monitors for, and addresses, potential vulnerabilities to ensure the integrity and safety of your environments. Today, we are providing an important update regarding six recently remediated vulnerabilities in MongoDB Server. MongoDB Atlas customers do not need to take any action, and MongoDB Server customers and users should promptly upgrade to the latest releases, per below.

This is a notification of a security patch to MongoDB's software that addresses a vulnerability. This is not a security or data breach. We have no indication of active misuse of this vulnerability against our customers at this time.

MongoDB identified and patched six security vulnerabilities, identified as:

CVE-2026-8053 could allow an authenticated actor, under specific conditions outlined in the next section, to potentially gain unauthorized access to data managed by your deployment. As a result, this Knowledge Base article will focus on CVE-2026-8053 as it is the most important issue. If you want additional details on the other issues, please read the linked CVE advisories above. We recommend prioritizing this update to maintain the confidentiality of your environment and protect against unauthorized data exposure.

Through MongoDB’s proactive security program, a "remote code execution" vulnerability was identified that, under some specific conditions, might allow unauthorized access to the MongoDB Server. More information about this vulnerability can be found at CVE-2026-8053.

The following specific conditions must all be present for an unauthorized party to take advantage of this vulnerability:

MongoDB recommends that customers deploy this patch promptly to protect your databases.

We strongly recommend upgrading to one of the fixed builds below. See the appropriate section for your deployment type.

Upgrade your MongoDB Server version to one of the following patch versions:

Visit the downloads page to download the latest binaries.

Upgrade your MongoDB Server version to one of the following patch versions:

Visit the downloads page to download the latest binaries.

If using Automation, see Change the Version of MongoDB.

If using Local Mode you must first populate your Versions Directory on each Ops Manager with the correct OS specific binaries from the MongoDB Ops Manager Download site. See Configure Deployment to Have Limited Internet Access.

Upgrade your MongoDB Server version to one of the following patch versions:

If using Automation, see Change the Version of MongoDB.

Adjust the spec.version of your MongoDB Deployments to the latest patch of your current major release:

This discovery highlights the importance of our multi-layered approach to security, including rigorous internal audits and our active Bug Bounty Program that incentivizes external researchers. We are constantly working to identify and mitigate risks before they can impact our customers.

For more details on how to configure your environments securely, please consult our MongoDB self-managed security checklist and the MongoDB Atlas security documentation.

MongoDB is dedicated to protecting your data and ensuring the reliability of our services. We thank you for your continued trust.

MongoDB Atlas customers do not need to take action to receive the fix. Self-managed MongoDB Server deployments should upgrade promptly to a fixed version.

If you run a self-managed deployment, upgrade to one of the following patch versions: 5.0.33, 6.0.28, 7.0.34, 8.0.23, 8.2.9, or 8.3.2/

Atlas customers can verify maintenance history in the Atlas UI and confirm that their cluster is already running the patched version. If there is no pending maintenance, or pending maintenance does not include a MongoDB patch version upgrade, the cluster has already been upgraded.

As noted in the Atlas Maintenance Window Documentation, Atlas may perform urgent maintenance activities (such as security patches for zero-day vulnerabilities) as soon as necessary without regard to configured maintenance windows or protected hours.

No. Applying the patch is the only way to fully remediate this issue.

If you cannot patch immediately, use defense-in-depth measures until you can upgrade. In particular, restrict network access to trusted sources, review and rotate credentials, and reduce unnecessary write privileges where feasible. These steps reduce risk, but they should not be treated as a full mitigation in place of the patch.

No. If your deployment is already running a fixed version, no additional action is required for this issue.

Yes. If you use Ops Manager, its backing databases are MongoDB databases and include the Ops Manager Application Database plus backup databases, such as the Oplog Store and blockstore. If any of those backing databases are running affected MongoDB Server versions, they should also be upgraded to a fixed version. If they are already running fixed versions, no additional action is required for this issue.

Please open a chat or a MongoDB Support case (if you have an active support plan) and include the custom build version you are currently running. MongoDB Support will coordinate with engineering to determine the availability of an updated build and next steps. If available, including the build's gitVersion may help speed review.

This issue was identified through MongoDB's proactive security program and subsequently addressed by Engineering via a patch release.

At this time, MongoDB is not aware of evidence that customer metadata was accessed improperly.

At this time, MongoDB is not aware of evidence that customer data stored in MongoDB was accessed improperly.

A patch was developed, tested, and released to address the issue.

MongoDB will continue to scrutinize its code and issue fixes when warranted as part of its ongoing security efforts.

An air-gapped or otherwise isolated network can reduce the opportunity for attack, but it does not eliminate risk. Unpatched clusters could still be exposed through a compromised internal asset or a trusted user within your environment. MongoDB recommends applying the mitigation regardless of internet connectivity.

MongoDB is currently unaware of any external parties having discovered or exploited this issue.

No. This is a security patch to address a vulnerability in MongoDB software, not a notice of a cyber attack or data breach.

MongoDB is sharing remediation guidance and fixed versions, but will not provide exploit-enabling detail in this article.

MongoDB understands the importance of assessing regulatory impact. However, whether any reporting or disclosure obligation applies depends on the specific laws and regulations that govern your organization, along with your specific facts and circumstances. Customers should consult their own legal and compliance teams.

For self-managed deployments, review core hardening measures including enabling access control, following least-privilege role design, enforcing TLS, limiting network exposure, and auditing system activity.

For Atlas deployments, review network restrictions such as IP allowlists, private endpoints or VPC peering, use role-based access control, and ensure auditing and logging are enabled as appropriate for your environment.

For self-managed deployments, review the MongoDB Security Checklist for guidance on authentication, authorization, TLS, limiting network exposure, and auditing.

For Atlas deployments, review the Atlas security guidance covering network security, authentication and authorization, encryption, compliance, and auditing.