Miggoの研究者は発見した、脆弱なメッセージブローカーの制御を攻撃者に奪われたり、共有環境全体のデータをさらされたりする可能性がある脆弱性2件を。
現時点で、いずれの脆弱性も実際の攻撃で悪用された証拠はないが、影響を受けるRabbitMQのバージョンを運用している組織は、提供済みのパッチ適用を優先すべきだ。
RabbitMQの脆弱性に関する主なポイント
- RabbitMQの脆弱性2件により、影響を受ける環境では認証なしでブローカーを乗っ取られたり、テナントメタデータをさらされたりする可能性がある。
- CVE-2026-57219では、攻撃者がRabbitMQのOAuthクライアントシークレットを取得し、脆弱なブローカーの管理権限を得られる可能性がある。
- CVE-2026-57221は認可チェックを回避し、認証済みユーザーがキュー、エクスチェンジ、テナントメタデータを列挙できるようにする。
RabbitMQの脆弱性の詳細
RabbitMQは世界で最も広く導入されているオープンソースのメッセージブローカーの1つであり、多くのエンタープライズアプリケーションのメッセージング基盤として機能している。
分散サービス間の通信を可能にし、決済トランザクションを処理し、認証イベントを扱うほか、クラウドネイティブアプリケーションやマイクロサービスを支えている。
RabbitMQはしばしばビジネスクリティカルなインフラの中心に位置するため、同プラットフォームに影響する脆弱性は、機密性の高いアプリケーションデータをさらし、重要な業務を妨げる可能性がある。
Miggoの研究者は、RabbitMQに影響するアクセス制御の脆弱性2件を特定した。
一方は認証されていない攻撃者がブローカーの機密OAuthクライアントシークレットを取得できるもので、もう一方は権限を持たない認証済みユーザーでも、他のテナントに属するメタデータを閲覧できるようにするものだ。
いずれの脆弱性も2024年初頭のRabbitMQ 3.13.0で導入され、Miggoが発見してRabbitMQのメンテナーに責任ある形で開示するまで、コードベースに残っていた。
いずれの欠陥も実際の攻撃で悪用された証拠はないが、企業環境に及ぼし得る影響を踏まえ、同社は組織に対して対策を優先するよう推奨している。
CVE-2026-57219：認証なしでのOAuthシークレット漏えいにより、ブローカー全体を乗っ取られる可能性
CVE-2026-57219はCVSSスコア8.7で、RabbitMQの廃止済み/api/auth管理エンドポイントにおける認可の欠陥に起因する。
このエンドポイントは認証を要求せずにブローカーの機密OAuthクライアントシークレットを返していたため、管理インターフェースに到達できる者なら誰でも、1回のリクエストで認証情報を取得できた。
リスクが最も大きいのは、Microsoft Entra ID、Auth0、Keycloak、Cloud Foundry UAAなどのIDプロバイダーと連携し、RabbitMQを機密OAuthクライアントとして利用している組織だ。
露出したクライアントシークレットを取得した攻撃者は、IDプロバイダーと交換して管理者アクセストークンを得ることで、実質的にブローカーになりすますことができる。
悪用に成功すれば、RabbitMQのユーザー、キュー、エクスチェンジ、メッセージ、ブローカー設定を含む管理権限を奪われる可能性がある。
Miggoは、機密性の高い管理データへのアクセスを制限せず、リクエストを常に承認していた認可チェックに問題の原因があるとした。
CVE-2026-57221：認可バイパスによりテナントメタデータが露出
2つ目の脆弱性であるCVE-2026-57221はCVSSスコア5.3で、RabbitMQのパッシブなキューおよびエクスチェンジの宣言機能に影響する。
この機能では、クライアントがキューやエクスチェンジを変更せずに存在を確認できるが、Miggoはこの操作で、同等のRabbitMQ機能に適用される認可チェックが実行されていないことを発見した。
その結果、権限を割り当てられていないアカウントを含め、認証済みユーザーなら誰でもキューやエクスチェンジを列挙し、メッセージ数やコンシューマー統計などのメタデータを取得できた。
この欠陥によってメッセージ内容が露出したり、データを不正に変更されたりすることはないものの、同じRabbitMQ環境を共有する他のアプリケーションやユーザーに関する運用上の詳細が明らかになることで、テナント分離が弱まる。
マルチテナント環境では、こうした情報によって攻撃者がアプリケーションアーキテクチャを把握し、価値の高い標的を特定し、その後の攻撃に向けた偵察を進められる可能性がある。
RabbitMQのリスクを低減する
影響を受けるRabbitMQのバージョンを利用している組織は、提供済みのパッチを適用し、潜在的なリスクを低減するため設定を見直すべきだ。
- パッチを最新バージョンに適用し、環境で機密OAuthクライアントを使用している場合は、パッチ適用後にOAuthクライアントシークレットをローテーションする。
- 直ちにパッチを適用できない場合は、代替策を検討する。例えばCVE-2026-57219について、WAFルールで脆弱なエンドポイントへのアクセスをブロックする。
- RabbitMQ管理インターフェースへのアクセスを制限するため、ネットワークセグメンテーション、VPN、IP許可リスト、ゼロトラストのアクセス制御を利用し、信頼できないネットワークには決して公開しない。
- RabbitMQのユーザー、管理者アカウント、仮想ホスト、権限を見直し、最小権限を徹底するとともに、適切な場合はテナントを専用の仮想ホストに分離する。
- 管理インターフェースのログとブローカーのアクティビティを監視することで、不正なAPIリクエスト、予期しない管理者アクセス、設定変更、通常とは異なるキュー列挙の試みを検出する。
- テストするインシデント対応計画を、机上演習やシミュレーションツールを用いて、ブローカーの侵害やメッセージングインフラへの不正アクセスを想定したシナリオで。
これらの対策は、全体的なリスクの低減や侵害時の影響範囲の限定、レジリエンスの強化に役立つ。
結論
公開時点では、いずれの脆弱性も実際の攻撃で悪用されたことは確認されていないが、組織はRabbitMQの環境を見直し、影響を受けるバージョンと設定を特定すべきだ。
また、管理インターフェースが適切に保護されていること、組み込み型またはパッケージ化されたRabbitMQインスタンスが通常の脆弱性管理プロセスに含まれていることも確認する必要がある。
こうした見直しにより、上流のパッチがリリースされた後も脆弱なまま残る可能性のある、見落とされたインフラを特定できる。
また、導入しているゼロトラストソリューションを活用して、重要なアプリケーションやインフラの保護を支援している。