CVE-2026-57219対策：Azure Linux 3.0のRabbitMQ OAuth資格情報漏えいを修正する方法

CVE-2026-57219への最優先対応は、Azure Linux 3.0のrabbitmq-serverを3.13.7-7.azl3以降へ更新することです。3.13.7-6を使用し、RabbitMQ管理プラグインでOAuth 2.0のクライアントシークレットを設定している環境では、管理用HTTP APIへ到達できる未認証の第三者に資格情報が漏えいする可能性があります。

OAuth 2.0を使用していない、management.oauth_client_secretを設定していない、または管理プラグインを無効にしている環境は、この脆弱性の成立条件には該当しません。ただし、設定の思い込みだけで判断せず、パッケージ、プラグイン、有効な設定、ネットワーク公開範囲を順番に確認する必要があります。MSRCではAzure Linux 3.0向けの修正版が示されていますが、個別の回避策は掲載されていないため、基本方針はセキュリティ更新の適用です。(Microsoft Security Response Center)

CVE-2026-57219の概要

項目	内容
CVE番号	CVE-2026-57219
対象	Azure Linux 3.0の`rabbitmq-server`
更新対象として扱うバージョン	`3.13.7-6.azl3`
Azure Linux向け修正版	`3.13.7-7.azl3`以降
漏えいする可能性がある情報	OAuth 2.0クライアントシークレット
問題のある機能	RabbitMQ Management Pluginの旧式な`GET /api/auth`エンドポイント
攻撃に事前認証が必要か	不要
深刻度	High
恒久対策	修正版パッケージへの更新
更新後に必要となり得る対応	クライアントシークレットのローテーション、ログ調査

RabbitMQの上流アドバイザリでは、CVSS 4.0の基本値は8.7で、重要度はHighです。脆弱なエンドポイントは修正版で単に認証必須へ変更されたのではなく、旧式で不要なエンドポイントとして削除されています。(GitHub)

CVE-2026-57219で何が漏えいするのか

問題となるのは、RabbitMQのAMQPユーザー名や内部ユーザーのパスワードではありません。

漏えいする可能性があるのは、RabbitMQの管理画面をOAuth 2.0またはOpenID ConnectのIDプロバイダーと連携させる際に設定する、次のクライアントシークレットです。

management.oauth_client_secret = <OAuthクライアントシークレット>

脆弱なバージョンでは、旧式の管理APIであるGET /api/authが認証なしで呼び出せる状態になっており、特定のOAuth 2.0構成ではレスポンスにクライアントシークレットが含まれる可能性があります。

漏えいしたシークレットがどこまで悪用できるかは、IDプロバイダー側の設定によって異なります。たとえば、対象のクライアントに強いロールや広いスコープが割り当てられている場合、攻撃者がトークンを不正取得し、RabbitMQの管理APIや関連リソースへアクセスできる可能性があります。

一方、クライアントシークレットがトークン発行に使用できない構成や、権限が限定されている構成では、直ちにRabbitMQ全体が乗っ取られるとは限りません。それでも、認証情報そのものが未認証で漏れる問題であるため、影響を小さく見積もるべきではありません。(GitHub)

影響を受ける環境の条件

次の条件が重なる環境は、CVE-2026-57219の影響対象として扱います。

Azure Linux 3.0を使用している
rabbitmq-server-3.13.7-6.azl3を使用している
rabbitmq_managementプラグインが有効
OAuth 2.0を管理画面で使用している
management.oauth_client_secretを設定している
管理用HTTP APIへ攻撃者が到達できる

特に優先度が高いのは、管理画面やHTTP APIをインターネット、社内共用ネットワーク、開発者用ネットワークなどへ公開している環境です。

環境の状態	判断	対応優先度
`3.13.7-6`、シークレットあり、外部公開あり	脆弱性を悪用され得る	最優先で隔離、更新、シークレット交換
`3.13.7-6`、シークレットあり、管理ネットワーク限定	影響対象	速やかに更新
`3.13.7-6`、シークレットなし	本脆弱性の主要な成立条件なし	通常の緊急更新手順で更新
`3.13.7-6`、管理プラグイン無効	本脆弱性の成立条件なし	パッケージ更新は実施
`3.13.7-7`以降	修正済み	過去の公開状況を確認
設定や公開範囲が不明	影響ありとして扱う	調査完了まで管理APIを制限

管理用ポートを社内ネットワークだけに限定していても、安全が保証されるわけではありません。侵害済み端末、踏み台サーバー、VPN利用者、同一ネットワーク内の別システムから到達できる場合があります。

Azure Linux 3.0で影響を確認する手順

OSとRabbitMQのバージョンを確認する

最初に、OSとインストール済みパッケージを確認します。

cat /etc/os-release

rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' rabbitmq-server

次のようなバージョンが表示された場合は、更新対象として扱います。

rabbitmq-server-3.13.7-6.azl3.x86_64

修正後は、少なくとも次のリリースになっていることを確認します。

rabbitmq-server-3.13.7-7.azl3.x86_64

上流のRabbitMQでは3.13系の修正版として3.13.15が案内されていますが、Azure Linuxでは修正をディストリビューション用パッケージへ取り込んだ3.13.7-7.azl3が案内されています。上流バージョンの数字だけを見て「3.13.15未満だから未修正」と判断せず、Azure LinuxのRPMリリース番号まで確認してください。(Microsoft Security Response Center)

管理プラグインとOAuthプラグインを確認する

有効なプラグイン名だけを表示します。

sudo rabbitmq-plugins list -e -m \
  | grep -E '^rabbitmq_(management|auth_backend_oauth2)$'

次の両方、または少なくともrabbitmq_managementが表示された場合は、設定確認へ進みます。

rabbitmq_management
rabbitmq_auth_backend_oauth2

rabbitmq-plugins listの-eオプションは、明示的または依存関係によって有効になっているプラグインを表示します。(RabbitMQ)

実際に読み込まれている設定ファイルを確認する

RabbitMQの設定ファイルは、必ずしも/etc/rabbitmq/rabbitmq.confだけとは限りません。環境変数で場所が変更されている場合や、複数の設定ファイルが読み込まれている場合があります。

sudo rabbitmq-diagnostics status \
  | sed -n '/Config files/,+5p'

RabbitMQ公式ドキュメントでも、rabbitmq-diagnostics statusのConfig filesセクションで実際の設定ファイルを確認する方法が案内されています。(RabbitMQ)

シークレットの値を表示せずに設定有無を調べる

次のコマンドは、該当設定を含むファイル名だけを表示します。シークレットの実値は出力しません。

sudo grep -RIlE \
  '^[[:space:]]*management\.oauth_client_secret[[:space:]]*=' \
  /etc/rabbitmq 2>/dev/null

環境変数の展開やadvanced.configなどを使用している場合は、有効な設定にも該当キーが存在するか確認します。

if sudo rabbitmq-diagnostics environment 2>/dev/null \
  | grep -q 'oauth_client_secret'; then
  echo "oauth_client_secret: configured"
else
  echo "oauth_client_secret: not detected"
fi

rabbitmq-diagnostics environmentをそのまま画面やチケットへ出力すると、設定値を含む情報が表示される可能性があります。調査結果を共有するときは、必ずシークレットやトークンをマスキングしてください。

本番環境でGET /api/authを直接呼び出し、シークレットが返るか試す検証は避けてください。 レスポンスをブラウザー、端末、プロキシ、監視製品、コマンド実行履歴などへ新たに残し、漏えい範囲を広げるおそれがあります。

管理APIの待受ポートと公開範囲を確認する

RabbitMQノードが使用しているリスナーは、次のコマンドで確認できます。

sudo rabbitmq-diagnostics listeners

出力例では、管理HTTP APIがhttpまたはhttpsとして表示されます。

Interface: [::], port: 15672, protocol: http, purpose: HTTP API
Interface: [::], port: 15671, protocol: https, purpose: HTTP API over TLS

実際のリスクは、サーバー上の待受状態だけでは判断できません。次の経路も確認してください。

Azure NSGや外部ファイアウォール
ロードバランサー
リバースプロキシ
VPNや踏み台サーバー
KubernetesのServiceやIngress
社内ネットワーク間のルーティング
IPv6経由の到達性
管理ポートへの直接アクセス経路

リバースプロキシで制限していても、RabbitMQの管理ポートへ直接接続できる経路が残っていれば、プロキシ側の制御を迂回されます。rabbitmq-diagnostics listenersはノード上の待受確認には有効ですが、外部からの到達性はネットワーク構成と組み合わせて判断する必要があります。(RabbitMQ)

CVE-2026-57219を修正する手順

更新前に確認する項目

更新前に、少なくとも次の状態を記録します。

rpm -q rabbitmq-server

sudo rabbitmq-diagnostics ping
sudo rabbitmq-diagnostics check_running
sudo rabbitmqctl cluster_status

あわせて、次の点を確認してください。

設定ファイルとシークレットを安全な方法で復旧できる
RabbitMQクラスタの全ノードとバージョンを把握している
クライアント側で再接続が機能する
単一ノードの場合は停止時間を確保している
クラスタの場合は1台停止してもキューの可用性を保てる
ロードバランサーから更新対象ノードを一時的に外せる
監視やアラートの連絡先が決まっている

設定ディレクトリを安易に別の場所へコピーすると、OAuthシークレットを含むファイルが増える可能性があります。バックアップは、既存の暗号化されたバックアップ基盤やシークレット管理手順を使用してください。

rabbitmq-serverを更新する

Azure Linuxでは、tdnfを使用してパッケージを更新できます。

sudo tdnf clean all
sudo tdnf upgrade rabbitmq-server

更新後、インストールされたRPMを確認します。

rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' rabbitmq-server

次のバージョン、またはそれより新しいAzure Linux向けパッケージであることを確認します。

rabbitmq-server-3.13.7-7.azl3.x86_64

Azure Linuxのパッケージ管理では、インストール済みパッケージの確認にrpm -qa、更新にtdnf upgradeを使用できます。(Microsoft Learn)

更新候補が表示されない場合は、次を確認します。

sudo tdnf list rabbitmq-server

確認すべきポイントは次のとおりです。

Azure Linux 3.0の正しいリポジトリが有効か
リポジトリのメタデータが古くないか
プロキシやDNSで更新先への通信が遮断されていないか
バージョン固定や除外設定がないか
独自リポジトリがMicrosoft公式リポジトリより優先されていないか

コンテナー内にRabbitMQを組み込んでいる場合は、ホストOS上のRPM更新だけでは修正されません。コンテナーイメージ内のRabbitMQパッケージを確認し、修正版を含むイメージを再ビルド、再配布してください。

RabbitMQを再起動して修正版を読み込む

RPMが更新されただけでは、実行中のRabbitMQプロセスが古いコードを使用し続けている可能性があります。運用手順に従ってサービスを再起動します。

sudo systemctl restart rabbitmq-server

再起動後に状態を確認します。

sudo systemctl --no-pager --full status rabbitmq-server

sudo rabbitmq-diagnostics ping
sudo rabbitmq-diagnostics check_running
sudo rabbitmq-diagnostics check_virtual_hosts
sudo rabbitmq-diagnostics check_local_alarms
sudo rabbitmqctl cluster_status

アプリケーションからも、次の動作を確認してください。

AMQPクライアントが再接続できる
メッセージの送受信が正常
Management UIへログインできる
OAuth 2.0による認証が正常
キュー、エクスチェンジ、バインディングが維持されている
クラスタ内の全ノードが稼働状態
監視指標やアラートが正常に取得できる

クラスタでは1ノードずつ更新する

複数ノードのRabbitMQクラスタでは、全ノードを同時に停止しないようにします。

更新対象ノードをロードバランサーから外す
クラスタとキューの状態を確認する
1ノードだけ更新する
RabbitMQを再起動する
クラスタへ正常復帰したことを確認する
アプリケーション通信を確認する
ロードバランサーへ戻す
次のノードへ進む

クォーラムキューやストリームを使用している場合は、更新中も必要なレプリカ数を維持できるか確認してください。単に「3台構成だから1台ずつなら安全」と判断せず、各キューの配置とオンラインメンバーを確認することが重要です。

更新できない場合の一時的な対応

MSRCでは、CVE-2026-57219に対する個別の回避策は掲載されていません。恒久対策は3.13.7-7.azl3以降への更新です。(Microsoft Security Response Center)

一方、RabbitMQの上流アドバイザリでは、更新までの回避策として次の選択肢が示されています。

一時対応	効果	主な影響
`rabbitmq_auth_backend_oauth2`を無効化して別の認証バックエンドへ切り替える	OAuth 2.0構成を停止する	ログイン方式やクライアント認証が変わる
`management.oauth_client_secret`を使用しないOAuth構成や別のグラント方式へ変更する	漏えい対象のシークレットをなくす	IDプロバイダー側の再設定が必要
`rabbitmq_management`を無効化する	問題のHTTP API自体を停止する	Management UIとHTTP APIが利用できなくなる
PrometheusとGrafanaなど別の監視手段へ移行する	管理プラグインへの依存を減らす	監視構成の変更が必要

これらは業務影響が大きいため、本番環境では認証方式、監視、運用ツールへの影響を確認してから実施します。(GitHub)

追加の封じ込め策として、管理APIを信頼できる管理ネットワークやVPNからだけ利用可能にし、リバースプロキシで/api/authへのアクセスを遮断する方法も考えられます。

ただし、これは修正プログラムの代わりにはなりません。RabbitMQの管理ポートへ直接アクセスできる経路が残っている場合や、別のプロキシ、IPv6、内部ネットワークから到達できる場合は、パス制御を迂回される可能性があります。

OAuthクライアントシークレットを交換すべきケース

次のいずれかに該当する場合は、更新後にOAuthクライアントシークレットをローテーションしてください。

管理APIをインターネットへ公開していた
社内の広いネットワークからアクセスできた
公開範囲を正確に特定できない
リバースプロキシやファイアウォールのログが残っていない
GET /api/authへのアクセス記録が見つかった
脆弱な状態でセキュリティ診断や自動スキャンを受けた
クライアントシークレットの有効期限が長い
対象クライアントに強いロールや広いスコープがある
過去に使用していたシークレットの漏えいを否定できない

シークレット交換の正しい順番

重要なのは、脆弱なエンドポイントを閉じる前に新しいシークレットへ交換しないことです。脆弱性が残った状態では、交換したばかりのシークレットも再び漏えいする可能性があります。

推奨する順番は次のとおりです。

管理APIへの外部アクセスを遮断する
rabbitmq-serverを修正版へ更新する
更新後のサービス稼働を確認する
IDプロバイダーで新しいクライアントシークレットを発行する
RabbitMQ側の設定またはシークレットストアを更新する
RabbitMQを再起動する
OAuthログインを確認する
古いシークレットを失効させる
不審なトークン発行や管理操作を調査する

IDプロバイダーが複数のシークレットを同時に有効化できる場合は、新旧シークレットを短時間だけ併存させると、認証停止を抑えながら切り替えられます。ただし、旧シークレットを残したままにせず、動作確認後すぐに失効させます。

漏えいの有無を調査するポイント

CVE-2026-57219は情報漏えいの脆弱性であり、パッケージを更新しても過去のアクセス履歴や漏えい済みシークレットは元に戻りません。

ネットワークとWebアクセスログ

次のログで、/api/authへのアクセスを確認します。

NginxやApacheなどのリバースプロキシ
Azure Application Gateway
Azure Load Balancer周辺のフローログ
Azure Firewall
Web Application Firewall
Kubernetes Ingress Controller
VPNや踏み台サーバー
社内プロキシ
RabbitMQのHTTPアクセスログを有効にしている場合はそのログ

確認する内容は、アクセス日時、送信元IPアドレス、User-Agent、HTTPステータス、レスポンスサイズ、同一送信元による後続アクセスです。

ただし、ログに記録がないことだけで「悪用されていない」とは断定できません。アクセスログを有効にしていなかった、ログ保存期間を過ぎた、直接ポートへ接続されたといった可能性があるためです。

IDプロバイダーのログ

対象のクライアントIDについて、次のイベントを確認します。

通常と異なる送信元IPアドレスからのトークン要求
想定していない国やネットワークからのアクセス
通常使用しないグラントタイプ
短時間に繰り返されるトークン発行
想定外のスコープやロールを含むトークン
管理者相当の権限を持つサービスプリンシパルの利用
シークレットの作成、変更、削除
失敗後に成功している認証イベント

不審なトークン発行が確認された場合は、シークレット交換だけでなく、既発行トークンやセッションの失効、ロールとスコープの見直し、RabbitMQ側の操作履歴調査も行います。

OAuth構成そのものを見直す

RabbitMQ公式ドキュメントでは、Management UIはOAuth 2.0上の公開クライアントに相当し、通常はクライアントシークレットを安全に保持できないため、基本的にシークレットを必要としない構成が推奨されています。一部のIDプロバイダーではトークン更新などのためにシークレットが必要となる場合がありますが、すべての環境で必須というわけではありません。(RabbitMQ)

更新後は、IDプロバイダーの仕様を確認し、次の見直しを検討してください。

クライアントシークレットを不要にできないか
公開クライアントとして登録できないか
クライアントに付与したロールやスコープを削減できないか
管理者権限と閲覧権限を分離できないか
管理UIをインターネットへ公開する必要があるか
管理アクセスをVPNや踏み台経由へ限定できないか
シークレットを設定ファイルへ直接記載せず、安全に注入できないか
シークレットの有効期限と定期交換を設定できないか
IDプロバイダーの異常検知やアラートを有効化できないか

脆弱性対応を「RPMを更新して終了」とせず、漏えいした場合の権限を小さくする設計まで見直すことで、同種の問題が発生した際の被害を抑えられます。

よくある疑問

OAuth 2.0を使っていなければ影響はないのか

RabbitMQの上流アドバイザリでは、OAuth 2.0を使用していない環境や、management.oauth_client_secretを使用しない別のOAuth構成は影響を受けないとされています。

ただし、現在は使用していなくても、過去の設定が残っている場合があります。設定ファイルだけでなく、実際に読み込まれている有効な設定を確認してください。(GitHub)

Management UIが社内限定なら更新しなくてもよいか

更新は必要です。社内限定は到達可能な攻撃者を減らす対策であり、脆弱性そのものを解消しません。

侵害済み端末、VPN利用者、内部不正、誤ったネットワークルールなどからアクセスされる可能性があります。修正版への更新を先送りする理由にはなりません。

HTTPSを使っていればシークレットは漏れないのか

HTTPSは通信経路を暗号化しますが、CVE-2026-57219はRabbitMQがHTTPレスポンスとしてシークレットを返す問題です。

攻撃者自身がHTTPSで管理APIへ接続した場合、RabbitMQと攻撃者の間の通信は正常に暗号化されます。したがって、TLSを有効にしているだけでは防げません。

上流の修正版3.13.15へ更新する必要があるのか

Azure Linux 3.0のMicrosoft提供RPMを使用している場合は、MSRCが示す3.13.7-7.azl3以降を基準にします。

上流版、Microsoft提供RPM、独自ビルド、コンテナーイメージを混同しないことが重要です。独自にRabbitMQを導入している場合は、使用している配布元のアドバイザリと修正版を確認してください。

パッケージ更新だけで対応は完了するのか

脆弱な管理APIへ過去に到達できなかったと確実に証明できる場合は、更新が中心となります。

外部公開していた、ログが不足している、公開範囲が不明、または不審なアクセスがある場合は、更新後にシークレットを交換し、IDプロバイダーと管理APIのログを調査してください。

対応時に避けたい失敗

CVE-2026-57219の対応では、次の失敗が起こりやすいため注意が必要です。

RPMの更新後にRabbitMQを再起動していない
バージョン番号の3.13.7だけを見て修正状況を判断する
上流版の3.13.15とAzure LinuxのRPMリリースを混同する
/api/authを直接呼び出してシークレットを画面へ表示する
リバースプロキシだけを制限し、管理ポートへの直接経路を残す
脆弱性を閉じる前に新しいシークレットへ交換する
旧シークレットを失効させず残しておく
Management UIのログイン確認だけで、AMQP通信やクラスタ状態を確認しない
1台だけ更新し、クラスタ内に脆弱なノードを残す
コンテナー内のRabbitMQをホストOSの更新だけで修正したと判断する
ログがないことを「悪用なし」の証拠として扱う

まとめ

CVE-2026-57219は、特定のOAuth 2.0構成を使用するRabbitMQで、未認証の相手にクライアントシークレットが漏えいする可能性がある脆弱性です。

Azure Linux 3.0でrabbitmq-server-3.13.7-6.azl3を使用している場合は、次の順番で対応します。

rabbitmq-serverのRPMバージョンを確認する
rabbitmq_managementとOAuth設定を確認する
管理APIの外部到達性を確認する
3.13.7-7.azl3以降へ更新する
RabbitMQを再起動し、クラスタとアプリケーションを確認する
過去に管理APIへ到達できた場合はシークレットを交換する
IDプロバイダーとWebアクセスのログを調査する
可能であればクライアントシークレットを不要とする構成へ見直す

最も危険なのは、管理画面が表示されていないことだけを理由に安全と判断することです。パッケージ、設定、プラグイン、ネットワーク経路の4点を確認し、修正版の適用と認証情報の事後対応を分けて進めてください。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

CVE-2026-57219対策：Azure Linux 3.0のRabbitMQ OAuth資格情報漏えいを修正する方法

CVE-2026-57219の概要

CVE-2026-57219で何が漏えいするのか

影響を受ける環境の条件

Azure Linux 3.0で影響を確認する手順

OSとRabbitMQのバージョンを確認する

管理プラグインとOAuthプラグインを確認する

実際に読み込まれている設定ファイルを確認する

シークレットの値を表示せずに設定有無を調べる

管理APIの待受ポートと公開範囲を確認する

CVE-2026-57219を修正する手順

更新前に確認する項目

rabbitmq-serverを更新する

RabbitMQを再起動して修正版を読み込む

クラスタでは1ノードずつ更新する

更新できない場合の一時的な対応

OAuthクライアントシークレットを交換すべきケース

シークレット交換の正しい順番

漏えいの有無を調査するポイント

ネットワークとWebアクセスログ

IDプロバイダーのログ

OAuth構成そのものを見直す

よくある疑問

OAuth 2.0を使っていなければ影響はないのか

Management UIが社内限定なら更新しなくてもよいか

HTTPSを使っていればシークレットは漏れないのか

上流の修正版3.13.15へ更新する必要があるのか

パッケージ更新だけで対応は完了するのか

対応時に避けたい失敗

まとめ

この記事を書いた人

コメント

コメントするコメントをキャンセル

CVE-2026-57219対策：Azure Linux 3.0のRabbitMQ OAuth資格情報漏えいを修正する方法

CVE-2026-57219の概要

CVE-2026-57219で何が漏えいするのか

影響を受ける環境の条件

Azure Linux 3.0で影響を確認する手順

OSとRabbitMQのバージョンを確認する

管理プラグインとOAuthプラグインを確認する

実際に読み込まれている設定ファイルを確認する

シークレットの値を表示せずに設定有無を調べる

管理APIの待受ポートと公開範囲を確認する

CVE-2026-57219を修正する手順

更新前に確認する項目

rabbitmq-serverを更新する

RabbitMQを再起動して修正版を読み込む

クラスタでは1ノードずつ更新する

更新できない場合の一時的な対応

OAuthクライアントシークレットを交換すべきケース

シークレット交換の正しい順番

漏えいの有無を調査するポイント

ネットワークとWebアクセスログ

IDプロバイダーのログ

OAuth構成そのものを見直す

よくある疑問

OAuth 2.0を使っていなければ影響はないのか

Management UIが社内限定なら更新しなくてもよいか

HTTPSを使っていればシークレットは漏れないのか

上流の修正版3.13.15へ更新する必要があるのか

パッケージ更新だけで対応は完了するのか

対応時に避けたい失敗

まとめ

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル