RabbitMQに見つかった2件の脆弱性により、OAuthクライアントシークレットが漏えいし、アクセス制御が回避され、エンタープライズメッセージング基盤が攻撃者にさらされる恐れがあります。
広く利用されているオープンソースのメッセージブローカー「RabbitMQ」において、アクセス制御に関する2件の脆弱性が修正されました。これらの脆弱性は、エンタープライズアプリケーションのデータを外部にさらすだけでなく、環境によってはメッセージング基盤全体を攻撃者に完全掌握される恐れがあるものでした。
これらの欠陥はMiggo Securityによって発見されたもので、認証を経ていない攻撃者にOAuthシークレットを露出させ、権限の低いユーザーが他のテナントを盗み見できる状態を作り出していました。
「RabbitMQは、注文、決済、認証イベント、内部通知といった、現代のアプリケーション内部でサービス間のデータをやり取りする配管のような役割を担っています」と、Miggoの研究者は月曜日の公開に先立ちCSOに共有したレポートの中で説明しています。「RabbitMQは年間1500万回以上ダウンロードされており、その規模の大きさが格好の標的となっています」
この脆弱性は2024年初頭にリリースされたバージョン3.13.0以降のRabbitMQに影響しており、現在サポートされているすべてのバージョンで修正が完了しています。
廃止済みエンドポイントからOAuth設定が漏えい
より深刻な問題であるCVE-2026-57219は、RabbitMQの管理インターフェースにネットワーク経由でアクセスできる者であれば誰でも、認証なしにブローカーのOAuthクライアントシークレットを取得できてしまうというものです。
この脆弱性は、クエリを送信した相手に対してRabbitMQのOAuth設定（ブローカーの機密情報であるOAuthクライアントシークレットを含む）を返してしまう、廃止済みの管理用エンドポイント「GET /api/auth」に起因しています。Microsoft Entra ID、Auth0、Keycloak、UAAといったプロバイダーで機密性の高いOAuthクライアントを使用している環境では、攻撃者が漏えいしたシークレットを管理者トークンと交換し、ブローカーを完全に掌握できる可能性がありました。
この問題にはCVSS 10点満点中8.7という高い深刻度スコアが割り当てられており、バージョン3.13.15、4.0.20、4.1.11、4.2.6で修正されています。
RabbitMQは、この廃止済みエンドポイントを完全に削除するという形でこの問題に対処したと報告されています。代わりに、認証済みのブートストラップ機構を通じてOAuth設定を提供する仕組みに切り替えられ、HTTP経由でクライアントシークレットが露出することはなくなりました。
Miggoによると、この脆弱性の悪用に成功した攻撃者は、メッセージへのアクセスや改ざん、ユーザーの作成、ブローカー設定の変更が可能となり、エンタープライズアプリケーションを支えるメッセージング層を事実上侵害できてしまう恐れがあるとのことです。同社は、組織に対して直ちにアップグレードを行い、パッチ適用後は漏えいの可能性があるOAuthクライアントシークレットをすべてローテーションし、管理インターフェースを信頼できないネットワークに決して露出させないよう徹底することを推奨しています。
RabbitMQを管理するBroadcom傘下のTanzu部門は、CSOのコメント要請に対し即座には回答しませんでした。
偵察行為を許す認可バイパス
2つ目の脆弱性であるCVE-2026-57221は、RabbitMQのパッシブなキュー宣言・交換宣言の操作に影響する認可バイパスです。
この脆弱性の悪用には有効な認証情報が必要ですが、権限が一切割り当てられていないアカウントであっても、権限チェックが省略されてしまうために、キューや交換の存在有無を確認したり、メッセージ数やアクティブな消費者といったメタデータを取得したりすることが可能でした。
Miggoは、この脆弱性はメッセージの内容を露出させたり改ざんを許したりするものではないものの、共有環境において貴重な運用インテリジェンスを漏えいさせる恐れがあると指摘しています。研究者らによると、攻撃者はアプリケーションのマッピングやワークロード活動の監視を行い、同じ仮想ホストを共有する他のテナントへの後続攻撃に向けた偵察情報を収集できる可能性があるとのことです。
RabbitMQは、パッシブなキュー宣言・交換宣言に対しても他の操作と同様の認可チェックを確実に適用させることで、この問題を修正しました。この脆弱性には設定による回避策やWAFによる緩和策が存在しないため、組織にはパッチ適用済みのリリースへアップグレードし、パッチ適用が完了するまでテナントを別々の仮想ホストに分離しておくことが推奨されています。
Miggoによると、これらの脆弱性は同社の自律型セキュリティ研究プラットフォーム「VulnHunter」が発見した最初のCVEであり、その後同社のセキュリティチームによる検証を経て、RabbitMQのメンテナーに開示されました。メンテナー側は問題を確認し、パッチをリリースしたと報告されています。
