This page lists critical alerts and advisories for MongoDB. This page is a work in progress and will be enhanced over time.
See <http://jira.mongodb.org/> for a comprehensive list of bugs and feature requests.
Data Integrity Related¶
- MongoDB installations on some Linux systems (certain 3.x Linux kernels, including Ubuntu 12.x, 14.x, and Fedora 20) that are running on VMWare and are using virtual SCSI disks managed by LVM may see corruption in namespace files. MongoDB requires initial zeroing of namespace files upon creation. A request to the operating system to zero a .ns file may fail to completely zero the file, leaving the previous contents of some disk locations exposed as part of the .ns file. This incomplete zeroing yields a corrupt .ns file, and may affect MongoDB in various ways. See SERVER-15369 for more information.
- An update to a text-indexed field may fail to update the text index. As a result, a text search query may not match the field contents, producing incorrect or incomplete search query results. Specifically, an in-place update may produce incorrect index entries if it modifies a text-indexed field and does not modify another index. This issue affects MongoDB versions 2.4.0 through 2.4.10, and 2.6.0 through 2.6.3. Version 2.6.4 includes a fix for this issue. See SERVER-14738 for more information.
- mongos may incorrectly report a write as successful in the unlikely event that the mongos reuses a previously-used connection from the shared pool which contains a stale writeback field. In this situation, mongos cannot guarantee the correct post-migration location of writes and thus may report the write results incorrectly. Since mongos outgoing connections are tied to incoming client connections, this can only occur in cases of high connection churn. The bug is difficult to trigger, but has caused a dropped write in one known case. Upgrading all mongos processes to MongoDB v2.4.9 or v2.2.7 will address this issue. See SERVER-12146 for more information.
- 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. This affects versions 2.2.5 and 2.4.5, and is fixed in 2.2.6 and 2.4.6. See SERVER-10478 for more information.
- 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. This affects version 2.4.0 and is fixed in 2.4.1. See SERVER-9087 for more information.
- Documents may be missing on a replication secondary after initial sync if a high number of updates occur during the sync that move the document (i.e., the documents are growing).
- When stepping down a replica set primary, the primary’s connection to clients is not automatically closed in 2.0.1. This means that if the primary steps down while an application is issuing fire-and-forget write, the application won’t necessarily fail over until it issues a query. Applications that only issue safe writes are not affected by this. The issue is fixed in 2.0.2. See <https://jira.mongodb.org/browse/SERVER-4405> for details.
- 2.4.7 added an optimization to cache results from the dbhash command (SERVER-11021). Not all operations on the config server reset this cache. As a result, dbhash sometimes returns old values. This issue does not affect correctness: the data in the config.chunks collection is always correct. However, if only one config server restarts, that config server may report a different dbhash for the config.chunks collection than the other config servers on startup. This may prevent new mongos instances from starting until the dbhash for all config servers agree. If the balancer is enabled, mongos will periodically log a message warning that it has detected that the “config servers differ” and will prevent further migrations. This issue affects version 2.4.7: 2.4.8 resolves this issue. See SERVER-11421 for more information.
|Date||Component||Description||Affects Versions||Fixed in Versions||CVE||Ref|
|03/27/2015||mongod||Remotely trigger a denial of service (crash) due to failure to check for missing value.||3.0.0||3.0.1||CVE-2015-2705||SERVER-17521|
|03/25/2015||mongod||Remotely trigger a denial of service (crash) via a specially crafted regular expression.||2.6.8 and earlier, 3.0.0||2.6.9 and 3.0.1||CVE-2015-2327, CVE-2015-2328||SERVER-17252|
|02/25/2015||mongod||A specially crafted, malformed BSON message may trigger an uncaught exception in the server, resulting in a loss of availability||2.6.7 and earlier, 2.4.12 and earlier||2.6.8 and 2.4.13||CVE-2015-1609||SERVER-17264|
|06/17/2014||mongod||Remotely trigger a crash when X.509 authentication is enabled||2.6.0, 2.6.1||2.6.2||CVE-2014-3971||SERVER-13753|
|05/05/2014||mongod||Information disclosure of user credentials||2.6.0||2.6.1||CVE-2014-2917||SERVER-13644|
|06/20/2013||Concurrency, Security||Improperly grant user system privileges on databases other than local.||2.4.0 - 2.4.4, 2.5.0||2.4.5, 2.5.1||CVE-2013-4650||SERVER-9983|
|11/27/2012||mongod and mongos||Object validation (--objcheck) not performed by default.||2.3.1 and earlier||2.3.2||CVE-2012-6619||SERVER-7769|
|10/02/2012||Authentication||Password hashing insecurity.||2.2-series and earlier.||2.4.0||CVE-2012-5241||Docs|
Make sure to subscribe to <http://groups.google.com/group/mongodb-announce> for important announcements.