MongoDBに深刻な脆弱性、認証なしの攻撃者がデータベースサーバーをクラッシュさせ、RCEを引き起こす恐れ

MongoDBは、CVSS v4.0スコアが9.5に達する深刻なuse-after-free(解放後使用)型のメモリ破壊の脆弱性「CVE-2026-118383」を修正しました。MongoDB Serverのレプリケーションコンポーネントに対し、認証なしのネットワークリクエストを送るだけで、この脆弱性を悪用できます。

悪用されると、サーバーが突然停止するほか、条件によってはサーバープロセス内で任意のコードが実行される可能性があります。MongoDBは2026年11月10日に修正を発表しました。同社は、この脆弱性を社内で発見したと説明しており、悪用の試みは確認していないとしています。

この脆弱性はCWE-416に分類されます。新たに選出されたレプリカセットのプライマリがキャッチアップを完了した時点で発生します。キャッチアップとは、書き込みを受け付ける前に、見逃していた操作を適用する処理です。

影響を受けるのはレプリカセットのメンバーで、シャーディング構成のシャードやコンフィグサーバーのメンバーも含まれます。スタンドアロンのmongodインスタンスは、プライマリのキャッチアップを行わないため影響を受けません。

このクラスのメモリ安全性の欠陥は最近の脆弱性公表で目立っており、10月にChromeで修正された、use-after-freeやバッファオーバーフローなどの深刻な脆弱性もその一例です。

Datadog Security Labsの研究者は、攻撃の流れを次のように説明しています。攻撃者はまず、到達可能なメンバーに対し、readConcern.afterOpTime値を含む認証なしのpingコマンドを2回送信します。

脆弱なサーバーはログイン前でもpingを受け付けるため、認証を有効にしてもこの段階は防げません。リクエストによって、保留中のレプリケーション通知である「古い待機要素(waiter)」が2つ残ります。これらは、メンバーが再起動、ロールバック、またはステップダウンするまで残り続けます。

第2段階は、攻撃者が制御できない事象に左右されます。汚染されたメンバーが、ピアより遅れた状態でプライマリ選出に勝つ必要があります。これは通常、メンテナンス中や障害発生時に起こります。

キャッチアップが終了すると、クリーンアップ処理が2回実行され、解放済みのメモリが参照されます。クラッシュは、ノードが書き込みを受け付ける前に発生し、タイミング競合に勝つ必要もありません。

このため、CVSSベクターでは、権限もユーザー操作も不要であるにもかかわらず、攻撃の複雑さが「高」とされています。Datadogは、4メンバー構成のレプリカセットを使い、MongoDB Server 8.0.34でクラッシュを再現しました。

ログには、新しいプライマリが1ミリ秒以内にキャッチアップを2回抜ける様子が記録され、その直後に「Got signal: 11 (Segmentation fault)」と出力されました。バックトレースはCatchupState::abort_inlock()を指していました。

リクエストを送らない対照実験では稼働が続き、8.0.37での実験では両方のリクエストがUnauthorizedで拒否されました。テスト用クラスターはプライマリが不在の状態になりましたが、他の環境では新たなプライマリが選出される可能性があります。

研究者はコード実行には成功していないため、RCEの影響についてはベンダーのアドバイザリに依拠しています。MongoDBでは以前にも、OP_COMPRESSEDのクラッシュの脆弱性「CVE-2026-25611」で、同様に認証なしのサービス拒否(DoS)が可能な経路が明らかになりました。コード実行の脆弱性「CVE-2026-8053」も、セルフホスト環境に同種のリスクがあることを示していました。

修正版は9.0.7、8.3.16、8.0.37、7.0.48、6.0.30、5.0.35、4.4.32です。Atlasクラスターはメンテナンス中に自動でアップグレードされますが、メンテナンスを延期している利用者は、速やかに更新を適用する必要があります。

管理者は、コンテナやパッチ適用中にオフラインだったノードを含め、すべてのメンバーで稼働中のバージョンを確認してください。アップグレードが完了するまでは、ネットワークアクセスを信頼できるシステムのみに制限してください。これにより、待機要素を仕込める攻撃者は限られますが、脆弱性そのものがなくなるわけではありません。

防御側は、構造化ログから、ping、readConcern.afterOpTime、maxTimeMS、MaxTimeMSExpiredエラーを含むCOMMANDの「Slow query」イベント(ID 51803)を探してください。

あわせて、キャッチアップの開始エントリ(ID 21359)、キャッチアップの二重終了(ID 21363)、CatchupState::abort_inlock()を参照する致命的シグナルも確認してください。

リクエストはフェイルオーバーのかなり前に送られている可能性があるため、同じメンバーの過去のログも調べる必要があります。検知できるかどうかは低速操作のしきい値に左右され、attr.remoteにはループバックアドレスが表示される場合があります。

脅威調査の効率化と手作業の削減のため、1万6,000以上のSOCチームがANY.RUNを活用しています。チームで試してみる

翻訳元: https://cyberpress.org/critical-mongodb-flaw/

本記事は cyberpress.org の記事を翻訳・要約したものです。