MongoDB Alerts
This page lists critical alerts and advisories for MongoDB. See the MongoDB JIRA for a comprehensive list of bugs and feature requests.
General
MongoDB Security Notice
1/23/24 - 6:00 PM EST
MongoDB has published a Post Event Summary for the security incident first reported here on December 16, 2023, US Eastern time (EST). As a reminder, our investigation is complete and closed, with our findings verified by our third-party forensic experts.
1/03/24 - 5:00 PM EST
Our investigation of the security incident first reported here on December 16, 2023, US Eastern time (EST) is now complete and closed.
The investigation led by our security and engineering teams uncovered no evidence of unauthorized access to MongoDB Atlas clusters. This finding has been verified by our third-party forensic experts.
We are committed to being timely and transparent with details about this Security Incident. We plan to release a post event summary as soon as practicable.
1/23/24 - 6:00 PM EST
MongoDB has published a Post Event Summary for the security incident first reported here on December 16, 2023, US Eastern time (EST). As a reminder, our investigation is complete and closed, with our findings verified by our third-party forensic experts.
1/03/24 - 5:00 PM EST
Our investigation of the security incident first reported here on December 16, 2023, US Eastern time (EST) is now complete and closed.
The investigation led by our security and engineering teams uncovered no evidence of unauthorized access to MongoDB Atlas clusters. This finding has been verified by our third-party forensic experts.
We are committed to being timely and transparent with details about this Security Incident. We plan to release a post event summary as soon as practicable.
12/20/23 - 9:00 PM EST
We continue to find no evidence of unauthorized access to MongoDB Atlas clusters or the Atlas cluster authentication system.
Based on the investigation to date, the unauthorized third party used a phishing attack to gain access to some of the corporate applications that we use to provide support services to MongoDB customers. In collaboration with outside forensic experts, we currently have a high level of confidence that the unauthorized third party has been removed from our corporate applications and that this incident is contained.
We have identified a list of contact information and related account metadata that the unauthorized third party accessed from the compromised applications. We are providing the list of fields in the blog post linked below, along with incremental guidance about the indicators of compromise (IOCs) provided in our previous alert.
As previously disclosed, the unauthorized third party primarily accessed MongoDB customer contact information and related account metadata. Over the last 24 hours, MongoDB personnel have individually contacted any customers with exposure beyond the fields listed in our blog post. This was a separate communication from the initial security notice sent over this past weekend.
Moving forward, we will provide updates when we have notable new information.
12/18/23 - 9:00 PM EST
We continue to find no evidence of unauthorized access to MongoDB Atlas clusters or the Atlas cluster authentication system. Our investigation and work with the relevant authorities is ongoing. MongoDB will update this alert page with pertinent information as we further investigate the matter.
At this time, as a result of our investigation in collaboration with outside experts, we have high confidence that we were victims of a phishing attack. Through our investigation, we have identified certain information that may be helpful to protect yourself against a potential attack by this unauthorized party:
Indicators of Compromise (IOCs)
The unauthorized party used the Mullvad VPN. Mullvad has many external IP addresses, and there are many VPNs that can be used to hide an IP address. In this case, we saw malicious activity coming from the following IP addresses:
- 107.150.22.47
- 138.199.6.199
- 146.70.187.157
- 179.43.189.85
- 185.156.46.165
- 198.44.136.69
- 198.44.136.71
- 198.44.140.133
- 198.44.140.199
- 199.116.118.207
- 206.217.205.88
- 66.63.167.152
- 66.63.167.154
- 87.249.134.10
- 96.44.191.132
We recommend using the above information to search your networks for suspicious activity. We are committed to being as transparent in this process as we can and providing information so you can assess risk in your network.
In regards to our previous guidance, here are instructions on how to enable phishing-resistant MFA on MongoDB’s native cloud authentication service. MongoDB Cloud also supports federating your identity from your IDP, please see here.
We have fielded questions from some customers about the authenticity of the e-mail titled: MongoDB Security Notice that our Chief Information Security Officer, Lena Smart, sent over the weekend from mongodbteam@mail1.mongodb.com. We can confirm that this email is legitimate.
12/17/23 - 9:00 PM EST
At this time, we have found no evidence of unauthorized access to MongoDB Atlas clusters. To be clear, we have not identified any security vulnerability in any MongoDB product as a result of this incident. It is important to note that MongoDB Atlas cluster access is authenticated via a separate system from MongoDB corporate systems, and we have found no evidence that the Atlas cluster authentication system has been compromised.
We are aware of unauthorized access to some corporate systems that contain customer names, phone numbers, and email addresses among other customer account metadata, including system logs for one customer. We have notified the affected customer. At this time, we have found no evidence that any other customers’ system logs were accessed.
We are continuing with our investigation, and are working with relevant authorities and forensic firms. MongoDB will update this alert page with additional information as we continue to investigate the matter.
12/16/2023 - 05:25 PM EST
We are experiencing a spike in login attempts resulting in issues for customers attempting to log in to Atlas and our Support Portal. This is unrelated to the security incident. Please try again in a few minutes if you are still having trouble logging in. [The issue involving user login attempts has been resolved as of 10:22 PM EST]
12/16/2023 - 03:00 PM EST
MongoDB is actively investigating a security incident involving unauthorized access to certain MongoDB corporate systems, which includes exposure of customer account metadata and contact information. We detected suspicious activity on Wednesday (Dec. 13th, 2023) evening US Eastern Standard Time, immediately activated our incident response process, and believe that this unauthorized access has been going on for some period of time before discovery. At this time, we are not aware of any exposure to the data that customers store in MongoDB Atlas. Nevertheless, we recommend that customers be vigilant for social engineering and phishing attacks, activate phishing-resistant multi-factor authentication (MFA), and regularly rotate their MongoDB Atlas passwords. MongoDB will update this alert page with additional information as we continue to investigate the matter.
Data Integrity Related
Queries may return incomplete results when Time Series collections created prior to MongoDB 5.2 have been upgraded to MongoDB 6.0 or newer prior to those collections being cloned. Relatedly, Time Series collections on MongoDB Rapid Releases 7.1.0-7.3.3 that had their collection granularity changed via collMod while on those versions, may have also returned incomplete query results.
Atlas, MongoDB Server
6.0.0 - 6.0.16
7.0.0 - 7.0.12
7.1.0 - 7.3.3
A bug can cause incorrect results or crashes when running certain aggregation pipelines containing $group and $lookup while on MongoDB Server version 6.0.17.
MongoDB Server
6.0.17
The Node.js v22.7.0 runtime contains a regression related to its handling of UTF-8 encoding that can impact the data integrity of applications using the MongoDB Node.js driver. MongoDB does not use the affected Node.js version in any of its products, however, developers using MongoDB’s Node.js driver could experience data integrity issues when data is written to their clusters via the Node.js v22.7.0 runtime.
MongoDB Node.js driver
Any MongoDB Node.js driver version if data was written using Node.js v22.7.0
To balance load and maintain a high quality of service, the Atlas Serverless system occasionally migrates data of serverless instances between different database servers. Certain multi-write, non-transactional database commands are not safely auto-retried by Atlas Serverless upon migration completion, which can lead to incorrect updates and deletes behavior.
Atlas Serverless
5.0+
Issues during the initial data copy in mongosync 1.1.0 – 1.7.1 may lead to some writes or documents on the source not being replicated to the destination. Upgrade to mongosync version 1.7.2 or later. Atlas Live Migrate relies on mongosync for migrations to MongoDB 6.0+ and the fix has been applied to Atlas Live Migrate.
Cluster-to-Cluster Sync (mongosync)
1.1.0 - 1.7.1
Issues affecting multi-document transactions on sharded clusters which can cause sharded multi-document transactions to return incorrect data and possibly miss writes.
MongoDB Server
4.4.0 - 4.4.29
5.0.0 - 5.0.25
6.0.0 - 6.0.14
7.0.0 - 7.0.8
7.1.0 - 7.3.1
An issue in mongodump can cause keys in collection options to be dumped in the wrong order. These alterations could change the result set returned by a view or change which documents are accepted by a validator.
Atlas, Mongodump
A fix has been released on Atlas, but free or shared clusters may have been impacted in the past.
Mongodump 4.2.0 - 100.9.0
An issue affecting inserts to Sharded Time Series collections can result in inserted documents on these collections to be immediately orphaned, leading to documents not being returned by queries and potential data loss.
MongoDB Server
5.0.6 - 5.0.21
6.0.0 - 6.0.11
7.0.0 - 7.0.2
A race condition in mongosync 1.5 can lead to some writes on the source not being replicated to the destination. Upgrade to version 1.6 or later.
Cluster-to-Cluster Sync (mongosync)
1.5.0
A storage engine issue can cause inconsistent incremental Ops Manager and Cloud Manager backups. Clusters restored from affected incremental backups can crash with checksum errors. Atlas customers/backups are not affected.
Ops Manager and Cloud Manager
4.4.8 - 4.4.21
5.0.2 - 5.0.17
6.0.0 - 6.0.5
A storage engine bug in MongoDB running on ARM64 or POWER architectures may store documents or index entries out of order, leading to inconsistencies and improperly sorted or incomplete query results.
MongoDB Server
4.2.0 - 4.2.23
4.4.0 - 4.4.18
5.0.0 - 5.0.14
6.0.0 - 6.0.4
6.1.0 - 6.2.0
A MongoDB agent issue in Atlas, Ops Manager, and Cloud Manager can cause automated "rolling index builds" to introduce index inconsistencies. MongoDB clusters on other platforms are not affected.
Atlas, Ops Manager, and Cloud Manager
MongoDB versions 4.2.19+, 4.4.13+, 5.0.6+, 5.1-5.3, and 6.0.0+ running on:
- Atlas - a fix has been released on Atlas, but clusters may have been impacted in the past.
- Ops Manager versions 5.0.10-5.0.14 and 6.0.0-6.0.2
- Cloud Manager running MongoDB Agent version from 11.13.0.7438-1 to 12.4.0.7702-1
A behavior change for improperly configured time-to-live (TTL) indexes can suddenly expire documents when upgrading to MongoDB 5.0 or 6.0 from version 4.4 or earlier.
MongoDB Server
5.0.X
6.0.X
A sharding metadata bug in MongoDB versions 5.0.0-5.0.10 and 6.0.0 can introduce corruption during a movePrimary command.
MongoDB Server
5.0.0 - 5.0.10
6.0.0
A storage engine bug in MongoDB 4.4.3 and 4.4.4 can introduce corruption when upgrading to 4.4.8-4.4.10 or 5.0.2-5.0.5. It is safe to upgrade from versions 4.4.3 and 4.4.4 directly to 4.4.11+ or 5.0.6+
MongoDB Server
4.4.3
4.4.4
A storage engine bug in MongoDB 4.4.2-4.4.8, and 5.0.0-5.0.2 can cause inconsistent data after an unclean shutdown and restart. Upgrade to version 4.4.9 or 5.0.3.
MongoDB Server
4.4.2-4.4.8
5.0.0-5.0.2
A storage engine bug in MongoDB 4.4.8 can cause inconsistent data after an unclean shutdown and restart. Upgrade to version 4.4.9.
MongoDB Server
4.4.8
A storage engine bug in MongoDB 4.4.7, 5.0.0, and 5.0.1 allows some inserts to violate unique index constraints. Upgrade to version 4.4.8 or 5.0.2.
MongoDB Server
4.4.7
5.0.0
5.0.1
A storage engine bug in MongoDB 4.4.5 causes crashes on startup and may cause temporary query correctness issues. Upgrade to version 4.4.6.
MongoDB Server
4.4.5
Possible Corruption of Backup Snapshots on certain MongoDB 4.2+ Products
MongoDB Server
4.2+
Possible buffer overflow may result cause in-memory corruption on MongoDB 4.2.7 with incremental backup enabled.
MongoDB Server
4.2.7
A memory management bug can cause lost documents and index inconsistencies on replica set secondaries that restart during index builds.
MongoDB Server
4.2.0
4.2.1
When MongoDB recovers from an unclean shutdown, it is possible for the recovery process to corrupt documents that have received size-changing updates.
MongoDB Server
3.6.14
3.6.15
A memory management bug can cause failed operations, process crashes, and in-memory corruption of data that may be persisted to disk.
MongoDB Server
4.2.0
We have identified a bug in MongoDB Compass where modification or deletion of a document through Compass may occur on a different document than expected under certain specific conditions.
Compass
1.3.x - 1.11.1
While a background index build is in progress, document updates modifying fields contained in the index specification may, under specific circumstances, cause mismatched index entries to appear. This has an impact on queries that use affected indexes.
Indexing
3.0
3.2
During chunk migrations, insert and update operations affecting data within a migrating chunk are not reflected to the recipient shard, resulting in data loss.
Sharding
3.0.9
3.0.10
In a replica set, if a secondary node is shut down cleanly while replicating writes, the node may mark certain replicated operations as successfully applied even though they have not.
Replication
3.2.0
A race condition in WiredTiger may prevent a write operation from becoming immediately visible to subsequent read operations, which may result in various problems, primarily impacting replication.
WiredTiger
3.0.0 - 3.0.7
Sharded clusters where the balancer is enabled (or there are manual chunk migrations), containing WiredTiger nodes that may become primary, may lose writes to a chunk being migrated if that chunk is under a heavy write load.
Sharding
3.0.0 - 3.0.3
MongoDB installations on certain 3.x Linux kernels running on VMWare and using virtual SCSI disks managed by LVM may see corruption in namespace (.ns) files.
Storage
2.4.11
2.6.4
An update to a text-indexed field may fail to update the text index. As a result, a text search may not match the field contents, yielding incorrect search results.
Text Search
2.4.0 - 2.4.10
2.6.0
Under very rare circumstances mongos may incorrectly report a write as successful.
Sharding
2.2.0 - 2.2.6
2.4.0 - 2.4.8
During a chunk migration in a sharded cluster, if one of the documents in the chunk has a size in the range of 16,776,185 and 16,777,216 bytes (inclusive), then some documents may be lost during the migration process
Sharding
2.2.0 - 2.2.5
2.4.0 - 2.4.4
Secondary indexes (i.e. all indexes other than _id) may be corrupted on an initial sync if write operations are performed on the sync source during the initial sync.
Replication
2.4.0
Operations Related
Caching of dbhash results may result in stale values, potentially causing disagreement among sharded cluster config servers.
MongoDB Server
2.4.7