2026年7月、オープンソースのメッセージブローカーであるRabbitMQにおいて、2件のアクセス制御の脆弱性が公開されました。2つの脆弱性のうち、より深刻なCVE-2026-57219（CVSS 8.7）は、認証なしでたった1回のHTTPリクエストを送信するだけでRabbitMQのOAuth client secretを取得し、それを管理者アクセストークンと交換することで、ブローカー全体を制御できる脆弱性です。また、CVE-2026-57221（CVSS 5.3）は、最小権限を持つ認証済みユーザーが、マルチテナント環境において他テナントのキューやエクスチェンジ構造を不正に列挙し、運用情報を偵察できる権限回避の脆弱性です。
RabbitMQは年間1,500万回以上ダウンロードされており、注文、決済、認証イベント、内部通知など、現代のアプリケーションにおける中核的なデータパイプラインを担うミドルウェアです。今回の2つの脆弱性は、2024年初頭のバージョン3.13.0以降、コードベースに存在していましたが、公開前に実際の悪用事例は確認されていません。本記事では、CVE-2026-57219とCVE-2026-57221の技術的原因と攻撃シナリオを分析し、外部に公開されたRabbitMQ資産がどのようなリスクにさらされる可能性があるのかを確認します。
CVE-2026-57219・CVE-2026-57221脆弱性の概要
| 項目 | 内容 |
|---|---|
| 脆弱性ID | CVE-2026-57219 / CVE-2026-57221 |
| 対象製品 | RabbitMQ（managementプラグインが有効化された環境） |
| CVSS v4.0 | 8.7 (High) / 5.3 (Medium) |
| 影響を受けるバージョン | 3.13.0以降、パッチ適用前の全バージョン |
| 修正バージョン | 3.13.15、4.0.20、4.1.11、4.2.6、4.3.0以降 |
| CVE-2026-57219の成立条件 | OAuth 2設定 + management.oauth_client_secret構成 + managementプラグインの有効化 |
| CVE-2026-57221の成立条件 | 仮想ホストに有効なログインが可能なアカウント（最小権限のアカウントを含む） |
CVE-2026-57219・CVE-2026-57221の技術的原因
CVE-2026-57219
CVE-2026-57219の要点は比較的単純です。RabbitMQ管理プラグインのGET /api/authエンドポイントは、OAuth設定情報を返す目的で作成された後、廃止予定の状態で残されていました。このエンドポイントの権限検証関数であるis_authorized/2にはtrueがハードコードされており、他のすべての機密性の高い管理エンドポイントとは異なり、リクエスト送信者の身元や権限を一切検証していませんでした。このエンドポイントが返すOAuth設定には、management.oauth_client_secretが含まれます。この値は、RabbitMQブローカーがEntra ID、Auth0、Keycloak、UAAなどのIDプロバイダーと機密クライアント方式で認証する際に使用する共有シークレットであり、本来はサーバー側のみが保持すべき機密認証情報です。
攻撃者は、このシークレットを1回の未認証GETリクエストで取得した後、ブローカーになりすましてIDプロバイダーにcredential grantリクエストを送信します。IDプロバイダーはこれを正規のブローカー認証として処理し、管理者アクセストークンを発行します。その後、攻撃者はすべてのメッセージの閲覧・変更・削除、ユーザー作成および権限変更、キュー・エクスチェンジ管理、ブローカー設定全体の変更など、ブローカーに対する完全な管理者権限を取得します。
CVE-2026-57221
CVE-2026-57221は、RabbitMQの「passive」キューおよびエクスチェンジ宣言処理において、権限検証が欠落していた脆弱性です。Passive宣言は、キューやエクスチェンジを作成せず、単に存在の有無だけを確認する操作です。この処理では読み取り権限の確認も行われないため、仮想ホストに接続可能なアカウントであれば、追加権限がなくても、その仮想ホスト内に存在するすべてのキューとエクスチェンジの名前、メッセージ数、コンシューマー数を照会できます。この脆弱性は、メッセージ内容を直接露出したり、データを改ざんしたりするものではありません。しかし、複数のアプリケーションやチームが同じ仮想ホストを共有するマルチテナント環境では、他テナントのキュー構造やメッセージ処理量を通じて、業務フローやサービス規模を推測できる運用インテリジェンスが漏えいする可能性があります。
攻撃シナリオ：偵察からブローカー完全制御まで
CVE-2026-57219を単独で悪用するシナリオでは、攻撃者は外部に公開されたRabbitMQ管理ポート（15672）を探索した後、GET /api/authリクエストを1回送信してOAuth client secretを取得します。その後、このシークレットを使ってIdPに管理者トークンを要求し、発行されたトークンでブローカー全体を制御します。この過程では、別途のマルウェアや複雑な手法は必要ありません。
CVE-2026-57219とCVE-2026-57221を組み合わせるシナリオでは、低権限アカウントや公開アクセス可能なアカウントを使って、まずCVE-2026-57221を悪用し、ブローカー内のキュー構造を詳細に把握します。決済処理、注文管理、認証イベントなど、高価値データが流れるキューを特定した後、CVE-2026-57219で取得した管理者権限により、該当キューのメッセージを直接閲覧または操作します。
単一のブローカーではなくクラスター環境の場合、被害範囲はさらに大きくなります。管理者トークンを使ってクラスター全体の設定を変更したり、新しいユーザーを作成して、パッチ適用後も継続的なアクセスを維持したりする可能性があります。
Criminal IPで観測された外部公開RabbitMQ管理インターフェース
CVE-2026-57219の実際の攻撃対象領域を把握するため、Criminal IP IT資産検索で異なるクエリを活用し、インターネットに公開されたRabbitMQ管理インターフェースを3つの観点から分析しました。
RabbitMQ管理UI全体の外部公開状況
Criminal IP検索クエリ: title: RabbitMQ Management
上記クエリによる検出結果では、2026年7月時点で約4,100件の外部公開RabbitMQ管理インターフェースが確認されました。RabbitMQ管理Webインターフェースは、ログインページのタイトルに「RabbitMQ Management」をそのまま表示します。このクエリは、ポートやTLS設定に関係なく、パブリックインターネット上で管理UIを識別できるすべてのRabbitMQインスタンスを捉えるものであり、CVE-2026-57219の潜在的な攻撃対象領域全体を把握する出発点になります。CVE-2026-57219の攻撃は、管理UIが外部から識別可能な状態であることを確認するところから始まります。検出されたインスタンスでOAuth 2とmanagement.oauth_client_secretが設定されている場合、GET /api/authリクエスト1回でブローカー制御につながる可能性があります。
デフォルトHTTP管理ポートの外部露出＝攻撃リスクの高い資産
Criminal IP検索クエリ: title: RabbitMQ Management port:15672
2つ目のクエリは、最初のクエリで確認された全体的な公開状況のうち、RabbitMQのデフォルトHTTP管理ポート（15672）が外部に直接公開されているインスタンスをフィルタリングします。2026年7月時点で、約1,800件の資産が検出されました。このクエリで検出された資産が最も高いリスク群に該当する理由は、主に3つあります。
- ポート15672はTLSなしの平文HTTPで運用されるデフォルトポートです。CVE-2026-57219の脆弱なエンドポイントであるGET /api/authへのレスポンスが暗号化されずに送信されるため、中間経路上のネットワーク区間でもシークレットが露出する可能性があります。
- デフォルトポートを変更しないまま外部に公開しているという事実は、セキュリティ設定全般がデフォルト値から大きく変更されていない可能性を示唆します。OAuthシークレットの露出有無とは別に、その他のアクセス制御設定も脆弱である可能性があります。
- ポートスキャナーや自動化された攻撃ツールはデフォルトポートを優先的に探索するため、これらのインスタンスはすでに攻撃者による探索対象となっている可能性が高いと考えられます。
このような理由から、2つ目のクエリで検出された資産には、迅速かつ積極的な対応と資産管理が必要です。
RabbitMQ管理インスタンスのうちSSL証明書が期限切れの資産
Criminal IP検索クエリ: title: RabbitMQ Management ssl_expired: true
3つ目のクエリは、SSL証明書が期限切れの状態で運用されているRabbitMQ管理UIインスタンスを識別します。このクエリがCVE-2026-57219の文脈で特に重要なのは、SSL証明書の期限切れが単なる証明書管理ミスにとどまらず、運用状態そのものを反映する可能性があるためです。
SSL証明書の更新は、多くの運用環境で自動化されるか、定期点検項目として管理されます。証明書が期限切れのまま放置されているインスタンスは、そのシステムのセキュリティ保守が全般的に不十分であることを示す間接的な指標です。このような環境では、アプリケーション更新やセキュリティパッチの適用も遅れている可能性があります。特にCVE-2026-57219が2024年初頭のバージョン3.13.0で導入された点を考慮すると、SSL証明書の期限切れ期間が長いインスタンスほど、脆弱なバージョンで長期間運用されてきた資産である可能性が高くなります。
また、証明書が期限切れの状態でもHTTPS接続が成立する場合、つまりクライアント側で証明書検証がスキップされる場合、/api/authエンドポイントは引き続き外部からアクセス可能な状態にあります。これらの資産は、OAuthクライアントシークレットがすでに取得されていないかを確認するため、最優先でログ監査を行うべき対象です。
3つのクエリを階層的に解釈すると、RabbitMQ公開資産のリスク分布が明確になります。最初のクエリは、理論上CVE-2026-57219攻撃が可能な外部公開RabbitMQ管理インターフェースの全体像を示します。2つ目のクエリは、HTTPデフォルトポートが開いており、追加の偵察なしに/api/authリクエストを即時送信できる直接攻撃可能な資産を示します。最後のクエリは、セキュリティ保守の不足によりパッチ未適用の可能性が高く、シークレットがすでに流出している可能性まで考慮すべき最優先対応資産を示します。
パッチ状況および対応策
2つの脆弱性はいずれも次のバージョンで修正されているため、3.13.15、4.0.20、4.1.11、4.2.6、4.3.0以降へ速やかにアップグレードする必要があります。
修正内容を見ると、CVE-2026-57219では/api/authエンドポイントが完全に削除されました。新しい実装では、OAuth設定が認証済みのブートストラップメカニズムを通じて渡され、シークレットがHTTPレスポンスに含まれないようになっています。CVE-2026-57221では、passiveキューおよびエクスチェンジ宣言経路に、他のすべての管理操作と同じ権限チェックが追加されました。パッチ適用後は、必ずOAuth client secretをローテーションする必要があります。パッチは脆弱なエンドポイントを削除しますが、すでに露出したシークレットを無効化するものではありません。管理インターフェースが信頼できないネットワークからアクセス可能だった期間がある場合、そのシークレットがすでに収集された可能性を前提にローテーションを実施する必要があります。IDプロバイダー（Microsoft Entra ID、Auth0、Keycloak、UAA）でクライアントシークレットを再生成し、RabbitMQ設定のmanagement.oauth_client_secret値を新しいシークレットに更新します。
即時アップグレードが難しい環境では、CVE-2026-57219について、WAFルールで/api/authエンドポイントへのすべてのアクセスを遮断する一時的な対策が可能です。また、ポート15672・15671への外部アクセスをファイアウォールで遮断し、OAuth 2プラグインまたはmanagementプラグインを一時的に無効化する方法もあります。CVE-2026-57221には別途のワークアラウンドやWAFによる緩和策はなく、テナントを別々の仮想ホストに分離することが、パッチ適用前に取り得る唯一の緩和策です。固定されたコンテナイメージ、Helmチャート、他製品に組み込まれたRabbitMQも必ず確認する必要があります。アップストリームのパッチが配布されていても、固定されたイメージバージョンを使用している環境は、依然として脆弱な状態のまま残る可能性があります。
FAQ
Q1. OAuth 2を使用していないRabbitMQ環境もCVE-2026-57219の影響を受けますか？
いいえ。CVE-2026-57219は、OAuth 2プラグインが有効化されており、management.oauth_client_secretが設定されている場合にのみ影響します。クライアントシークレットが設定されていない場合、/api/authエンドポイントは応答しますが、シークレットが存在しないため取得される情報はありません。LDAP、内部ユーザーデータベース、またはシークレットを使用しないOAuth設定のみを利用している環境は直接的な影響を受けません。ただし、CVE-2026-57221および同一リリースに含まれるCVSS 9.1・9.2の脆弱性への対応という観点から、アップグレードが必要です。
Q2. CVE-2026-57221はCVSSが5.3と低いのに、なぜ重要視すべきですか？
CVSS 5.3は単独での脅威レベルを反映したものであり、CVE-2026-57219との組み合わせによる悪用可能性は含まれていません。実際の脅威シナリオでは、2つの脆弱性を組み合わせられる可能性がある点や、キュー・エクスチェンジ構造およびメッセージ量の情報が、標的型攻撃の設計において有用なインテリジェンスとなり得る点を考慮する必要があります。特にSaaSプラットフォームや共有メッセージングインフラにおいて、複数の顧客が同じ仮想ホストを使用している場合、あるテナントが別テナントのアプリケーション内部構造を把握できるという点は、単なるCVSSスコア以上のビジネスリスクを意味します。
結論
CVE-2026-57219とCVE-2026-57221は、ソフトウェアにおける構造的な不整合の典型例を示しています。廃止予定エンドポイントの権限検証関数にハードコードされたtrue、passive宣言経路で欠落していた権限チェックが、2024年初頭から数百万回のダウンロードを通じて配布されていました。発見チームは、これらの欠陥について「人手によるコードレビューでは見落とされやすい一方で、コード全体を同時に比較分析する自動化ツールが検出するのに適した」タイプの脆弱性だったと説明しています。
RabbitMQを運用する組織が今すぐ確認すべき点は3つです。バージョンが3.13.0以上かつ修正バージョン未満であるか、OAuth 2とクライアントシークレットが設定されているか、管理ポート（15672・15671）が信頼できないネットワークからアクセス可能な状態にあるかです。この3つの条件が同時に満たされる場合、パッチ適用とシークレットのローテーションを直ちに実施する必要があります。特に、SSL証明書が期限切れのまま運用されているインスタンスは、セキュリティ保守全般が不十分な状態である可能性が高いため、最優先の点検対象として扱うべきです。
なお、関連してインターネットに露出したCisco IOS管理インターフェース：レガシーネットワーク機器が再び攻撃対象となる理由の記事もご参考いただけます。
Criminal IP（criminalip.io/ja/register）に登録すると、すぐに脆弱資産の検知を開始できます。さらに、下記ボタンからデモをご依頼いただくことで、エンタープライズ環境において外部に露出した資産を対象としたCriminal IP の脅威インテリジェンス（TI）分析を直接ご確認いただけます。
本レポートは、サイバー脅威インテリジェンス検索エンジン Criminal IP のデータを基に作成されています。
今すぐCriminal IP の無料アカウントを作成すれば、本レポートで引用された検索結果を直接確認したり、さらに膨大な脅威インテリジェンスを自由に検索することができます。
データソース: Criminal IP(https://www.criminalip.io/ja), TheHackerNews(https://thehackernews.com/2026/07/rabbitmq-flaws-could-leak-oauth-secrets.html), SecurityWeek(https://www.securityweek.com/rabbitmq-vulnerability-threatens-enterprise-systems/)
