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¶
- 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|
|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.