MongoDBの脆弱性CVE-2025-14847（MongoBleed）とは？影響バージョン・確認手順とzlib無効化の対策【2026年10月時点】

CVE-2025-14847は、MongoDB Serverがzlibで圧縮されたメッセージを解凍する処理で長さの扱いを誤り、認証前のクライアントに未初期化のヒープメモリを返してしまう脆弱性です。通称はMongoBleedです。影響は3.6系から8.2系までのほぼ全系列に及び、米CISAは2025年12月29日に悪用済み脆弱性カタログ（KEV）へ追加しました。この記事では、MongoDB公式のJIRA（SERVER-115508）とNVDの記載に沿って、影響版と修正版、自分の環境を確かめるコマンド、zlibを外す暫定策、2026年10月5日時点で上げるべき版までを整理します。

まとめ：MongoBleed（CVE-2025-14847）の影響有無と2026年10月時点の対応

自己管理のMongoDBは、2025年12月の修正版で止めず、各系列の最新まで上げてください。2026年9月にもMongoDB Serverへ未認証のサービス妨害を含むCVEが公表されています。すぐ上げられないなら、zlibを外し、待受ポート（既定は27017番）を外部から遮断したうえで、サーバのメモリに載っていた認証情報を入れ替えます。

CVE-2025-14847の影響バージョン・修正版とCVSS・KEV掲載の事実関係

影響バージョンと修正版の対応表とEOL済み系列への例外的な修正

NVDの記載では、下表の修正版より前の版が影響を受けます。4.2・4.0・3.6系は全版が対象で、修正版はありません。

サポート期限はMongoDBのライフサイクル表によります。修正が出た2025年12月の時点で、4.4・5.0・6.0はすでにサポートが終わっていました。それでも修正版が出たのは例外的な対応で、EOL済み系列が今後も修正を受けられる前提にはなりません。7.0系はJIRAに「7.0.0 through 7.0.26」とありますが、7.0.27は正式版が出ておらず、判定は「7.0.28未満」で行えば足ります。

CVSS 3.1の7.5とCVSS 4.0の8.7が示す未認証・機密性のみの影響

NVDに載る評価は、CNAであるMongoDB自身のものです。CVSS 3.1は7.5（AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N）、CVSS 4.0は8.7で、CWEはCWE-130（長さパラメータの不整合の不適切な処理）です。PR:Nは認証不要を、I:NとA:Nはこの欠陥自体が改ざんや停止を直接起こさないことを表します。ただし漏れた認証情報を使った不正ログインやデータ改ざんといった二次被害は、CVSSの値に含まれていません。CVSSの読み方は脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説で整理しています。

CVSS 3.1の区分では7.0〜8.9がHighで、7.5はその範囲に入ります。数字としては突出していませんが、ネットワークで届けば誰でも試せる条件です。数字の大小より、到達できる範囲で優先度を決めてください。

発見からCISA KEV追加までの時系列と公式発表で確認できる範囲

MongoDBのCTOが2025年12月29日に公開した公式ブログは、発見から公表までを米国東部時間で示しています。

ブログは、本件はMongoDBやAtlasへの侵害ではないとし、数十万のAtlasインスタンスへ数日で修正を当てたと説明しています。フォーラムの告知は、投稿時点で悪用や顧客データ侵害の証拠は無いとしていました。その後、CISAのKEVに掲載されたことで、悪用が確認された脆弱性の扱いになっています。PoCはoss-securityの投稿でも紹介されました。被害件数や悪用した主体は、公式発表では明らかにされていません。

zlib圧縮メッセージの長さ不一致から未初期化ヒープが返る仕組み

OP_COMPRESSEDの解凍処理で確保サイズを返していた1行の欠陥

MongoDBのワイヤプロトコルには、メッセージを圧縮して送るOP_COMPRESSEDがあり、ヘッダに解凍後のサイズを書きます。zlibの解凍処理は、このサイズでバッファを確保して解凍したあと、実際に解凍できた長さではなく確保したバッファの長さを返していました。ヘッダのサイズを実データより大きく偽ると、解凍されなかった残りの領域、つまり直前まで別の処理が使っていたヒープの中身が、後続の処理へデータとして渡ります。

修正はmongodb/mongoリポジトリのコミット（SERVER-115438）で確認でき、message_compressor_zlib.cppのreturn {output.length()};をreturn {length};に変える1行です。2026年1月にはSERVER-116125として解凍結果の検証を足す追加の堅牢化も入りました（修正対象は8.3.0-rc0）。zlib圧縮は2017年に追加された機能で、影響が3.6系からに及ぶのはこのためです。

認証前の解凍処理により資格情報なしでメモリを繰り返し読み出せる理由

圧縮メッセージの解凍は、認証コマンドの処理より前に走ります。そのため攻撃者は資格情報を持たずに、mongodやmongosの待受ポート（既定は27017番）へ細工したメッセージを送るだけで済みます。1回で漏れるのはその時点でたまたま残っていたメモリの断片で、狙った情報を選べません。ただし何度でも繰り返せるので、接続文字列のパスワードや、アプリが投げたクエリ中の個人情報が混ざる可能性は試行回数とともに上がります。

Atlasは2025年12月18日までに修正済みで、利用者側の作業はありません。危ないのは、EC2などのIaaSやオンプレミスで自分で動かしている自己管理版です。Atlasとの違いはMongoDB Atlasとは？クラスタ階層・料金・セキュリティ設定と採用判断を実装者目線で解説【2026年版】で扱っています。

自環境が影響を受けるかを確かめるバージョンとzlib有効状態の確認手順

mongod –versionとdb.version()で稼働中の版を確かめる手順

バイナリの版と、実際に動いているプロセスの版は、更新後に再起動していないとずれます。両方を見てください。以下のmongoshの例は接続先・認証・TLSの指定を省いています。認証を有効にしている環境では、接続文字列や--username、--tlsなどを付けて、serverStatusやgetCmdLineOptsを実行できる権限のユーザーで接続してください。

# インストール済みバイナリの版
mongod --version

# 稼働中のサーバの版（mongosh から）
mongosh --quiet --eval 'db.version()'

# レプリカセットのメンバー一覧（版は出ない。各メンバーへ直接接続して db.version() を実行する）
mongosh --quiet --eval 'rs.status().members.forEach(m => print(m.name, m.stateStr))'

出力が表の修正版より前なら影響を受けます。レプリカセットやシャードクラスタでは、プライマリだけでなくセカンダリやmongosも同じ扱いです。どのメンバーも外部から届く位置にあれば攻撃の入口になります。

Dockerイメージのタグとパッケージで固定された古い版を洗い出す手順

見落としが多いのは、開発用や検証用に立てたまま残っているコンテナと、パッケージ管理で版を固定したサーバです。mongo:7.0.14のようにタグで版を固定したコンテナは、イメージを取り直さない限り更新されません。逆にmongo:8.0のような系列タグでも、ホストに古いイメージが残っていれば古い版のまま起動します。

# 稼働中コンテナのイメージと、コンテナ内のバイナリの版（稼働中プロセスの版は db.version() で確認）
docker ps --format '{{.Names}} {{.Image}}' | grep -i mongo
docker exec <コンテナ名> mongod --version | head -1

# 公式リポジトリから入れたパッケージの版
apt list --installed 'mongodb-org*' 2>/dev/null   # Debian / Ubuntu
rpm -qa 'mongodb-org*'                              # RHEL 系

Debian・Ubuntuでapt-mark holdにより版を固定している場合は、apt-mark unholdで外さない限りapt upgradeでも上がりません。RHEL系でdnf versionlockを使っている場合も、ロックを外さない限りdnf upgradeでは上がりません。CI用やステージング用のインスタンスも、外部から届くなら本番と同じ扱いで確認してください。

serverStatusとgetCmdLineOptsによるzlib圧縮の有効状態の確認

設定リファレンスによると、net.compression.compressorsの既定値はsnappy,zstd,zlibです。設定ファイルに何も書いていなければzlibは有効です。

# 有効な圧縮方式の一覧（zlib が出なければ無効）
mongosh --quiet --eval 'printjson(Object.keys(db.serverStatus().network.compression || {}))'

# 起動時に指定された圧縮設定（未指定なら compression は出ない＝既定値）
mongosh --quiet --eval 'printjson(db.adminCommand({getCmdLineOpts: 1}).parsed.net)'

既定の起動なら一覧にzlibが含まれ、zlibを外した構成ではsnappyとzstdだけになります。設定を変えたあとは、再起動後にこの一覧で反映を確かめてください。

修正版へのアップデートとzlib無効化・通信制限による暫定対策

2026年10月時点の推奨版8.0.34・7.0.45と9.0系への移行判断

MongoDBのセキュリティアラート一覧には、2026年9月8日から11日にかけてMongoDB ServerのCVEが20件以上載っています。認証なしでmongosやレプリカセットのメンバーを停止させられるCVE-2026-82075とCVE-2026-82064（いずれも8.7）、設定の大文字小文字の扱いで起動時に認可が無効のまま残りうるCVE-2026-82067（9.2）が含まれます。多くは8.0.30・7.0.41・8.3.9で修正され、CVE-2026-89099は8.0.32・7.0.43・8.3.11が必要です。

9.0系は2026年9月に提供が始まり、現行は9.0.2、サポートは2031年10月31日までです。新しく組む環境なら候補ですが、稼働中のシステムはドライバーの対応を確かめてから移すのが無難で、当面は8.0系の最新で守れます。6.0以前からのメジャー移行は、5.0から6.0、6.0から7.0と1系列ずつ上げる必要があり、互換性の確認を含めた作業工数の確保が必要です。移行の設計や切替まで外部に任せたい場合はデータベース設計・移行支援で相談を受けています。

アップデートできない場合のzlib除外設定と起動オプションの書き方

JIRAの回避策は、networkMessageCompressorsまたはnet.compression.compressorsでzlibを明示的に外すことで、例としてsnappy,zstdかdisabledを挙げています。mongodとmongosの両方が対象です。

# /etc/mongod.conf（YAML）
net:
  compression:
    compressors: snappy,zstd

# 起動オプションで指定する場合
mongod --config /etc/mongod.conf --networkMessageCompressors snappy,zstd

設定の変更を反映するには再起動が必要です。レプリカセットはセカンダリから1台ずつ再起動し、最後にプライマリをrs.stepDown()で降格させてから再起動します。それでも新しいプライマリが選出されるまでの間（既定設定では通常12秒以内）は書き込みを受け付けないため、アプリ側でretryWritesを有効にし、接続のタイムアウトが選出時間より長いことを確かめておきます。クライアントとサーバの両方に共通する圧縮方式が無くなると非圧縮で通信するため、通信量が増えることがあります。これはあくまで修正版までのつなぎです。

自己管理環境で外部公開の遮断と認証情報ローテーションを優先する順番

実務での優先順は、外部からの到達を断つ、修正版へ上げる、認証情報を入れ替える、の順です。セキュリティグループやファイアウォールで、mongodとmongosの待受ポート（既定は27017番）への接続元をアプリサーバと管理端末だけに絞れば、未認証の攻撃はそもそも届きません。net.bindIpは接続元の許可リストではなく、サーバがどのネットワークインターフェースで待ち受けるかを決める設定です。外部向けのインターフェースで待ち受けないようにする用途で併用します。上げ終えたら、DBユーザーのパスワード、接続文字列に埋めたシークレット、同じサーバで扱っていたAPIキーを入れ替えます。漏れた可能性を否定できない以上、入れ替えは「念のため」ではなく対応手順の一部です。

MongoBleed対応後の継続更新・EOL系列の移行・悪用痕跡の調査

2026年9月の後続CVEを踏まえたマイナー版の更新周期

2025年12月に8.0.17や7.0.28へ上げた環境は、MongoBleedには対応済みでも、前章で挙げた2026年9月のCVEには未対応です。CVEが報道されるたびに版を合わせる運用では漏れが出ます。確認の担当者を決め、MongoDBのアラート一覧とリリースノートを月1回見て、同じ系列の最新版をまず検証環境に入れ、問題がなければ本番へ広げる、という周期を作ってください。どの環境をいつどの版へ上げたかを記録しておけば、次のCVEが出たときに影響範囲をすぐ絞れます。同じ考え方はPostgreSQLにも当てはまり、PostgreSQLの脆弱性CVE-2024-10979の解説でマイナー版の追随を整理しています。

EOL済み6.0以前と8.2で運用を続ける場合のリスクと見送れない場面

6.0以前の系列は、MongoBleedでは例外的に修正版が出ましたが、2026年9月のCVEの影響版一覧には7.0・8.0・8.3しか載っていません。EOL済み系列は、影響の有無そのものが公表されない状態です。8.2は2026年7月31日にサポートが終わっています。

移行を見送ってよいのは、外部から到達できない閉じたネットワークにあり、接続元がアプリサーバに限られ、かつ移行日程が決まっている場合だけです。インターネットやほかの拠点から27017番に届く構成、複数のアプリや利用者が同じインスタンスを共有する構成は見送れません。互換DBへの乗り換えも選択肢で、Amazon DocumentDBとは？MongoDB互換マネージドDBの仕組み・料金・採用判断を実装者目線で解説が比較の材料になります。

悪用の痕跡調査で公式情報から判断できる範囲と漏えいを否定できない理由

MongoDBの公式ブログとJIRAは、ログ上の痕跡（IoC）を示していません。言えるのは、攻撃にはmongodやmongosの待受ポート（既定は27017番。シャード構成では27018番・27019番も既定値）へTCPで接続する必要がある、という事実だけです。手がかりとして、mongodが既定で出力するConnection accepted（id 22943）の接続元を集計し、見覚えのない外部アドレスがないかを調べます。

# 接続元アドレスごとの接続回数（ログの場所は環境に合わせる）
grep -E '"id": ?22943[,}]' /var/log/mongodb/mongod.log \
  | grep -oE '"remote": ?"[^"]*"' | cut -d'"' -f4 \
  | sed 's/:[0-9]*$//' | sort | uniq -c | sort -rn | head

通常のドライバーは接続直後にclient metadata（id 51800）を記録します。接続だけが大量に並びメタデータが無い外部アドレスは、調べる価値があります。ただしこれは公式のIoCではなく、無いことが被害の無いことを示すわけでもありません。ファイアウォールやVPCフローログでも、影響を受ける版が稼働していた期間全体について、外部から実際の待受ポートへ届いた通信があったかを確認してください。欠陥は公表前から存在していたため、2025年12月以降に絞ると見落とします。

よくある質問

CVE-2025-14847の判定と対応で、よく確認される点をまとめます。

MongoDB Atlasを使っている場合も対応が必要ですか？

MongoBleedについては不要です。MongoDBの公式ブログによると、Atlasは2025年12月18日までに、メンテナンス枠を設定していたクラスタも含めて修正が適用されています。利用者側でできるのは、IPアクセスリストを絞ること、念のためDBユーザーのパスワードを入れ替えることです。同じ組織でEC2などに自己管理のMongoDBを置いている場合、そちらは別に確認してください。

自分のMongoDBのバージョンはどう確認しますか？

サーバ上でmongod --version、接続してdb.version()を実行します。更新後に再起動していないと両者がずれるため、判定は稼働中のdb.version()で行います。レプリカセットやシャードクラスタでは、セカンダリとmongosを含む全メンバーで確認してください。8.0系なら8.0.34、7.0系なら7.0.45が2026年10月5日時点の最新です。

zlibを無効にすると性能や接続に影響はありますか？

圧縮方式は、クライアントが接続時に示した候補とサーバの設定に共通するものから選ばれます。ドライバーは既定では圧縮を使わず、接続文字列のcompressorsで指定したときだけ圧縮します。zlibを外してもsnappyやzstdを両側で指定していればそちらで圧縮が続き、zlibしか指定していないクライアントは非圧縮に戻るため、帯域の狭い拠点間の通信量が増えることがあります。disabledにした場合は、圧縮自体が停止する設定です。いずれも再起動が必要で、修正版への更新までの暫定策です。

MongoDB 4.2以前を使い続けるとどうなりますか？

4.2・4.0・3.6系には修正版が出ていません。zlibを外せばMongoBleedの経路は塞げますが、それ以外の欠陥は修正されないまま残ります。4.4・5.0・6.0系も、サポート終了後の今回は例外的な修正でした。外部から届く位置にあるなら、ネットワークを閉じたうえで8.0系への移行を計画してください。

悪用されたかどうかを確かめる方法はありますか？

確実に判定する方法は公表されていません。手がかりは、mongodログのConnection acceptedの接続元と、ファイアウォールやフローログに残る、外部から待受ポート（既定は27017番）への通信です。痕跡が見つからなくても漏えいを否定できないため、修正版へ上げたあとに認証情報とシークレットを入れ替えるのが確実な対応です。

関連記事

• MongoDBとは？ドキュメント指向データベースの構造・ドキュメント・使い方入門
• MongoDB Atlasとは？クラスタ階層・料金・セキュリティ設定と採用判断を実装者目線で解説【2026年版】
• MongoDBのインデックス完全ガイド：種類・作成・ESR・効果確認
• Amazon DocumentDBとは？MongoDB互換マネージドDBの仕組み・料金・採用判断を実装者目線で解説
• 脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説