---
title: "MongoDB脆弱性CVE-2026-118383：レプリカセットの対象判定と修正版への更新手順"
url: "https://www.issoh.co.jp/tech/details/19673/"
published: 2026-11-12
updated: 2026-11-12
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# MongoDB脆弱性CVE-2026-118383：レプリカセットの対象判定と修正版への更新手順

MongoDBは2026年11月10日、レプリカセットの新しいプライマリがキャッチアップを終える瞬間に起きる解放後使用（use-after-free）の脆弱性CVE-2026-118383を公表しました。CVSS 4.0の基本値は9.5で、認証を必要としないリクエストで誘発でき、条件次第ではサーバープロセスの権限で任意のコードが動きます。この記事では、公表された事実と系列別の修正版、自分のMongoDBが対象かをmongoshで判定するスクリプト、レプリカセットを止めずに修正版へ上げる手順を、2026年11月12日時点の一次情報に沿って整理します。

## まとめ：レプリカセット構成なら修正版8.0.37・7.0.48以上へ今週中に上げる

対象はレプリカセットのメンバーで、シャードクラスタのシャードとconfig serverも含みます。単体で動かしているmongodは対象外です。修正版は9.0.7・8.3.16・8.0.37・7.0.48・6.0.30・5.0.35・4.4.32で、いずれも10月30日に公開済みでした。11月12日時点の最新は9.0.8・8.3.17・8.0.38なので、これから上げるなら最新版を選びます。

Community Editionなどの自前運用は、セカンダリから1台ずつ入れ替えるローリング更新で、書き込み停止をフェイルオーバーの10〜20秒に抑えられます。MongoDB Atlasはメンテナンス時に自動で更新されますが、メンテナンスを延期している場合は今すぐ適用してください。公開範囲の洗い出しから任せたい場合は、一創の[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で、DBが外部から届く経路を含めて確認できます。

## CVE-2026-118383の公表内容：CVSS 9.5・認証不要・対象はレプリカセット

### 2026年11月10日のMongoDB告知とNVD登録までの時系列と発見経緯

告知はMongoDB社員がコミュニティフォーラムに投稿した「[Important MongoDB security update available (Action Required)](https://www.mongodb.com/community/forums/t/important-mongodb-security-update-available-action-required-november-10-2026/344843)」です。社内のセキュリティプログラムで見つけたもので、悪用の試みは把握していないと説明しています。他社で相次いだ脆弱性とは別件だとも明記されました。

記録の時刻はUTCで、Jiraの修正チケット解決が19時19分、[NVDのCVE登録](https://nvd.nist.gov/vuln/detail/CVE-2026-118383)が21時18分、フォーラム告知が23時20分です。日本時間では11月11日の朝にあたります。修正を含むパッチ版は告知より11日早い10月30日に出ていました。10月30日以降のパッチを入れていた環境は、告知の時点で既に塞がっていたことになります。NVDの判定状態は11月12日時点で「Awaiting Analysis」で、NVD自身のスコアはまだ付いていません。

### 系列別の影響範囲と修正版・11月12日時点の最新版を確認する対応表

[MongoDBのAlertsページ](https://www.mongodb.com/resources/products/alerts)とNVDの影響範囲は一致しており、7系列すべてに修正版があります。最新版の列は、公式の全リリース一覧（downloads.mongodb.org）で11月12日に確かめた値です。

| 系列   | 影響を受ける範囲     | 修正版（10月30日公開） | 11月12日時点の最新   |
| ---- | ------------ | ------------- | ------------- |
| 9.0系 | 9.0.0〜9.0.6  | 9.0.7         | 9.0.8（11月5日）  |
| 8.3系 | 8.3.0〜8.3.15 | 8.3.16        | 8.3.17（11月5日） |
| 8.0系 | 8.0.0〜8.0.36 | 8.0.37        | 8.0.38（11月5日） |
| 7.0系 | 7.0.0〜7.0.47 | 7.0.48        | 7.0.48        |
| 6.0系 | 6.0.0〜6.0.29 | 6.0.30        | 6.0.30        |
| 5.0系 | 5.0.0〜5.0.34 | 5.0.35        | 5.0.35        |
| 4.4系 | 4.4.0〜4.4.31 | 4.4.32        | 4.4.32        |

8.2系や4.2系以前は、告知の一覧に載っていません。修正版も示されていないため、対象外と読むのではなく、一覧にある系列へ移る前提で扱います。同じ11月10日付でAlertsには別のCVEが3件掲載されているので、更新作業はまとめて済ませると手戻りがありません。

### CVSS 4.0の9.5とAC:Hが示す「認証不要だが条件付き」の意味

CNAであるMongoDBが付けたベクトルは、ネットワーク経由（AV:N）・権限不要（PR:N）・利用者の操作不要（UI:N）で、機密性・完全性・可用性がすべて高（H）です。CVSS 3.1でも9.0で、影響が他の構成要素へ及ぶS:Cが付いています。弱点の分類はCWE-416（解放済みメモリの使用）です。

唯一の緩和要素が攻撃の複雑さAC:H（高）です。新プライマリがキャッチアップを終える瞬間という、攻撃者が自由に起こせないタイミングに依存するためです。ただし選出は、保守作業・ノード障害・ネットワークの揺れで日常的に起きます。複雑さが高いことは、更新を延ばす理由にはなりません。

## 新プライマリのキャッチアップ処理で起きる解放後使用の発生の仕組み

### 選出直後のcatch-up期間とcatchUpTimeoutMillisの既定値-1

レプリカセットで新しいプライマリが選ばれると、自分より新しい書き込みを持つメンバーへ追いつく「キャッチアップ期間」に入ります。[レプリカセット設定のドキュメント](https://www.mongodb.com/docs/manual/reference/replica-configuration/)によると、この期間中はクライアントからの書き込みを受け付けず、追いついた時点で前倒しで終わります。上限を決める `settings.catchUpTimeoutMillis` の既定値は-1（無制限）です。

CVE-2026-118383は、このキャッチアップが完了する処理の中で、既に解放したメモリを参照してしまう欠陥です。キャッチアップを0で無効にする設定もありますが、ロールバック量が増える副作用があり、修正版への更新の代わりにはなりません。

### 修正チケットSERVER-138175とSERVER-138119が示す修正の範囲

CVEに参照として登録されたチケットは2件です。[SERVER-138175](https://jira.mongodb.org/browse/SERVER-138175)の件名は「CatchupState::abort() の再入による解放後使用を修正」で、欠陥そのものの修正にあたります。[SERVER-138119](https://jira.mongodb.org/browse/SERVER-138119)の件名は「readConcernのafterOpTimeをシステムユーザーだけに許可する」です。

afterOpTimeはレプリケーションの内部で使われる指定で、アプリケーションのドライバーが通常の読み取りで付けるものではありません。両チケットとも修正版は9.0.7・8.3.16・8.0.37・7.0.48・6.0.30・5.0.35・4.4.32で、内部向けの指定を外部の要求から使えないように絞る変更が同時に入ったと読めます。チケット本文は非公開で、攻撃手順は公表されていません。

### 単体のmongodが対象外でシャードとconfig serverが対象になる理由

欠陥はレプリケーション部品の選出とキャッチアップにあるため、選出が起きない単体のmongodには及びません。シャードクラスタでは、各シャードとconfig serverがそれぞれレプリカセットとして動くので、すべて対象に入ります。

注意したいのは、開発用に1台だけでレプリカセットを組んでいる構成です。トランザクションや変更ストリームを使うために `rs.initiate()` した1台構成は、単体に見えてもレプリカセットのメンバーです。判定は台数ではなく、次の章のスクリプトで `setName` の有無を見て行います。

## 自環境が対象かをmongoshで判定する手順と判定スクリプト

### db.version()とhelloで版と構成を同時に取る判定スクリプト

各メンバーにmongoshで接続し、次のスクリプトを貼り付けます。`db.version()` で稼働中の版を、[helloコマンド](https://www.mongodb.com/docs/manual/reference/command/hello/)でレプリカセット名（`setName`）とmongosかどうか（`msg: "isdbgrid"`）を取り、修正版の表と突き合わせます。

```
// CVE-2026-118383 の対象判定（mongosh で各メンバーに接続して実行）
const FIXED = { "9.0": 7, "8.3": 16, "8.0": 37, "7.0": 48, "6.0": 30, "5.0": 35, "4.4": 32 };
const v = db.version();
const h = db.hello();
const [maj, min, patch] = v.split(".").map(Number);
const series = maj + "." + min;
let role = "standalone";
if (h.msg === "isdbgrid") role = "mongos";
else if (h.setName) role = "replica set member (" + h.setName + ")";
let verdict;
if (role === "standalone") verdict = "対象外：単体のmongod";
else if (role === "mongos") verdict = "要確認：配下のシャードとconfig serverに個別に接続して判定";
else if (!(series in FIXED)) verdict = "要確認：告知に修正版が無い系列 " + series;
else if (patch < FIXED[series]) verdict = "対象：" + series + "." + FIXED[series] + " 以上へ更新";
else verdict = "修正済み";
print(v + " | " + role + " | " + verdict);
```

たとえば8.0.34で動くレプリカセットのメンバーなら「対象：8.0.37 以上へ更新」と表示されます。`db.version()` は接続先プロセスの版を返すため、パッケージを入れ替えても再起動していないノードの表示は、古い版のままです。インストール済みの版と稼働中の版がずれていないかも、ここで分かります。

### シャードクラスタでmongos経由では判定できない部分の回り方

アプリケーションが普段つなぐのはmongosですが、mongosで上のスクリプトを流しても分かるのはmongos自身の版だけです。NVDの記述が対象として挙げるのはレプリカセットのメンバーで、mongosは含まれていません。

シャードの接続先は、mongos上で `sh.status()` を実行すると各シャードのレプリカセット名とホストが一覧で出ます。config serverのホストは `db.adminCommand({ getShardMap: 1 })` の結果で確かめられます。それぞれのプライマリとセカンダリへ直接つないで判定を回してください。

### Dockerイメージのタグとパッケージ固定で版が止まった環境の洗い出し

コンテナで動かしている場合、`mongo:8.0` のような系列タグなら再pullで最新に追従しますが、`mongo:8.0.34` のようにパッチ版まで固定したタグは自動では上がりません。[Docker Hubの公式イメージ](https://hub.docker.com/%5F/mongo)には11月12日時点で `9.0.8`・`8.3.17`・`8.0.38`・`7.0.48` のタグがあります。

```
services:
  mongo:
    image: mongo:8.0.38
    command: ["--replSet", "rs0", "--bind_ip", "127.0.0.1,mongo"]
```

パッケージ導入の環境では、aptの `apt-mark hold` やyumのversionlockで版を止めていないかを確かめます。CI用のdocker composeやテスト用のTestcontainersで古いタグが残っていても本番の危険には直結しませんが、本番と同じ版で試験する前提が崩れるので、合わせて上げておきます。

## レプリカセットを止めずに修正版へ上げるローリング更新の実施手順

### セカンダリから1台ずつ更新しSECONDARY復帰を待つ順番と確認方法

手順は公式の「[Upgrade to the Latest Self-Managed Patch Release of MongoDB](https://www.mongodb.com/docs/manual/tutorial/upgrade-revision/)」に沿います。同じ系列内のパッチ更新なので、データ形式の移行はありません。

1. 最新のバックアップがあることと、全メンバーが起動していることを確かめる
2. `db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })` で、FCVが現在の系列と一致していることを確かめる
3. セカンダリを1台選び、mongodを止めてバイナリを修正版に入れ替え、起動する
4. `rs.status()` でそのメンバーが `SECONDARY` に戻るまで待ち、次のセカンダリへ進む
5. 全セカンダリが終わったら、最後にプライマリを降格させて入れ替える

入れ替え直後のセカンダリは一時的に `STARTUP2` や `RECOVERING` になりますが、公式手順はこれを正常としています。SECONDARYに戻る前に次の1台を止めると過半数を失い、プライマリが選べなくなるので、待つ工程は省きません。

### rs.stepDown()で旧プライマリを降ろすときの書き込み停止10〜20秒

プライマリは直接止めずに、[rs.stepDown()](https://www.mongodb.com/docs/manual/reference/method/rs.stepdown/)で降格させてから入れ替えます。公式手順は、降格のほうがフェイルオーバーが早く、書き込みを受け付けない時間は通常10〜20秒だとしています。

```
// 旧プライマリで実行：60秒間は再選出されないように降格させる
rs.stepDown(60)

// 別のメンバーがPRIMARYになったことを確かめる
rs.status().members.map(m => m.name + " " + m.stateStr)
```

このフェイルオーバーで新しいプライマリが選ばれ、まさに今回の欠陥があるキャッチアップ処理が走ります。セカンダリを先に修正版へ上げておくと、選ばれる側は修正済みになります。順番を守ることが、そのまま防御になる構図です。アプリ側は、ドライバーの[再試行可能書き込み（retryWrites）](https://www.mongodb.com/docs/manual/core/retryable-writes/)が有効なら、降格で失敗した書き込みが1回だけ自動で再送されます。

### MongoDB Atlasの自動更新とメンテナンス延期中の早期適用

Atlasのクラスタは、メンテナンスの際に修正版へ自動で上がります。告知では、メンテナンスを延期している場合に強く勧める対応は、早期の適用です。延期は1回につき1週間で、自動延期の設定を入れていると実質2週間ごとの実施になります。[Begin or Defer Scheduled Maintenance](https://www.mongodb.com/docs/atlas/tutorial/respond-to-required-maintenance/)の手順で、予定されたメンテナンスを今すぐ開始できます。

クラスタ階層やネットワーク設定を含むAtlasの全体像は[MongoDB Atlasとは？クラスタ階層・料金・セキュリティ設定と採用判断](https://www.issoh.co.jp/tech/details/16446/)にまとめています。Atlasでも、同じアプリが自前のレプリカセットを開発環境で使っているなら、そちらは手動更新の対象です。

## 更新できない期間の暫定策と、対応を後回しにしてよい場面の線引き

### bindIpとネットワーク制限で認証前の要求が届く範囲を絞る手順

認証の前に誘発できる欠陥なので、ユーザー認証やロール設計は防御になりません。効くのは、mongodの待ち受けに届く送信元そのものを減らすことです。[IP Bindingのドキュメント](https://www.mongodb.com/docs/manual/core/security-mongodb-configuration/)のとおり、`net.bindIp` にはアプリサーバーと他メンバーが届くアドレスだけを書き、`0.0.0.0` での待ち受けをやめます。

クラウドではセキュリティグループやファイアウォールで27017番への送信元を、アプリサーバーとレプリカセットのメンバーに限定します。API側の入口対策は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)で扱っています。ただし、アプリサーバーが乗っ取られれば内側から届くので、暫定策は更新までのつなぎです。

### 単体構成や閉域の開発環境だけを更新の後回しにしてよい条件と例外

後回しにしてよいのは、次の2つを両方満たす環境だけです。ひとつは `setName` が無い単体のmongodであること。もうひとつは、本番データを持たず、開発者の端末やCIの中だけで動くことです。

反対に、「社内ネットワークだけだから」という理由で本番や検証のレプリカセットを後回しにするのは見送れません。社内の端末1台が侵害されれば認証前の要求は届きますし、成立すればサーバープロセスの権限でコードが動きます。DB層の更新を含めた優先度の付け方は[パッチ管理とは：KEVで優先度を決めて自動適用する手順](https://www.issoh.co.jp/tech/details/19309/)も参考になります。

### MongoBleed対応で8.0.34に上げた環境が再び更新対象になる理由

2025年12月のMongoBleed（CVE-2025-14847）では、zlib圧縮の処理から未初期化のメモリが読み出せました。そのときに8.0.34や7.0.45へ上げて止めた環境は、今回の修正版より古いため、もう一度対象になります。MongoBleedの仕組みと痕跡の調べ方は[MongoDBの脆弱性CVE-2025-14847（MongoBleed）とは？](https://www.issoh.co.jp/tech/details/10540/)で解説しています。

1年足らずの間に、認証前に届くCriticalな欠陥が2件続きました。脆弱性が出るたびに対応するのではなく、四半期ごとなど決まった周期でパッチ版を追従する運用に切り替えると、次の告知の日に慌てずに済みます。

## MongoDBの脆弱性CVE-2026-118383でよくある質問と回答

CVE-2026-118383の対応で迷いやすい点を、11月12日時点の公表内容をもとに答えます。

### MongoDB Atlasを使っている場合も自分で更新する必要はありますか？

Atlasのクラスタは、メンテナンスの際にMongoDBが修正版へ自動で上げるため、自分でバイナリを入れ替える必要はありません。ただし、メンテナンスを延期している場合は、Atlasの画面から予定済みのメンテナンスを今すぐ開始する操作が勧められています。同じシステムでも、開発環境やオンプレミスの検証環境で自前のレプリカセットを動かしているなら、そちらは手動で更新します。

### 単体構成（スタンドアロン）のMongoDBなら更新しなくてよいですか？

NVDの記述では、単体のmongodは対象外です。ただし、トランザクションや変更ストリームのために1台だけでレプリカセットを組んでいる場合は、レプリカセットのメンバーなので対象に入ります。見分けるにはmongoshで `db.hello().setName` を確かめ、値が返ればレプリカセットです。対象外の単体構成でも、次の更新周期で最新のパッチ版へ上げておくと、別の脆弱性への備えになります。

### CVE-2026-118383は実際に悪用されていますか？

MongoDBは告知の中で、社内のセキュリティプログラムで見つけたもので、悪用の試みは把握していないと説明しています。攻撃手順や検証コードも、11月12日時点では公表されていません。ただし、修正版のパッチ同士を比べれば修正箇所は推測できるため、公表後は悪用までの時間が短くなりがちです。悪用の報告を待たずに更新を進めてください。

### 8.0.37と8.0.38のどちらへ上げればよいですか？

CVE-2026-118383の修正は8.0.37から入っているので、どちらでも本件は塞がります。8.0.38は11月5日に出た後続のパッチ版で、11月12日時点の8.0系の最新です。これから作業するなら、最新の8.0.38を更新先として選びます。9.0系なら9.0.8、8.3系なら8.3.17が同じ位置づけで、7.0系は7.0.48が修正版かつ最新です。

### 6.0系や4.4系のような古い系列にも修正版は出ていますか？

出ています。6.0.30・5.0.35・4.4.32が、新しい系列と同じ10月30日に公開されました。ただし、告知の一覧に無い8.2系や4.2系以前には修正版が示されていません。古い系列で動かしている場合は、今回は修正版を入れて急場をしのぎ、そのうえで一覧にある新しい系列への移行計画を立てるのが現実的です。

## 関連記事

- [MongoDBとは？ドキュメント指向データベースの仕組み・利点・使い方入門【9.0対応】](https://www.issoh.co.jp/column/details/3006/)：レプリカセットを含む基本構成の整理です。
- [MongoDBのインデックス設計：createIndexの書き方・ESRの並び順・explainの読み方【9.0で実測】](https://www.issoh.co.jp/tech/details/2626/)：更新後の性能確認に使えるexplainの読み方です。
- [CVEとCWEの違いとは？CWEの意味と、1件のCVEにCWEが付く仕組みを実例で解説](https://www.issoh.co.jp/tech/details/5119/)：本件のCWE-416の読み方を補います。
- [脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](https://www.issoh.co.jp/column/details/13101/)：DBが外から届くかを含めた点検の進め方です。
- [パッチ管理とは：KEVで優先度を決め、Patch Managerとapt・dnfで自動適用する手順](https://www.issoh.co.jp/tech/details/19309/)：定期的なパッチ追従の仕組み作りです。

---

出典: [MongoDB脆弱性CVE-2026-118383：レプリカセットの対象判定と修正版への更新手順](<https://www.issoh.co.jp/tech/details/19673/>)（株式会社一創）