MongoDBのレプリカセットに認証不要RCEの脆弱性｜設定サーバーも含めて更新を

MongoDBは2026年11月10日、MongoDB Serverのレプリケーション処理に関する重大な脆弱性CVE-2026-118383への更新を案内しました。レプリカセットを運用する担当者は各メンバーの版を確認し、系列ごとの修正版へ更新してください。認証を必要としない要求によって予期しない終了や、条件次第でサーバープロセスの権限による任意コード実行につながるおそれがあります。

対象にはシャードと設定サーバーのレプリカセットも含まれます。一方、単独で動くstandalone mongodはこのCVEの対象ではありません。MongoDBの公式案内はCommunity Editionの利用者に早急な更新を推奨し、Atlasではメンテナンス時に自動更新するものの、延期中なら早く適用するよう求めています。

プライマリのキャッチアップ完了時に起きる問題

公式CVEレコードは、新たに選出されたプライマリがキャッチアップを完了する際、レプリケーション部品で解放済みメモリーの使用（Use After Free）が生じ得ると説明しています。単なる重い検索やアプリ側のSQL入力を修正する問題ではなく、DBサーバー自身の更新が必要です。

評価はCriticalで、CVSS 4.0基本値9.5、CVSS 3.1基本値9.0です。本記事と構造化メタでは4.0の9.5を使用します。ネットワーク経由、権限不要、利用者操作不要である一方、攻撃複雑性はHighです。「認証不要」を「どの接続からも必ずコードが実行される」と読み替えず、構成と到達範囲を確認してください。

提供元は内部のセキュリティ活動で発見・修正し、公式案内の時点で悪用を試みた事例を把握していないとしています。これは悪用が起きない保証でも、自社に侵害がない証明でもありません。本稿は11月12日に一次資料を確認した更新・対応解説で、実環境の攻撃を再現したものではありません。

シャードと設定サーバーも対象台帳へ

確認の単位は、アプリが接続する一つのホスト名では足りません。レプリカセットの全メンバーを特定し、シャードクラスタでは各シャードと設定サーバーの構成を確認します。ルーターであるmongosの表示だけを見て、配下のmongodも同じ版と判断しないようにします。

公式CVEレコードはレプリカセットのメンバーが対象と明示しています。そのため、現在セカンダリとして動いているノードも更新計画に含めます。現在の役割がプライマリではないという理由で、修正を省略する判断にはつながりません。

本サイトの提案として、クラスタ名、導入形態、系列、稼働版、レプリカセット名、各メンバーの役割、更新担当者を整理します。データベースを保守会社へ委託している場合も「MongoDB更新済みですか」だけでなく、全メンバーの版と反映結果を確認できる回答を求めるとよいでしょう。

系列ごとの修正境界を確認する

公式CVEレコードと修正チケットが示す最初の修正版は次のとおりです。表は各系列の修正境界であり、あらゆる環境で最も古い修正版を選ぶ推奨ではありません。配布されている最新パッチと、その系列のリリースノートも照合してください。

系列	影響する版	最初の修正版
9.0	9.0.0～9.0.6	9.0.7
8.3	8.3.0～8.3.15	8.3.16
8.0	8.0.0～8.0.36	8.0.37
7.0	7.0.0～7.0.47	7.0.48
6.0	6.0.0～6.0.29	6.0.30
5.0	5.0.0～5.0.34	5.0.35
4.4	4.4.0～4.4.31	4.4.32

SERVER-138175はキャッチアップ処理の再入に関するUse After Freeの修正を示し、SERVER-138119も同じ系列の修正版を列挙しています。CVE番号だけでなく開発元の修正先を追うことで、利用系列の配布物に対応する修正が含まれるかを確認できます。

古い系列に今回の修正があることを、その系列が今後も通常のサポートを受けられる保証と混同しないでください。まず本件への更新を進め、長期的な系列移行は互換性やサポート条件を別途確認します。緊急修正とメジャー更新を一つにまとめ、検証が終わるまで何も反映しない状態を避けることが実務上の判断になります。

Atlasはメンテナンスの延期状態を確認

Atlasを利用する場合、公式案内はクラスタメンテナンスの際に修正版へ自動更新されると説明しています。利用者が延期している場合は、できるだけ早く更新を適用することを強く推奨しています。マネージドサービスだから確認が不要という意味ではありません。

本サイトの提案は、担当アカウントから対象クラスタの保守予定と適用結果を確認し、延期中の作業がないかを調べることです。契約・クラスタ固有の通知を本稿から推測することはできません。実際の案内と稼働版を確認し、保守予定を見ただけで反映済みと記録しないようにします。

自己管理環境では更新前に構成を検証

公式のパッチ更新手順は、最新のバックアップ、リリースノートとドライバーの互換性、保守時間、本番を再現した検証環境での確認を挙げています。参照したページは9.0系列向けなので、別系列では対応する版のマニュアルを使ってください。

公式手順は、バイナリー更新の前にfeatureCompatibilityVersion（FCV）の更新が全関連部品で完了しているかを確認します。過去のFCV変更が完了していないと、新しいバイナリーの再起動でノードがクラッシュする場合があるためです。これは今回の脆弱性そのものとは別の、更新作業を成立させる前提確認です。

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

このコマンドは値の取得です。9.0向け資料に示された期待値を、7.0や8.0の環境へそのまま当てはめてFCVを変更する手順ではありません。利用系列の手順と現在の移行状態を照合し、全メンバーの結果を確認してから作業に進みます。

レプリカセットは一台ずつ反映する

9.0向け公式手順では、セカンダリから一台ずつ更新し、各ノードがSECONDARYへ戻ったことを確認してから次へ進みます。一時的にSTARTUP2やRECOVERINGになる場合もあるため、単にプロセスが起動しただけで次のノードを止めないようにします。状態はmongoshのrs.status()で確認できます。

プライマリは最後にステップダウンし、別メンバーがPRIMARYになったことを確認してから、元のプライマリを停止・更新します。フェイルオーバー中は書き込みを受け付けられないため、アプリ側の再接続や再試行を含めて保守時間を計画します。本記事の説明を、全系列や全構成に共通する作業コマンドとして使わないでください。

本サイトの提案として、各段階でメンバーの状態、更新した版、レプリケーションの回復、アプリの読み書きを記録します。途中で回復が確認できなければ次のノードへ進まず、更新ログと状態を保全して原因を調べます。作業を早く終えるために複数台をまとめて停止することは、段階更新の前提を崩します。

シャードクラスタは設定サーバーから順序を確認

9.0向け公式手順は、バランサーを停止し、設定サーバー、各シャード、mongosの順で更新した後にバランサーを再開する流れを示しています。レプリカセットである設定サーバーとシャードは、前述の段階更新を適用します。今回は設定サーバーも影響範囲なので、アプリのデータを持つシャードだけで対応済みとしない点が重要です。

作業前にバランサーの元の状態と運用担当者を記録し、更新後の復帰を確認してください。これは本サイトが提案する作業管理です。サービス全体の正常性は、個別プロセスの起動に加え、クラスタ状態とアプリの通常処理を対応づけて確認します。

認証設定だけで修正を置き換えない

本件は認証を必要としない要求が条件を引き起こせる問題です。認証を有効にしているという事実だけで、対象のレプリカセットを更新対象から外すことはできません。本サイトは、DBへの到達元を必要なアプリや運用経路に絞り、公開範囲を確認することも提案しますが、これは露出を減らす補助策であり、開発元が示す修正版への更新の代わりではありません。

また、脆弱性の説明にプライマリ選出が含まれることを理由に、冗長化や選出の動作を独自に無効化する回避策を作らないでください。公式資料で安全性を確認していない設定変更は、可用性や復旧性を損なうおそれがあります。今回の対応は、構成の把握と修正版の配備を中心に進めます。

完了は全メンバーの稼働版と動作で判断

パッケージ取得やコンテナイメージの更新だけでは、稼働中のサーバーが修正版へ切り替わったとは限りません。本サイトの提案として、再起動後の各メンバーの版、役割、同期状態、通常の読み書き、監視の結果を一組で残します。ローリング更新の途中で旧版が残っている状態と、全台の反映完了を明確に分けてください。

予期しない終了があった場合も、それだけで本件の悪用と断定はできません。時刻、稼働版、選出や同期の状況、関連ログを保存し、提供元や担当部門へ相談します。更新は将来の脆弱な処理を修正するもので、過去の侵害がなかったことを証明する手続きではありません。

対応記録には確認日と参照した告知の版も残し、後日の修正案内と照合できるようにします。今回の判断で押さえるのは、standaloneとレプリカセットの区別、シャード・設定サーバーを含む全メンバー、自己管理とAtlasで異なる更新担当、系列ごとの修正境界です。利用している接続先一つだけを確認して終わらせず、実際のDB構成と配備結果に基づいて対応を閉じてください。