MongoDB Serverを運用している場合は、レプリカセット構成とサーバーのバージョンを確認してください。 2026年11月10日、MongoDBは認証なしの通信をきっかけにデータベースサーバーが停止し、条件によってはサーバープロセスの権限で任意のコードを実行される恐れがある重大な脆弱性「CVE-2026-118383」を公表しました。CVSS v4.0は9.5（Critical）です。
対象はレプリカセットのメンバーで、シャーディング構成のシャードや設定サーバーも含まれます。単独稼働のmongodは今回のCVEの対象外です。MongoDBは修正版を提供しており、Community Editionの管理者には速やかな更新を勧めています。
2026年11月12日12時台（日本時間）確認。 MongoDBは11月10日の発表時点で実際の悪用を把握していないと説明しています。一方、セキュリティ企業Datadogは脆弱な版でサーバー停止を実験的に再現しました。攻撃が現実に広く行われている、情報漏えいが起きたという事実は確認されていません。
MongoDBの脆弱性で何が起きる？ 影響を受ける人・環境
| 項目 | 確認された内容 |
|---|---|
| CVE番号 | CVE-2026-118383（CWE-416：Use After Free） |
| 深刻度 | CVSS v4.0：9.5／Critical（v3.1：9.0） |
| 攻撃条件 | ログイン不要のリクエストが起点になり得る。ただし、レプリカセットの切り替え処理に関する特定の条件が必要 |
| 想定される被害 | MongoDB Serverの異常終了。条件によってはサーバープロセス権限で任意コード実行 |
| 影響する構成 | レプリカセットの各メンバー、シャーディング構成のシャード・設定サーバーのレプリカセット |
| 対象外の構成 | スタンドアロンで稼働するmongod |
| 公表・修正 | MongoDBが2026年11月10日に公表、同日付の各系列の修正版で対応 |
今回のニュースは、MongoDBを利用した全てのWebサービスで情報漏えいが起きたという意味ではありません。一般利用者が端末の設定を変更する問題でもなく、MongoDB Serverを管理する担当者や、管理を委託している事業者が対応すべき問題です。MongoDB Compassなどの管理用クライアントをインストールしているだけで、このサーバーの脆弱性の影響を受けるとは限りません。
影響バージョン一覧：どのMongoDB Serverを更新すべき？
MongoDB公式のセキュリティ情報に掲載された影響範囲と、各系列で最初に修正されたバージョンをまとめました。修正版以上のパッチリリースがある場合は、サポート状況と互換性を確認して更新先を選んでください。
| MongoDB系列 | 影響を受けるバージョン | 最初の修正版 |
|---|---|---|
| 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 |
上表は今回のCVEについてMongoDBが公表した範囲です。表にない別の系列については、対象外と推測せず、メーカーのアラートと利用製品のサポート資料を確認してください。古い系列は今回の修正の有無だけでなく、製品自体のサポート期限も確認が必要です。
MongoDBのバージョン・レプリカセット構成を確認する方法
1．実行中のMongoDB Serverのバージョンを調べる
権限を持つ管理者がmongoshで対象サーバーに接続し、次のコマンドを実行します。
db.version()接続先のmongodまたはmongosのバージョンが表示されます。ルーターmongos経由で接続している場合、その結果だけで裏側の全シャードやレプリカセットメンバーが更新済みとは判断できません。各メンバーの実行バージョンを確認してください。コンテナー・仮想マシンで運用している場合は、イメージのタグだけでなく、実際に起動中のプロセスの版も確認します。
2．レプリカセット構成かを確認する
レプリカセットのメンバーに管理者権限で接続して、次のコマンドで状態を確認できます。
rs.status()メンバーの状態（PRIMARY／SECONDARYなど）や構成を把握できます。rs.status()はレプリカセットのメンバー向けのコマンドで、スタンドアロン環境では通常成功しません。ただし、コマンドが失敗したという事実だけで安全と断定しないでください。権限不足や接続先の違いなどでも失敗します。Atlasの一部プランでは利用できないため、管理画面から構成を確認します。
なぜ認証を有効にしていても危険なのか：仕組みを解説
今回の不具合は、MongoDBのレプリケーション（複数のDBサーバー間でデータを複製する仕組み）にあります。レプリカセットでは、書き込みを担当するPRIMARYが使えなくなると、別のメンバーを新しいPRIMARYとして選出することがあります。その際、引き継ぎ側では遅れている処理を追いつかせる「catch-up」が行われます。
脆弱なバージョンでは、このcatch-upの終了処理にUse After Free（解放済みメモリへのアクセス）が起き得ます。不要になったメモリを解放したあと、誤って再び参照してしまう不具合で、サーバー停止の原因になり、条件によってはコード実行に発展する可能性があります。
重要なのは、ログイン前に受け付ける通信が引き金になり得ることです。Datadog Security LabsはMongoDB 8.0.34の検証環境で認証を用いない通信を起点に、後のPRIMARY切り替え時にmongodがSIGSEGVで異常終了することを確認しました。修正版8.0.37では同じ検証で異常終了しませんでした。Datadogは任意コード実行までは確認していません。
このため、security.authorization: enabledのような認証設定を行っていても、今回の欠陥そのものは解消しません。また、脆弱性は選出・catch-upに関わる特定の状況で発生するため、接続できれば常に即座に乗っ取れるという説明も正確ではありません。
今すぐ実施したい対策：更新までに管理者が行うこと
最優先：対象メンバーを修正版へ更新する
- インベントリの作成：Community／Enterprise／Atlas、バージョン、レプリカセット・シャード・設定サーバーの構成と公開範囲を確認する
- バックアップと切り戻し計画：更新前の正常なバックアップ、復元手順、監視設定を確認し、可能なら検証環境で更新を試す
- ローリング更新：自己管理のレプリカセットは原則SECONDARYを1台ずつ更新し、同期回復を確かめてから次へ進み、最後にPRIMARYを更新する。シャーディング構成は公式の手順を参照する
- 全ノード確認：コンテナー、停止していたノード、後から再起動するノードを含め、全メンバーの実行版を確認する
- Atlasの保守確認：Atlasはメンテナンスで自動適用されるが、延期している場合は早期適用を検討し、反映完了を確認する
MongoDB公式のパッチリリース更新手順には、稼働中のメンバーを確認しながら順次更新する方法が記載されています。メジャーバージョンをまたぐ更新は手順が異なるため、パッチ更新と同じ手順で一足飛びにアップグレードしないでください。
更新までの暫定対策：ネットワークからの到達範囲を狭める
- MongoDBの待受ポート（一般的にはTCP 27017）をインターネットへ不必要に公開していないか、ファイアウォール・セキュリティグループ・ロードバランサーで確認する
- 接続をアプリケーションサーバー、監視サーバー、管理用端末、必要なレプリカセットメンバーなどに限定する。運用に必要な相互通信を遮断しないよう事前に通信要件を確認する
net.bindIpやOSのファイアウォール、クラウド側のアクセス制御を点検する。認証・TLS設定も維持するが、今回の脆弱性の根本対策は更新である
ネットワーク制限で攻撃できる相手を減らせますが、内部ネットワークからのアクセスや許可済みサーバーの侵害などのリスクは残ります。ポートを閉じたのでパッチ不要、とは判断しないでください。
障害や悪用を疑う場合のログ確認
MongoDBログの不審な異常終了、SIGSEGV、PRIMARY切り替え、catch-up前後のエラー、予期しない接続元などを時系列で確認します。Datadogの実験ではcatch-up終了直後のメモリエラーが観測されました。ただし、似たログがあるだけで脆弱性攻撃と断定することはできません。監視データ、OSログ、通信履歴と突き合わせ、必要ならベンダーやインシデント対応担当へ相談します。
MongoDB Atlasを使っている場合はどうする？
MongoDBは、Atlasのクラスターについて修正版をクラスターのメンテナンス時に自動適用するとしています。一方、メンテナンスを延期している場合は速やかな適用を推奨しています。Atlasの管理画面で対象クラスターのバージョンと保守予定・適用履歴を確認してください。Atlasを使っていれば何もしなくてよい、と一律には言えません。
よくある質問（FAQ）
Q．MongoDBにログインパスワードを設定していれば安全ですか？
いいえ。今回の脆弱性は認証を必要としない通信を起点に発生し得るため、パスワード設定だけでは防止できません。更新とネットワークアクセス制限が必要です。
Q．MongoDBの単独サーバーでも影響しますか？
MongoDB公式情報では、スタンドアロンのmongodはCVE-2026-118383の対象外です。ただし、別の脆弱性への対応や通常のセキュリティ更新は引き続き必要です。
Q．もう情報が盗まれたり、サーバーが乗っ取られたりしていますか？
MongoDBは11月10日の公表時点で悪用を把握していないとしています。Datadogが再現したのは検証環境での異常終了で、任意コード実行ではありません。個別環境の侵害有無はこの情報だけでは判定できません。
Q．更新後に確認すべきことは？
全メンバーのバージョン、PRIMARY／SECONDARYの状態、複製遅延、アプリケーションの読み書き、監視アラート、バックアップの成功状況を確認します。部分更新のままのノードや、古いコンテナーイメージからの再起動がないかも点検してください。
まとめ：まず構成を確認し、対象ノードは修正版に更新を
CVE-2026-118383は、MongoDBのレプリカセットに影響する認証不要・CVSS 9.5の重大なメモリ処理の脆弱性です。DB停止と、条件による任意コード実行の可能性が示されています。管理者は「レプリカセットか」「影響バージョンか」「外部から到達可能か」を確認し、アクセス制限を暫定対策として実施しながら、全メンバーへ修正版を適用してください。
出典・更新履歴
- MongoDB公式：Important MongoDB security update（2026年11月10日）
- MongoDB公式：Security Alerts（CVE-2026-118383）
- MongoDB公式：9.0系リリースノート
- MongoDB公式：パッチリリース更新手順
- MongoDB公式：IPバインドとネットワーク制限
- MongoDB公式：replSetGetStatus／rs.status()
- MongoDB公式：Atlasメンテナンス管理
- Datadog Security Labs：CVE-2026-118383の検証（2026年11月11日）
初版：2026年11月12日／公式資料・技術検証の確認：2026年11月12日12時台（日本時間）。今後、悪用状況やメーカーの対策情報に変更があれば追記します。
