MongoDBに重大な脆弱性。レプリカセットの更新とAtlasの適用状況を確認

MongoDBを業務システムのデータベースに使っている場合、まず構成と修正状況を確認してください。MongoDBは2026年11月10日、重大な脆弱性CVE-2026-118383の修正版を案内し、Community Editionの利用者に速やかな更新を求めました。

対象になるのは、データを複製して運用する「レプリカセット」のメンバーです。単独で動くmongodは対象外です。クラウドサービスのAtlasを使う場合も、更新が終わっているかを確認する必要があります。

何が起きる可能性があるのか

問題は、レプリカセットで新しく主系になったサーバーが、他のメンバーにデータを追いつかせる処理にあります。すでに解放したメモリーを再び使ってしまう不具合で、サーバープロセスの異常終了や、条件によっては任意のコード実行につながる可能性があります。

MongoDBの発表では、CVSSスコアは9.5で、社内の取り組みで発見したと説明しています。発表時点で、同社は悪用の試みを認識していないとしています。

一方、Datadogの11月11日の検証では、認証していないクライアントからの要求をきっかけに、条件を整えた検証環境で異常終了を再現しています。認証を有効にするだけでは防げません。ただし、同社が実証したのはクラッシュであり、コード実行の成功ではありません。

レプリカセットは、障害時にもサービスを続けられるようにデータを複製する仕組みです。今回の対象には、通常のレプリカセットに加え、シャーディング構成で使うシャードや設定サーバーのレプリカセットも含まれます。

MongoDBのレプリカセットで新しい主系がデータに追いつく処理が対象で、単独mongodは対象外。自社管理とAtlasで対応を分ける図

確認するときは、次の点を区別してください。

攻撃に必要な条件には、主系の切り替えやデータの遅れも関係します。「外部から要求を送れば、いつでも直ちにコードが動く」といった単純な問題ではありません。それでも、業務停止につながり得るため、構成確認と更新を優先する理由があります。

MongoDBの修正チケットで確認できる、各系列で最初に修正を含む正式版は次のとおりです。

この表は「現在の最新版」の一覧ではありません。利用系列のサポート状況も含め、修正が入った適切なリリースや配布パッケージを選んでください。

更新は、現在の主系一台だけでなく、対象となるすべてのメンバーで確認します。停止中のサーバーや古いコンテナを後から戻す場合も、修正が取りこぼされていないか点検が必要です。バックアップ、更新手順、切り戻し方法、業務への影響を運用担当者と確認して進めます。

MongoDBは、Atlasのクラスターはメンテナンスで修正版へ自動更新されると説明しています。メンテナンスを延期している利用者には、できるだけ早く適用するよう強く勧めています。

そのため確認したいのは、「Atlasだから何もしなくてよいか」ではなく、自社のクラスターで修正の適用が完了しているか、延期した予定が残っていないかです。管理画面で判断できない場合は、サポート窓口にクラスターと修正状況を確認します。

MongoDBへ通信できる相手を必要なシステムに絞ることは、外部から不審な要求が届く範囲を減らす対策になります。ただし、通信制限は不具合そのものを修正するものではありません。

運用担当者には、データベースをインターネットへ不要に公開していないかに加え、異常終了や不審な要求の記録がないかを確認してもらいます。原因不明の停止があった場合、再起動して動いたという理由だけで終わらせず、切り替え前後の記録を保全して調べるとよいでしょう。

新たな検証結果が公開されたことと、実際の被害が確認されたことは別です。この記事では、個別企業で侵害が起きたかや、すべての構成でどの程度攻撃が成功するかまでは確認できていません。

確認日：2026年11月12日。修正版とAtlasの対応状況は、公式情報と自社環境で確認してください。