要点
- MongoDB Server に、ログインなしで送れる2件のリクエストが、あとでサーバーを落とす原因になる欠陥（CVE-2026-118383）が見つかった。
- 落ちるのは、仕込まれたサーバーが、遅れた状態のまま新しい親役（プライマリ）に選ばれたときだけである。単独構成のサーバーは対象外だ。
- 修正版は出ている。MongoDB は、悪用の試みは把握していないと説明している。
何が起きたか
MongoDB は 2026年11月10日、重大な欠陥の修正を告知した。深刻度は CVSS 4.0 で 9.5。MongoDB の内部の点検で見つかったという。
翌11日、Datadog Security Labs が技術的な分析を公開した。それによると、原因はメモリの解放後に同じ場所をもう一度使ってしまう誤り（use-after-free）だ。認証が要らない2件のリクエストで、あとから働く「待ち行列の登録」を残せる。
ただし、すぐには落ちない。仕込まれたサーバーが、ほかのメンバーより遅れたまま選挙に勝って新しいプライマリになる必要がある。このとき、追いつくための処理の終わりに、解放済みの場所をまた片づけようとして落ちる。攻撃者は、遅れの大きさも選挙の時機も操れない。
Datadog の実験では、認証を有効にしても、2件のリクエストは止められなかった。8.0.34 では異常終了し、修正版の 8.0.37 では拒否された。Datadog は、任意のコードの実行までは示していない。MongoDB は、条件しだいでコード実行もありうるとしている。
日本の利用者への影響
日本の利用者に限った影響は、分からない。Atlas（MongoDB のクラウド版）は、メンテナンス時に自動で更新される。自分で運用している場合は、自分で更新する必要がある。
今すぐやること
- 自社のMongoDBが、複数台のレプリカ構成か、シャード構成かを確かめる。単独構成は対象外である。
- すべてのメンバーの版を調べる。コンテナ内のものや、メンテナンス中に止まっていたものも忘れない。
- 修正版（下の表）か、それ以降に上げる。Atlas でメンテナンスを延期している場合は、早めに適用する。
- 更新までのあいだ、MongoDB に届く通信を、必要な機器だけに絞る。Datadog は、これは送れる相手を減らすだけで、欠陥は直らないとしている。
- ログに、見覚えのない認証なしの要求や、追いつき処理のあとの異常終了がないか見る。
背景
今回は、悪用の報告がない段階の公表である。落とすには運の要素が要るため、危険度は「注意」とした。ただし、認証で防げないため、外部に開いているサーバーは優先して直したい。
なお、報道では、8.2 系に関して、テスト用の設定で今も欠陥が出たとする GitHub の検証コードがあるとされる。8.2 系は7月31日にサポートが終わっている。この点は、一次情報では確認できていない。
技術者向けの詳細
- 対象: レプリカセットのメンバー（シャード・config サーバーのレプリカセットを含む）。単独の mongod は対象外。
- 原因:
readConcern.afterOpTime付きの未認証コマンド2件で作られた待ち行列が、プライマリの追いつき処理の終了時に二重に片づけられる（Datadog の分析による）。 - 修正版（各系統の最初の修正版、Datadog の表による）:
- 9.0.7 / 8.3.16 / 8.0.37 / 7.0.48 / 6.0.30 / 5.0.35 / 4.4.32
- 確認: 各メンバーの版を上の表と照らす。インターネットに開いたメンバーがないかも探す。
- ログ: 未認証の
readConcern.afterOpTime付き要求、期限切れの待ち、追いつき後の致命的シグナルを探す。設定によっては項目が出ず、attr.remoteがループバックになることもある。 - 詳細な版の範囲は、MongoDB の告知と CVE レコードを見ること。