MongoDB Serverの重大度の高い欠陥により、数万件のデータベースが危険にさらされています。攻撃者は認証なしに、データベースのメモリから機密データを直接リモートで吸い出すことが可能です。
MongoBleedと名付けられたこの脆弱性は、影響を受けるシステムから残留メモリ内容を「漏えい（bleed）」させる能力があることから、Heartbleedと比較されています。
この脆弱性は「…認証されていないリモート攻撃者がMongoDB Serverインスタンスから未初期化のヒープメモリを読み取れるようにする」と、Censysの研究者が述べています。
MongoBleedのメモリ情報漏えい欠陥の内部
MongoBleed（CVE-2025-14847）は、MongoDB Serverにおけるzlibメッセージ伸長（解凍）実装に存在する、未初期化メモリの情報漏えい脆弱性です。
MongoDBインスタンスが特別に細工された圧縮メッセージを処理すると、伸長ルーチンのロジックエラーにより、サーバーが要求元へ返す前に明示的に初期化されていなかったヒープメモリの断片を返してしまう可能性があります。
ヒープメモリは動的に割り当てられ、クエリ処理、認証ワークフロー、セッション管理など、継続的な処理を扱うためにデータベースによって再利用されます。
その結果、漏えいしたメモリには過去のリクエストの残留データが含まれる可能性があり、平文の認証情報、認証キー、セッショントークン、またはデータベースが直近で扱った個人を特定できる情報（PII）など、極めて機微な成果物が露出する恐れがあります。
MongoBleedが特に懸念されるのは、悪用のハードルが低い点です。
この脆弱性は認証なしでトリガーできるため、MongoDBのサービスポートにネットワークレベルで到達できる任意のリモート主体が悪用を試みることができます。
攻撃者は有効な認証情報や事前のシステムアクセスを必要とせず、潜在的な攻撃対象領域が拡大します。
このリスクは、MongoDBのデフォルト設定によってさらに増幅されます。
標準的なデプロイではzlib圧縮がデフォルトで有効になっているため、管理者が明示的に圧縮を無効化するかネットワークアクセスを制限していない限り、公開と同時に多くのインスタンスが露出しました。
MongoDBインスタンスがパブリックインターネットから直接アクセス可能な環境では、悪用の試行を大規模に自動化できます。
また、実環境での能動的な悪用と、概念実証（PoC）の存在も報告されています。
メモリ情報漏えいに対するMongoDBの強化
MongoBleedがもたらすリスクに対処するには、迅速な修正対応と、より広範な防御的コントロールの両方が必要です。
- 修正済みバージョンへアップグレードしてMongoDBを直ちにパッチ適用し、サポート対象外のレガシーリリースから移行してください。
- 直ちにパッチ適用できない場合は、脆弱な伸長経路の悪用を防ぐため、MongoDBの設定でzlib圧縮を無効化してください。
- MongoDBインスタンスをプライベートネットワークに配置してネットワーク露出を制限し、信頼できるIP範囲のみにアクセスを限定し、インターネットに直接面したデータベースのデプロイを避けてください。
- 影響範囲を縮小し、潜在的なデータ露出の影響を抑えるため、認証、ロールベースのアクセス制御、およびTLS暗号化を強制してください。
- 監視ログとネットワークトラフィックを監視し、異常な接続挙動、不正な形式のリクエスト、または悪用の試行を示す可能性のある異常な応答サイズを検知してください。
- パッチ適用後にデータベースの認証情報と機密シークレットをローテーションし、継続的な資産発見と露出監視を通じて設定を検証してください。
これらのコントロールを組み合わせることで、影響範囲を縮小し、長期的なデータベースのセキュリティ耐性を向上させます。
MongoBleedは、コアコンポーネントにおけるメモリ安全性の欠陥が、デフォルト設定とパブリックインターネットへの露出によって増幅されるという、一般的なインフラリスクを改めて浮き彫りにしています。
この種のリスクへの対処は、境界防御に基づく前提を超え、アクセスを継続的に検証し暗黙の信頼を最小化するゼロトラストアプローチへ移行することが、ますます求められています。
翻訳元: https://www.esecurityplanet.com/threats/87k-mongodb-instances-exposed-by-mongobleed-vulnerability/
