RabbitMQに認証不要のブローカー乗っ取りを許す脆弱性が発覚

Miggoの研究者らは、攻撃者が脆弱なメッセージブローカーを乗っ取ったり、共有環境をまたいでデータを流出させたりすることを可能にする2件の脆弱性を発見しました。 

現時点でどちらの脆弱性も実際に悪用された形跡はありませんが、影響を受けるバージョンのRabbitMQを運用している組織は、提供済みのパッチ適用を優先すべきです。 

RabbitMQ脆弱性の要点

• 2件のRabbitMQ脆弱性により、影響を受ける環境で認証を経ないブローカー乗っ取りやテナントのメタデータ漏えいが起こり得る
• CVE-2026-57219では、攻撃者がRabbitMQのOAuthクライアントシークレットを取得し、脆弱なブローカーの管理者権限を掌握できる可能性がある
• CVE-2026-57221では認可チェックが回避され、認証済みユーザーがキュー・エクスチェンジ・テナントのメタデータを列挙できてしまう 

RabbitMQ脆弱性の詳細 

RabbitMQは、世界で最も広く導入されているオープンソースのメッセージブローカーの一つで、多くの企業向けアプリケーションのメッセージング基盤として機能しています。 

分散サービス間の通信を可能にするほか、決済取引の処理、認証イベントの処理、クラウドネイティブアプリケーションやマイクロサービスのサポートも担っています。 

RabbitMQは事業継続に不可欠なインフラの中核に位置することが多いため、このプラットフォームに影響する脆弱性は、機密性の高いアプリケーションデータの流出や重要な業務の中断につながりかねません。

Miggoの研究者らは、RabbitMQに影響を及ぼすアクセス制御関連の脆弱性を2件特定しました。 

一方は、未認証の攻撃者がブローカーの機密であるOAuthクライアントシークレットを取得できてしまうもの、もう一方は、権限を一切持たない認証済みユーザーであっても他のテナントに属するメタデータを閲覧できてしまうというものです。 

両脆弱性はいずれも2024年初頭のRabbitMQ 3.13.0で作り込まれ、Miggoによって発見され責任ある形で開示されるまでコードベースに残り続けていました。 

どちらの欠陥も実際の悪用が確認されているわけではありませんが、企業環境に及ぼしうる影響の大きさから、Miggoは組織に対応を優先するよう推奨しています。

CVE-2026-57219:未認証のOAuthシークレット漏えいがブローカーの完全乗っ取りを招く恐れ

CVSSスコア8.7のCVE-2026-57219は、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インスタンスが定期的な脆弱性管理プロセスに含まれていることも確認する必要があります。 

こうした見直しは、上流のパッチが公開された後も見落とされたまま脆弱性が残り続けているインフラを洗い出す一助となります。 

RabbitMQのようなプラットフォームのセキュリティを強化する中で、重要なアプリケーションやインフラを保護するためにゼロトラストソリューションの導入を進める組織も増えています。