Posted By ,

MongoBleed (CVE-2025-14847)：8年間潜伏していた致命的な MongoDB メモリ情報漏えいの脆弱性

概要

2025年末、MongoDB において長期間潜伏していた高危険度 (High) のメモリ情報漏えいの脆弱性が公開された。MongoBleed と名付けられた本脆弱性は、認証を伴わない状態で初期化されていないヒープメモリを読み取ることが可能であり、その結果、機密情報が漏えいする恐れがある。また、CISA は本脆弱性を KEV リストに登録し、実際に悪用されている可能性を前提として迅速な対応を推奨している。

本稿では、MongoBleed (CVE-2025-14847) の発生原理および攻撃フローを整理するとともに、8年間にわたり発見されなかった背景と、本脆弱性への対応策について解説する。

技術的背景

1. MongoDB ワイヤープロトコルとメッセージ圧縮

MongoDB は、クライアントとサーバー間の通信に HTTP ではなく、独自のバイナリプロトコルである MongoDB ワイヤープロトコル (Wire Protocol) を使用する。従来は OP_QUERY や OP_INSERT など複数の opcode が利用されていたが、MongoDB 5.1 以降、多くの処理が OP_MSG に統合された。OP_MSG は、BSON 形式のペイロードを送信する拡張性の高いメッセージフォーマットである。

2017年にリリースされた MongoDB 3.6 以降、zlib によるメッセージ圧縮機能が導入され、ネットワーク転送量を削減する選択肢が拡張された。MongoDB は snappy、zlib、zstd の3種類の圧縮アルゴリズムをサポートしており、クライアントとサーバーはハンドシェイク時に使用するアルゴリズムを交渉する。圧縮が有効な場合、既存のメッセージは OP_COMPRESSED メッセージとしてラップされ送信される。

[図 1] OP_COMPRESSED メッセージ構造

OP_COMPRESSED メッセージには、MsgHeader (16バイト)、originalOpcode (4バイト)、uncompressedSize (4バイト)、compressorId (1バイト)、そして圧縮されたペイロードが含まれる。uncompressedSize フィールドの値は検証されることなく信頼されるため、この値をそのまま用いることで、実際のデータサイズを超えるメモリバッファが割り当てられる可能性がある。

2. BSON 形式とパースメカニズム

BSON (Binary JSON) は MongoDB の基本データ形式であり、JSON-like 文書をバイナリ形式で直列化したものである。フィールド名 (element name) は、null-terminated 文字列 (cstring) として表現される。

[図 2] BSON 構造

MongoDB サーバーは、BSON データをメモリ上で順次パースする。まず文書全体のサイズを読み取り、その後各フィールドを1つずつ読み取る。各フィールドの読み取り時にはタイプバイトを確認し、null terminator に到達するまでフィールド名を読み進める。パース中に想定外のデータ構造が検出された場合、MongoDB は処理を中断してエラーを返し、そのエラーメッセージには問題が発生したフィールド名が含まれることがある。

CVE-2025-14847 脆弱性の原因

MongoBleed 脆弱性は、src/mongo/transport/message_compressor_zlib.cpp に実装された ZlibMessage Compressor::decompressData() 関数における長さ処理の不備と BSON パース処理が連動することで発生する。以下に各要因を説明する。

1. decompressData

[図 3] decompressData 関数

本関数は、OP_COMPRESSED メッセージを受信した際に圧縮データを展開する役割を担う。引数として、圧縮データを保持する ConstDataRange オブジェクトの input と、展開後データを格納するバッファである DataRange オブジェクトの output を受け取る。

関数はまず length 変数を宣言し、output.length() で初期化する。ここで output.length() は、割り当てられたバッファの全体サイズを返す。その後、zlib の uncompress() 関数を呼び出して実際の展開処理を行う。

uncompress() 関数のシグネチャは int uncompress (Bytef *dest, uLongf *destLen, const Bytef *source, uLong sourceLen) であり、destLen は入出力パラメータ (in-out parameter) である。呼び出し前は dest バッファのサイズを示し、呼び出し後には実際に展開されたデータサイズへと更新される。

本質的な欠陥は、戻り値の扱いにある。decompressData() 関数は、uncompress() によって更新された length 値ではなく、元々のバッファサイズである output.length() を返却してしまう。

2. BSON パースとメモリ漏えい

decompressData() が誤ったサイズを返却すると、初期化されていないメモリを含む大きなバッファが有効なデータとして扱われる。攻撃者は OP_COMPRESSED メッセージの uncompressedSize フィールドを操作し、サーバーに実データよりも大きなバッファを割り当てさせる。

通常、フィールド名は有効なデータ領域内で null terminator を迎えるが、返却されたバッファサイズが不正な場合、パーサは有効データの境界を超えて初期化されていないメモリ領域まで読み込む。この領域には、過去にヒープ上に存在していた文字列や断片が残存している可能性があり、パーサはそれをフィールド名として解釈しようとする。

初期化されていないメモリ内で偶然 null バイトに遭遇すると、そこまでのバイト列がフィールド名として認識される。結果として BSON 構造が不正となりパースは失敗するが、その際に生成されるエラーメッセージには、漏えいしたメモリ内容が含まれる。攻撃者はこのエラー応答を繰り返し収集することで、サーバーメモリ内の機密情報を取得できる。

攻撃シナリオ

[図 4] MongoBleed 攻撃シナリオのフロー図

脆弱な MongoDB インスタンスを前提とした場合、[図 4] のようにデータ漏えいが発生し得る。攻撃者は、zlib ベースの OP_COMPRESSED メッセージにおいて、長さやヘッダ情報を不正に構成した細工パケットを認証なしで送信する。サーバーは認証処理以前の段階でこれを展開処理に渡し、ヘッダ上の長さ情報と実際の処理長の不整合により、「実際に展開されたデータ長」と「割り当てられたバッファ長」が一致しないエラー状態が生じる。

その結果、サーバーは有効データ長を超えるサイズを後続処理に使用し、バッファの未使用領域に残存していた初期化されていないヒープメモリ断片が応答経路を通じてクライアントへ露出する可能性がある。漏えいするデータは断片的である場合が多いが、攻撃を繰り返す過程でトークン、鍵情報、認証情報などの機密データの一部が断片として流出する恐れがある。

実際に2025年12月末、ある大手オンラインゲームサービス事業者において、アカウント/運用システムの異常兆候およびサービス障害を伴うセキュリティインシデントが発生した。一部の報道やセキュリティコミュニティの分析では、その原因候補の一つとして MongoBleed (CVE-2025-14847) の悪用可能性が言及されている。

長期間発見されなかった理由

本脆弱性が長期間表面化しなかった背景には、同一入力であっても漏えい結果が毎回異なり得るという特性が大きく影響している。この種のメモリ情報漏えいは、ヒープレイアウト、メモリの割り当て・解放タイミング、ワークロードに依存したメモリ状態に左右されるため、再現性が低く、自動テストや一般的な障害解析において一貫したパターンとして把握しにくい。

運用面においても観測性は限定的である。MongoDB のデフォルトログ設定 (verbosity=0) は情報ログ中心であり、Assertion や COMMAND 関連のエラーをシステムログに出力するには verbosity を最低でも1 (Debug) 以上に設定する必要がある。そのため、特別な設定を行わずに運用している場合、攻撃トラフィックが流入しても詳細な原因を示すログが残らず、現場では単なる接続切断や一時的なエラーとして認識される可能性がある。

加えて、本問題は認証前の経路でトリガー可能であり、エラー応答も正規プロトコルの流れの中で返却されるため、単純なシグネチャベースの検知や単純な遮断ルールのみでは識別が困難である点も挙げられる。

対応策

MongoBleed 脆弱性への最も確実な対策は、修正済みバージョンへ直ちにアップグレードすることである。しかし、何らかの理由で即時更新が困難な場合には、暫定的な緩和策を講じることが可能である。まず、MongoDB インスタンスがインターネットに直接公開されないよう、ファイアウォール、ACL、VPC などを用いてネットワークアクセスを最小限に制限する。

また、本脆弱性は zlib ベースの OP_COMPRESSED 処理経路を悪用するため、zlib 圧縮設定を無効化し、zlib 圧縮メッセージの処理を遮断 (許可リストから除外) することが有効である。

[図 5] mongod.conf における zlib 圧縮無効化設定

ログの観点では、デフォルト設定 (verbosity=0) では十分なエラーの手掛かりが残らない可能性があるため、COMMAND コンポーネントの verbosity を1以上に引き上げ、InvalidBSON や Assertion while parsing command といったパース失敗の兆候がシステムログに出力されるよう可視性を確保する必要がある。

アンラボにおける対応状況

アンラボ製品群における検知名は以下のとおりである。

AIPS/HIPS 検知ルール

  • MongoDB zlib Decompression Information Disclosure Vulnerability(MongoBleed)-1

結論

MongoBleed (CVE-2025-14847) は、わずか一行の長さ処理の誤りが、長期間にわたって蓄積され、広範なリスクへと発展し得ることを示した事例である。公開情報やスキャン結果によれば、当時およそ8万7千台規模のインターネット公開インスタンスが存在していたとされる。

MongoDB ユーザーは、パッチ適用を最優先とし、やむを得ない場合にはネットワーク露出の遮断、zlib 無効化、ログ可視性の強化を併用すべきである。セキュリティ専門家は本事例を研究し、類似の脆弱性を事前に発見・予防するために活用する必要がある。また、ソフトウェア開発者は「セキュリティは機能より優先される」という原則を常に念頭に置くべきである。本脆弱性に関する詳細な技術分析は、AhnLab ATIPが提供する「MongoBleed 脆弱性分析報告書 (CVE-2025-14847) – AhnLab TIP」にて確認できる。

出典

関連 IOC および詳細な解析情報は、AhnLab の次世代脅威インテリジェンスプラットフォーム 「AhnLab TIP」 サブスクリプションサービスを通して確認できる。

Categories: 脆弱性