MongoDB セキュリティ告知
(mongodb.com)- MongoDB Alerts は、データ整合性・運用・CVE セキュリティ問題を一か所に集約し、バージョンごとの影響範囲と対応が必要な MongoDB デプロイメントを確認できる告知ハブ
- 2026年のデータ整合性項目には、clustered collection の
_id降順範囲クエリの不具合、sharded cluster の unique index での重複許容、Relational Migrator の移行漏れ、shard への直接接続時に read/write concern が適用されない問題が含まれる - 運用面では、2026年4月までに主要な公的 CA が clientAuth EKU を含む TLS 証明書の発行を停止するため、self-managed MongoDB の mTLS・X.509 認証構成に影響する可能性がある
- セキュリティセクションでは、2019年から2026年までの MongoDB Server、Compass、mongosh、ドライバー、Ops Manager などの CVE 一覧を製品別に提供
- 実務担当者は、利用中の Server、Atlas、Relational Migrator、Compass、mongosh、各言語ドライバーのバージョンを影響範囲と照合し、パッチバージョンへのアップグレードや告知された回避設定を適用する必要がある
MongoDB Alerts ページが扱う範囲
- MongoDB Alerts は、MongoDB の 重要な警告と勧告をまとめたページ
- 包括的なバグおよび機能要望の一覧は MongoDB JIRA で確認できる
- 新しい告知は RSS Feed でも提供される
- ページは次のカテゴリで構成される
- Data Integrity Related
- Operations Related
- Security Related: Common Vulnerabilities and Exposures (CVEs)
- General
2026年のデータ整合性警告
-
clustered collection の
_id降順範囲クエリ- 2026年6月17日告知
- clustered collection で
_idフィールドに降順ソートを適用し、{$lt: A},{$gt: A},{$gte: A, $lt: B},{$gt: A, $lte: B}形式の範囲条件を使うと、境界ドキュメントが誤って含まれたり除外されたりする可能性がある - time series collection、non-clustered collection、
_id降順ソートを適用していない clustered collection、同じ包含/除外タイプの比較演算子の組み合わせは影響を受けない - 影響バージョン:
- MongoDB 8.0.0–8.0.23
- 8.2.0–8.2.9
- 8.3.0–8.3.2
- SERVER-121822
-
sharded cluster の unique index における重複保証
- 2026年5月14日告知
- sharded cluster で shard key が index key pattern と同一または strict prefix で、unique index が non-simple collation を使う場合、shard 間で 一意性が強制されない可能性がある
"YES"と"yes"のように byte 値は異なるが collation 上は同じ値が、別々の shard に独立して入力される可能性がある- 問題の条件は、2つ以上の shard、non-simple collation の unique index、shard key が index key pattern と同一または strict prefix の場合
- 影響バージョン:
- 5.0.0–5.0.32
- 6.0.0–6.0.28
- 7.0.0–7.0.31
- 8.0.0–8.0.20
- 8.2.0–8.2.6
- SERVER-85346
-
Relational Migrator の移行漏れ
- 2026年5月14日告知
- Relational Migrator で移行したユーザーは、sharded cluster migration において embedded document や embedded array がある場合、ドキュメント欠落が発生する可能性がある
- embedded array 配下に除外された foreign key を持つ cyclic mapping、複数の composite foreign key 関係で使われた source table column、競合する field name の選択は、欠落・不整合・誤命名フィールドを生む可能性がある
- 影響製品は MongoDB Relational Migrator 1.16.0 未満
- SERVER-126522
-
shard への直接接続時に read/write concern が未適用
- 2026年5月14日告知
mongosを経由せず shard node に直接接続すると、cluster-wide default read/write concern が適用されない可能性がある- この場合、write は設定済み concern ではなく
{w: 1}で実行されることがあり、rollback が発生すると acknowledged write が失われる可能性がある - sharded cluster へは
mongos経由でのみ接続すべき - shard への直接接続が必要な場合は、直ちにパッチバージョンへアップグレードするか、connection string に
{w: "majority"}のような明示的な read/write concern を指定する必要がある - 影響バージョン:
- 5.0.0–5.0.32
- 6.0.0–6.0.28
- 7.0.0–7.0.31
- 8.0.0–8.0.19
- 8.2.0–8.2.3
- SERVER-111031
最近のデータ整合性警告で繰り返されるパターン
-
sharding と migration
- 2026年3月の項目では、shard key prefix を含む compound wildcard index がある sharded collection で、chunk migration 中にデータ損失のリスクがあることを扱っている
- 2025年11月には、cross-shard transaction が特定の failover 条件で部分的にコミットされる可能性がある問題が登録された
- 2024年4月には、sharded multi-document transaction が誤ったデータを返したり write を欠落させたりする問題が含まれた
-
time series collection
- 2025年11月の項目では、time series collection の metric data に対する 2dsphere index key が生成・挿入されず、geospatial query が不完全な結果を返す可能性があると告知している
- 2025年8月の項目では、特定の double-precision metric 入力パターンがデータ破損を引き起こす可能性のある問題を扱っている
- 2025年1月の項目では、
ordered: falseの同時 insert と retryable writes の組み合わせで、time series collection にデータ損失の可能性が含まれている
-
クエリ結果の正確性
- 2026年3月には、
$sort直後に$groupが$topまたは$bottomaccumulator を使う aggregation query が誤った結果を返す可能性がある問題が登録された - 2026年2月には、SQL interface で
WHERE句のOR条件の一方がUNKNOWN、もう一方がTRUEのときに誤った結果を返す可能性がある - 2025年6月には、
$elemMatchと文字列 predicate を含むクエリが、collation が一致しない index を使って本来含まれるべきドキュメントを欠落させる可能性がある
- 2026年3月には、
運用関連の警告
-
公的 CA の clientAuth EKU ポリシー変更
- 2026年1月22日告知
- 主要な公的 Certificate Authority は、2026年4月までに client authentication(clientAuth) Extended Key Usage を含む TLS 証明書の発行を停止するというポリシー要件を適用する
- この変更は、mutual TLS(mTLS) または X.509 認証に public CA 証明書を使う self-managed MongoDB デプロイメントにのみ影響する
- self-managed の顧客は、2026年4〜5月の期限前に private PKI infrastructure へ移行するか、MongoDB の設定を変更する必要がある
- Atlas の顧客は影響を受けない
- 影響範囲:
- X.509 Cluster Authentication
- X.509 Client Authentication
- Google Trust Services、Let’s Encrypt、DigiCert、Sectigo の public CA 証明書を使う mTLS
- 関連告知
-
mongosh と Node.js REPL autocomplete
- 2025年9月30日告知
- Homebrew または npm package manager でインストールした MongoDB Shell のような third-party distribution は、Node.js REPL バグの影響を受ける可能性がある
- autocomplete 中に意図しない side effect が発生する可能性がある
- 影響範囲は、Node.js 20.19.5–24.7.0 とともに使う mongosh 2.5.8 未満
- MONGOSH-2635
-
FIPS mode と OpenSSL 3
- 2025年9月11日告知
- Linux で OpenSSL 3 を cryptographic operation に使う FIPS mode 設定の MongoDB が、non-FIPS provider の cryptographic algorithm を使用する可能性がある
- この場合、client は non-FIPS-compliant な cryptographic algorithm で FIPS-mode MongoDB に TLS 接続できてしまう可能性がある
- 影響バージョン:
- 6.0.0–6.0.25
- 7.0.0–7.0.22
- 8.0.0–8.0.12
- SERVER-109268
2026年の CVE セキュリティ告知
-
MongoDB Server の脆弱性
- 2026年6月12日の CVE-2026-11933 は、server-side JavaScript BSON-to-array conversion における post-authentication use-after-free 脆弱性で、スコアは 8.8
- 影響バージョンは 8.3.3 以前、8.2.10 以前、8.0.25 以前、7.0.36 以前、6.0.28 以前、5.0.33 以前、4.4.30 以前
- SERVER-128125
-
pre-authentication denial of service
- CVE-2026-9740 は、BSONColumn interleaved-reference の unbounded recursion により pre-auth stack overflow を引き起こす可能性があり、スコアは 8.7
- 影響バージョンは 8.3.3 未満、8.2.10 未満、8.0.24 未満、7.0.35 未満
- SERVER-125063
- CVE-2026-25611 は、unauthenticated message によりメモリを枯渇させる可能性がある pre-authentication memory exhaustion denial of service で、スコアは 8.7
- 影響バージョンは 8.2.4 未満、8.0.18 未満、7.0.29 未満
- SERVER-116210
-
ログに残る機密情報
- CVE-2026-9735 は、MongoDB Server が authentication parameter と credential を server log に記録してしまう問題で、MongoDB Server 8.3.3 未満が影響範囲
- SERVER-126506
- CVE-2026-9751 は、
ldapQueryPasswordparameter が runtimesetParametercommand で設定された際に、機密情報がmongod.logに記録される可能性がある問題 - 影響バージョンは 8.3.3 未満、8.2.10 未満、8.0.24 未満、7.0.35 未満
- SERVER-123370
-
サーバークラッシュと可用性の問題
- CVE-2026-9754 は、
filemd5command で read role を持つ authenticated user が初期化されていない stack memory の一部を読み取れる問題で、スコアは 7.1 - CVE-2026-9753 は、malformed binary diff が
$_internalApplyOplogUpdateに渡されたときに server crash を引き起こす可能性がある - CVE-2026-9752 は、strict-winding polygon を含む
GeometryCollectionが 2dsphere index key generation 中に server crash を引き起こす可能性がある - CVE-2026-9749 は、
MaxKey()使用時に server crash が発生する可能性がある
- CVE-2026-9754 は、
-
ドライバーとツール
- CVE-2026-9101 は、Compass の CSV parsing における prototype pollution で、影響バージョンは Compass 1.36.3 から 1.49.5 まで
- CVE-2026-9100 は、C Driver の legacy GridFS file reader における heap memory out-of-bounds read および crash の問題
- CVE-2026-6811 は、MongoDB PHP driver の stack exhaustion により application crash を引き起こす可能性がある
- CVE-2026-2303 は、MongoDB Go Driver の GSSAPI C wrapper における heap out-of-bounds read により、application crash または information leak を可能にする
- CVE-2026-2302 は、MongoDB Ruby Driver の
Mongoid::Criteria.from_hashにおける unsafe reflection の問題
-
Ops Manager の RCE
- CVE-2026-8431 は、Ops Manager の webhook body を介した RCE で、スコアは 9.4
- administrative user が webhook を設定できる場合、payload 内の特定の値を通じて任意のコマンドを実行できる
- 影響範囲は Ops Manager 7.0 から 8.0.23 未満まで
- Ops Manager release notes
2025年以降のセキュリティ告知で頻出する製品群
-
MongoDB Server
- server crash、denial of service、privilege escalation、certificate validation、malformed BSON、aggregation、query planner、sharding、time series 関連の CVE が繰り返し登録されている
- 影響バージョンは MongoDB 5.0、6.0、7.0、8.0、8.1、8.2、8.3 系列にまたがり、告知ごとに異なる
-
クライアントとドライバー
- C Driver、PHP Driver、Go Driver、Ruby Driver、Rust Driver、Node.js Driver、Java driver、.NET/C# Driver、PyMongo、libbson、js-bson などが影響製品として登場する
- 一部の項目では、authentication-related data が command listener または connection pool event listener に露出する問題を扱っている
-
運用ツール
- Compass、mongosh、MongoDB for VS Code、Atlas Kubernetes Operator、Enterprise Kubernetes Operator、Ops Manager、Cloud Manager、BI Connector、Atlas SQL ODBC driver、Database Tools が影響製品に含まれる
- Windows インストール MSI の ACL 設定漏れ、local privilege escalation、control character injection、MITM 関連の入力検証不足などが含まれる
一般セキュリティ告知
- General セクションには、2023年12月16日に最初に公開されたセキュリティ incident の更新が含まれる
- 2023年12月28日と12月29日の項目では、MongoDB Atlas cluster または Atlas cluster に保存された customer data への unauthorized access の証拠は見つからなかったと述べている
- 2023年12月26日の項目では、login attempt の急増により顧客ログインの問題が発生していることを告知している
- 2024年1月24日の項目では、MongoDB の post event summary の掲載を案内している
- MongoDB Security Incident Post Event Summary
1件のコメント
Hacker Newsのコメント
いま Atlasアカウントとサポートポータルから完全に締め出されている状態
MongoとOkta認証を使っているが、すべてのログイン試行がログイン画面で「The request contained invalid data.」となって失敗する
問題はサポートポータルも認証が必要で、認証失敗の助けを求めるには認証しなければならない構造になっていること
他の人もダッシュボードへのアクセスに問題があるのか気になる
追記: 米国東部時間午後5時15分ごろに認証が再び動作し、ダッシュボードにもアクセスできるようになった
すべての顧客とユーザーに同時に通知を送ったことで、ログイン試行が急増した
まだログイン問題がある場合は、数分後にもう一度試してほしい
通知ページは引き続き確認してほしい: https://www.mongodb.com/alerts
告知が簡潔で要点を押さえていて良い
まだ初期段階であること、現時点で把握されている範囲、情報が入り次第続報があることを明確に述べている
調査が明らかに初期段階なのに、より多くの情報を載せなかったからといってMongoDBを罰するような反応はしてほしくない
ユーザーデータに触れたかどうかも実質的には確かではないのに、まだ提示していない、あるいは「違う」とだけ言っているように感じるので、回答が必要
MongoDBはいろいろ批判されているが、今回の対応は誠実さ、透明性、信頼という点で一歩引いて認めるべきもの
他社もこうしたやり方に従ってほしいし、こうした原則を実際に示した分、MongoDBと取引する意欲が高まった
regularly rotate their MongoDB Atlas passwordsとあるけど、自分が文脈を見落としているのか?それとも現代的なセキュリティチームが本当にパスワードの定期変更を勧めているのか?
ユーザーのパスワードを定期的に変更するよう強制するのはあまり良くない
影響を受けた場合、システムで異常な挙動をどう監視すべきか分からない
ログを見るだけでは十分ではなさそう
この件は極端な集中化の危険性を示している
Atlasの顧客が直接影響を受けていなくても、告知後にWebサイトやサポートチャネルが圧倒されれば不安になるのは自然
こういう場合に本当の冗長性を持たせるには、独立したMongoDB DBaaSプロバイダーがもっと必要だが、SSPLライセンスへの変更によって大きく制限されている
FerretDBが実現可能な代替をうまく作ってくれることを願う
今日受け取ったセキュリティ通知は、MongoDBが一部の企業システムへの不正アクセスを調査中で、顧客アカウントのメタデータと連絡先情報が露出したという内容だった
現時点では、顧客がMongoDB Atlasに保存したデータが露出した事実は把握していないという
米国東部時間2023年12月13日水曜日の夜に疑わしい活動を検知し、直ちにインシデント対応手順を開始したが、発見前の一定期間アクセスが続いていたと見ているという
顧客にはソーシャルエンジニアリングやフィッシング攻撃に警戒し、まだ実施していない場合はフィッシング耐性のある多要素認証とパスワードのローテーションを推奨し、追加情報はmongodb.com/alertsで更新するとしていた
幸い、実際には MongoDB Atlas は使っていない
「皆さんのデータは安全です。そもそもディスクに書き込んでいませんから」
/dev/nullはWebスケールでスケールするhttps://youtube.com/watch?v=b2F-DItXtZs
MongoDBを使ったことがないのだが、人々が他のデータベースではなくMongoDBを選ぶ理由が何なのか気になる
スキーマに合わせて開発しないので、たとえば機能やデータを素早く変えるときにマイグレーションの心配をあまりしなくてよい
素早く動きたいスタートアップには大きな利点
クエリがアプリケーションコードのように見えるので、アイデアをSQLクエリに翻訳するのに頭を使うことが減り、経験上、壊れにくいクエリにつながる
インジェクション攻撃も、意図的に危険な構造を作らない限りあまり気にする必要が少なく、SQLより複雑なクエリを書きやすいと思う
型変換も
field_name::timestampのようなプラットフォーム固有のインラインSQL関数ではなく、コード側で処理できるクエリと開発方法に単一の基準があり、SQLのように方言ごとに開発することがほとんどない
ほとんどのユースケースでかなりうまく、そして簡単にスケールし、MongoDBは種類が1つなので特定の派生版をめぐる教条的な混乱が起きる余地も少ない
柔軟なスキーマが良いと思うならMongoDBは優れているし、柔軟なスキーマが悪いと思うならいまいち
要するにそれがすべて
JSONドキュメントを保存して扱いやすい
データが木構造のような形なら、大きなドキュメントにもかなり合う
ドキュメント間の関係に依存するならSQLデータベースの方が良いが、多くの場合――実質的には普通のほとんどの場合――SQL的なリレーションは必ずしも必要ではない
MongoDBもリレーションを扱えるが、少し複雑になる
MQLも理解しやすく、MongoDBをある程度楽しく感じさせてくれる
ちなみにMongoDBで働いている
最近なぜ人々がPostgresではなくMongoDBを選び続けるのか気になる
自分が見落としているものがあるなら本気で知りたいし、JSONデータ自体に反対しているわけでもなく、Postgresで jsonbテーブル をよく使っている
「データベースの仕事」と「認証」をやってくれる
この流れに逆らうのは諦めたし、初期段階でMongoDBを使っているのを見ると、開発者たちがまだ補助輪を付けているというサインだとすぐ受け取るようになった