MongoDB CVE-2026-8053（OOB Write）｜time-series由来の任意コード実行と自己ホスト機のsystemdローリング更新

JPCERT/CCが2026年5月20日の週次レポートで取り上げたMongoDB境界外書き込み（OOB Write）脆弱性は、CVE-2026-8053として公表されました。MongoDB Server 5.0系から8.3系まで現役6系列すべてが影響を受け、CVSS 4.0は8.7（High）です。time-series collectionの内部マッピング不整合を踏ませるとmongodプロセス内でメモリ破壊が起き、条件次第で任意コード実行に発展します。Atlasは適用済みですが、自己ホストはユーザー側で対応が必要です。本記事は影響評価・公式リポジトリでの更新・ReplicaSet/Sharded別のsystemdローリング手順・retryWrites設定を実務目線でまとめます。

CVE-2026-8053で何が壊れたか

CVE-2026-8053はCWE-787（境界外書き込み）で、根本原因はtime-series collectionの内部実装です。5.0以降のtime-seriesはドキュメントを時刻順にバケット化圧縮し「フィールド名→インデックスマッピング」を内部カタログに保持します。整合性が崩れた状態で書き込みが走ると、割り当て領域を超えるメモリ書き込みが発生しメモリ破壊が起こります。

攻撃成立条件と深刻度

項目	値	意味
CWE	CWE-787	境界外書き込み
CVSS 4.0	8.7（High）	緊急に近い高深刻度
攻撃元区分（AV）	Network	ネットワーク経由で攻撃可
攻撃条件複雑度（AC）	Low	特殊な前提条件は不要
必要権限（PR）	Low	DB書き込み権限を持つ認証ユーザー
利用者関与（UI）	None	被害者側の操作は不要
機密性／完全性／可用性	High／High／High	3要素すべて高インパクト

必要権限「DB書き込み権限を持つ認証ユーザー」が判断軸です。匿名は叩けないので即時乗っ取りにはなりませんが、社内開発者共有・SaaSテナント別DBアカウント・CI/CDワーカーは踏み台になります。共通高権限ユーザーで接続している場合、認証情報漏洩でOOB Writeから管理権限まで取られます。

影響を受けるMongoDB Serverバージョン

メジャー系列	脆弱なバージョン	修正バージョン
5.0系	5.0.33未満	5.0.33
6.0系	6.0.28未満	6.0.28
7.0系	7.0.34未満	7.0.34
8.0系	8.0.23未満	8.0.23
8.2系	8.2.9未満	8.2.9
8.3系	8.3.2未満	8.3.2

5.0系は公式サポート満了済みの延長サポート対象ですが、5.0.33までパッチが出ています。運用しているなら当てる必要があります。Atlasは2026年5月14日時点で適用済み、対応が必要なのは自己ホスト機です。

自己ホストMongoでの影響評価とまず確認すべきこと

Atlas以外のすべて、つまりオンプレ・EC2・Lightsail・GCE上のVMで自前mongodを動かしている全環境が対象です。確認は次の3つで完結します。

1. mongodプロセスとバージョンの実体確認

sudo pgrep -a mongod
mongod --version | head -1
sudo systemctl status mongod --no-pager | head -10

mongod --versionの出力先頭が「db version v8.0.22」のように脆弱バージョンを返したら即対応対象です。ドット3桁目まで見て、8.0.22と8.0.23では後者だけが安全です。

2. time-series collection利用有無の確認

mongo --quiet --eval 'db.adminCommand({listDatabases:1}).databases.forEach(function(d){db.getSiblingDB(d.name).runCommand({listCollections:1, filter:{type:"timeseries"}}).cursor.firstBatch.forEach(function(c){print(d.name+"."+c.name)})})'

time-series collectionを使っていなくても攻撃面はゼロになりません。書き込み権限ユーザーが新規作成して踏ませる経路があるため、利用有無に関わらず修正版へ上げるのが原則です。

3. 書き込み権限ユーザーの棚卸し

mongo --quiet --eval 'db.getSiblingDB("admin").system.users.find({},{user:1,db:1,roles:1}).forEach(printjson)'

readWrite・dbOwner・root・userAdminAnyDatabaseを持つアカウントが一覧されます。長期未使用や個人放置アカウントを見つけたら修正版適用と並行して無効化、二重防御として効きます。

MongoDB公式リポジトリでの更新手順

Linuxディストリ標準リポジトリの「mongodb」パッケージは古いコミュニティ版（3.x～4.x）で修正版は降りてきません。実運用はMongoDB公式yum/aptリポジトリ（repo.mongodb.org）前提で、2026年5月14日のリリース当日～48時間以内に該当メジャー系列へ反映済みです。

RHEL/Rocky/AlmaLinux系（mongodb-org 7.0系を8.0系修正版に上げる例）

# 1. 現在バージョン・リポジトリ反映確認
mongod --version | head -1
sudo dnf clean expire-cache
sudo dnf list available mongodb-org-server | tail -3

# 2. 同一メジャー内マイナー更新
sudo dnf update -y mongodb-org mongodb-org-server mongodb-org-shell mongodb-org-mongos mongodb-org-tools

# 3. バージョン確認
rpm -q mongodb-org-server

同一メジャー内更新は内部ストレージ形式が変わらず、停止→更新→起動の3ステップで完結します。メジャー跨ぎはfeatureCompatibilityVersion段階引き上げが必要なので、今回は同一メジャー内マイナー上げに限定します。

Ubuntu/Debian系

sudo apt-get update
apt-cache policy mongodb-org-server | head -5
sudo apt-get install --only-upgrade -y mongodb-org mongodb-org-server mongodb-org-shell mongodb-org-mongos mongodb-org-tools
dpkg -l | grep mongodb-org-server

Ubuntu jammy・noble・Debian bookwormは別リポジトリで提供されているので、/etc/apt/sources.list.d/mongodb-org-*.listの内容が自OSと合うかを確認します。Amazon Linux 2023はRHEL 9系を流用します。

反映タイミング目安

環境	経路	反映目安
RHEL/Rocky/Alma 9	MongoDB公式RPM	リリース当日～48時間
Ubuntu 22.04/24.04	MongoDB公式APT	リリース当日～48時間
Debian 12	MongoDB公式APT	リリース当日～48時間
Amazon Linux 2023	RHEL 9系RPM流用	リリース当日～48時間
OS標準リポジトリ（非公式古い版）	非対応	−

systemdローリング再起動の手順（単体・ReplicaSet・Sharded）

パッケージを上げただけでは動作中mongodは古いバイナリのまま走り続けます。構成種別ごとに整理します。

単体構成（スタンドアロン）

mongo --quiet --eval 'db.adminCommand({currentOp: true}).inprog.length'
sudo systemctl stop mongod
# 前章のパッケージ更新を実施
sudo systemctl start mongod
sudo systemctl status mongod --no-pager | head -10
mongo --quiet --eval 'db.version()'

単体構成は再起動中、書き込み・読み込みが全停止します。停止時間は10秒～数分（データサイズとWiredTigerチェックポイント次第）で、許容不可ならReplicaSet化検討、緊急対応では短時間メンテナンス枠で割り切る判断が現実的です。

ReplicaSet構成（3ノード想定）

順序は「SECONDARYから先に当て、最後にPRIMARYをstepDownしてから当てる」です。これによりPRIMARY不在時間が数秒～十数秒に抑えられます。

# 現状把握
mongo --quiet --eval 'rs.status().members.forEach(function(m){print(m.name + " " + m.stateStr)})'

# 各SECONDARYで実施: 停止→パッケージ更新→起動→追従確認
sudo systemctl stop mongod
sudo systemctl start mongod
mongo --quiet --eval 'rs.status().members.find(function(m){return m.self}).stateStr'

# 最後にPRIMARYでstepDown→停止→更新→起動
mongo --quiet --eval 'rs.stepDown(60)'
sudo systemctl stop mongod
sudo systemctl start mongod

rs.stepDown(60) はPRIMARY権限を最大60秒放棄するコマンドで、別SECONDARYがPRIMARYに昇格してクライアントが切り替わります。retryWrites=trueが有効なら書き込みはドライバ層で自動再試行され、アプリは数秒のレイテンシ上昇で通り抜けます。

Sharded Cluster構成

Sharded Clusterは「Config Server ReplicaSet → 各Shard ReplicaSet → mongos」の順で当てます。逆順にすると、mongosが古いConfig Server情報をキャッシュしたまま新Shardを叩く事故が起きます。

順序	対象	手順概要
1	Config Server ReplicaSet	SECONDARYから順、最後にPRIMARYをstepDown
2	各Shard ReplicaSet	シャード単位で同様、複数シャード並行も可
3	mongos（全ルーター）	順番にsystemctl restart mongos、ロードバランサで一台ずつ抜く

mongosは状態を持たないルーターなので、ロードバランサ（ALB・NLB・haproxy）背後なら一台ずつ抜きながら再起動できます。アプリが複数mongosを直接接続文字列に列挙しているなら、ドライバの接続プールが残り台数で吸収します。

クライアント側設定とFAQ

ローリング更新中にアプリへ波及させないコツは接続文字列です。次の3点を確認します。

• retryWrites=true: 既定で有効だが明示確認。フェイルオーバー時の書き込み再試行に必須。
• readPreference=primaryPreferred: PRIMARY不在時にSECONDARY読み込みを許す（要件整合時のみ）。
• w=majority: 書き込みが過半数ノードに行き渡るまで待機、ローリング再起動中の整合性確保に有効。

接続文字列例: mongodb://app:password@mongo1,mongo2,mongo3/mydb?replicaSet=rs0&retryWrites=true&w=majority&readPreference=primaryPreferred

FAQ

Q1. time-series collectionを使っていないが影響あるか？
A1. 影響あります。書き込み権限ユーザーが攻撃時に新規作成できるため、利用有無に関わらず修正版適用が必要です。

Q2. MongoDB Atlasでやることはあるか？
A2. サーバー側対応は不要。古いmongodb-driverを使い続けているならretryWrites=trueとTLS設定を再確認してください。

Q3. メジャー跨ぎ（6.0→7.0等）を同時にやってもよいか？
A3. 今回のパッチ目的に限れば、同一メジャー内マイナー更新にとどめるのが安全です。メジャー跨ぎは別タスクで計画します。

Q4. OS標準リポジトリの古いmongodbパッケージ（4.4以前）は？
A4. CVE-2026-8053は5.0系以降が影響範囲のため4.4以前は対象外ですが、5.0以前はコミュニティサポート完全終了で別CVE修正も来ません。5.0系以降への移行計画を別途必要とします。

Q5. パッチ適用後の動作確認ポイントは？
A5. (1) mongod --versionとrs.status()でバージョン・レプリカ整合確認、(2) writeレイテンシp95の悪化有無、(3) /var/log/mongodb/mongod.log のクラッシュ痕跡、の3点です。

まとめと次のアクション

CVE-2026-8053は現役全メジャー系列を直撃する境界外書き込みで、書き込み権限ユーザーがtime-series経由で任意コード実行まで持ち込めます。対応は自己ホスト機のみ、同一メジャー内マイナー更新で済みます。ReplicaSetならSECONDARYから順にsystemctl restart、最後にrs.stepDown(60)でPRIMARYを退避してから当てる手順でダウンタイムを最小化できます。書き込み権限ユーザー棚卸しを並行すれば二重防御として効きます。同月のnginx Rift（CVE-2026-42945）とあわせ、Webスタック全体の同時メンテ計画として整理してください。

---

• 前のページへ：PostgreSQL 18.4/17.10/16.14で11件のCVEを塞ぐ｜マイナー更新で済む再起動手順とPGDG運用
• この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る