MongoDBは、重大なuse-after-free（解放後メモリ使用）の脆弱性を修正しました。この脆弱性は「CVE-2026-118383」として追跡されており、CVSSスコアは9.5です。認証を受けていない攻撃者が、ネットワーク経由で悪用できます。
同社は社内でこのバグを発見しており、これまでに悪用の試みは確認していないとしています。アドバイザリーでは、この脆弱性によりサーバーがクラッシュするほか、特定の条件下ではサーバープロセス内で任意のコードが実行される可能性があると警告しています。
MongoDBのuse-after-free脆弱性
この脆弱性はレプリケーションコンポーネントに存在します。新たに選出されたレプリカセットのプライマリがキャッチアップを完了した時点で発動します。キャッチアップとは、書き込みを受け付ける前に、取りこぼした操作を適用するフェーズです。
影響を受けるのはレプリカセットのメンバーで、シャーディングされたクラスターのシャードおよびコンフィグサーバーのメンバーも含まれます。スタンドアロンのmongodインスタンスは影響を受けません。今回の問題は、任意のコード実行を可能にするMongoDBの新たなセキュリティ上の欠陥でもあります。数か月前には、同社が社内テストで発見した別のバグ「CVE-2026-8053」を公表したばかりです。
クラウドセキュリティソリューション
Datadog Security Labsは、攻撃がどのように進行し得るかを解説しています。脆弱なサーバーはログイン前でもpingリクエストを受け付けるため、認証されていないクライアントが、readConcern.afterOpTimeの値を持つpingコマンドを2回送信できます。これによりメンバー上に古い「ウェイター」が残り、再起動、ロールバック、またはステップダウンが起きるまで残り続けます。認証を有効にしても、この問題は防げません。
クラッシュを引き起こすには、攻撃者が制御できない条件がさらに2つ必要です。1つ目はメンバーが遅延すること、2つ目はそのメンバーが選挙に勝つことで、メンテナンス中や障害時などに起こり得ます。キャッチアップが終了すると、クリーンアップ処理が2回実行されて解放済みメモリに触れ、書き込みを受け付ける前にプロセスがクラッシュします。このため、特権やユーザー操作が不要であっても、攻撃の複雑さは「高」と評価されています。
研究者らは、4メンバー構成のレプリカセットを使い、MongoDB 8.0.34でクラッシュを再現しました。対象メンバーはセグメンテーション違反を記録し、バックトレースはCatchupState::abort_inlock()を示していました。8.0.37で同じフェイルオーバーを行ったところ、pingはUnauthorizedで拒否され、サーバーは稼働を続けました。Datadogはコード実行には至っていないため、リモートコード実行のリスクは、実証されたエクスプロイトではなく、ベンダーの評価にとどまります。
過去の事例は、迅速なパッチ適用が重要である理由を示しています。MongoBleed脆弱性（CVE-2025-14847）は、公表直後に実環境で悪用され、数日以内に公開エクスプロイトコードも出回りました。
インターネットへの露出も根強い問題です。攻撃者は、インターネットに公開されたMongoDBインスタンスを狙い続けています。ポート27017に対する大規模スキャンを行い、データベースを消去して身代金を要求しています。インターネットから到達可能なレプリカセットは、この脆弱性の最初の標的になりやすいといえます。
影響を受けるバージョンと修正バージョン
| ブランチ | 最初の修正リリース |
|---|---|
| 9.0 | 9.0.7 |
| 8.3 | 8.3.16 |
| 8.0 | 8.0.37 |
| 7.0 | 7.0.48 |
| 6.0 | 6.0.30 |
| 5.0 | 5.0.35 |
| 4.4 | 4.4.32 |
管理者は、すべてのレプリカセットメンバーを、使用しているブランチの修正リリースにアップグレードし、各ノードで稼働中のバージョンを確認する必要があります。コンテナや、メンテナンス中にオフラインだったメンバーも対象です。Atlasクラスターはメンテナンス時に自動でアップグレードされますが、メンテナンスを延期している顧客は、速やかにアップデートを適用してください。
パッチ適用が完了するまでは、ネットワークアクセスを必要なシステムのみに制限してください。これにより、認証なしのリクエストを送信できる相手は限定できますが、バグ自体は修正されません。
防御側は、MongoDBの構造化ログも確認する必要があります。readConcern.afterOpTimeの値が通常と異なる認証なしのpingコマンドや、MaxTimeMSExpiredエラーを探してください。次に、メンバーがキャッチアップを2回終了している記録（ログID 21363）と、その後に続く致命的なシグナルを探します。仕込まれたリクエストはフェイルオーバーのかなり前に届いている可能性があるため、同じメンバーの過去のログも確認してください。
最新の脅威に関するアラートのコンテキストをSOCに提供し、インシデントを迅速に阻止しましょう -> 16K SOCの脅威インテリジェンスを統合:
翻訳元: https://gbhackers.com/critical-mongodb-use-after-free-vulnerability/
