CVE-2026-57213対策：RabbitMQ Federationのstored XSSと修正版3.13.7-7

Azure Linux 3.0でrabbitmq-server 3.13.7-6を利用している場合、CVE-2026-57213の影響を受ける可能性があります。これは、RabbitMQ Federationの管理画面でconsumer_tagが適切にHTMLエスケープされず、管理者や監視担当者のブラウザー上で不正なJavaScriptが実行されるstored XSSです。

結論として、Azure Linux 3.0のrabbitmq-serverを3.13.7-7以上へ更新してください。MSRCは個別の回避策を示していないため、管理画面のアクセス制限やプラグインの一時停止だけで対応完了とは判断できません。Azure Linuxでは上流のRabbitMQバージョンを変更せず、修正をRPMへバックポートしているため、確認時は3.13.7だけでなく、RPMのリリース番号である-7まで見ることが重要です。(マイクロソフトセキュリティ応答センター)

CVE-2026-57213の概要と修正版

項目	内容
CVE番号	CVE-2026-57213
脆弱性の種類	格納型クロスサイトスクリプティング、stored XSS
CWE	CWE-79
影響する機能	`rabbitmq_federation_management`のFederation Status画面
問題となる入力	Federation upstreamに設定された`consumer-tag`
Azure Linux 3.0の影響パッケージ	`rabbitmq-server-3.13.7-6.azl3`
Azure Linux 3.0の修正版	`rabbitmq-server-3.13.7-7.azl3`以上
上流RabbitMQ 3.13系の修正版	3.13.14
CVSS	CVSS v4.0で5.7、Medium
攻撃に必要な権限	Federation upstreamまたはpolicyを設定できる高い権限
被害発生に必要な操作	管理者や監視担当者がFederation Status画面を表示する
MSRCの個別回避策	掲載なし

上流のRabbitMQでは、3.13.0以上3.13.14未満、4.0.0以上4.0.19未満、4.1.0以上4.1.10未満、4.2.0以上4.2.5未満が影響対象です。Azure Linux 3.0では3.13.7を維持したまま修正をバックポートし、RPMのリリース番号を-6から-7へ上げています。(GitHub)

このため、次のような確認は不十分です。

rabbitmqctl version

このコマンドで3.13.7と表示されても、Azure Linux向け修正が適用済みかは分かりません。必ずrpmコマンドでVERSION-RELEASEを確認してください。

RabbitMQ Federationでstored XSSが発生する仕組み

consumer-tagは、Federationがupstreamからメッセージを受信するときに使用するコンシューマー識別子です。RabbitMQ Federationでは任意設定のパラメーターとして扱われます。(RabbitMQ)

CVE-2026-57213では、次の流れで攻撃が成立します。

攻撃者がFederation upstreamまたは関連するpolicyを設定する
consumer-tagへHTMLやJavaScriptとして解釈される文字列を保存する
その値がFederationのステータス情報へそのまま含まれる
Federation Status画面が値をHTMLエスケープせずに表示する
管理者や監視担当者が画面を開くと、ブラウザー上でJavaScriptが実行される

入力時に実行されるのではなく、データとして保存された後、別の利用者が管理画面を表示した時点で実行されるため「stored XSS」と呼ばれます。上流アドバイザリでは、consumer_tagがステータスAPIまで未加工で渡され、管理画面のテンプレートで安全な文字列変換を行わずに描画されていたことが原因として説明されています。(GitHub)

想定される影響

不正なJavaScriptは、RabbitMQ管理画面を表示している利用者のブラウザーで実行されます。上流アドバイザリでは、管理セッションに関連する情報の窃取、CSRFとの組み合わせ、管理画面を介した不正操作などが影響として挙げられています。(GitHub)

ただし、この脆弱性自体をRabbitMQホスト上で直接コードを実行するRCEと同一視すべきではありません。主な攻撃対象は管理画面を開くブラウザーと、その利用者が持つ管理権限です。

一方で、管理者権限が奪われれば、ユーザー、権限、policy、parameter、接続などに影響が及ぶ可能性があります。CVSSが5.7であっても、管理画面を広いネットワークから利用できる環境や、管理権限を多数の利用者へ付与している環境では優先度を上げるべきです。

自分の環境が影響を受けるか確認する

Azure LinuxとRPMのバージョンを確認する

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

cat /etc/os-release

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

判断基準は次のとおりです。

確認結果	判断
`rabbitmq-server-3.13.7-6.azl3...`	影響対象。更新が必要
`rabbitmq-server-3.13.7-7.azl3...`	Azure Linux向け修正済み
`3.13.7-8`など`-7`より新しいリリース	通常は修正を含むが、配布元の変更履歴も確認する
パッケージが見つからない	ソース導入、別RPM、コンテナなどを個別確認
Azure Linux以外のRabbitMQ 3.13.0～3.13.13	上流の影響範囲として確認が必要

Azure Linuxの修正PRでは、修正前の3.13.7-6.azl3と、修正を含む3.13.7-7.azl3が明示されています。(GitHub)

対象プラグインが有効か確認する

有効なRabbitMQプラグインを名前だけで一覧表示します。

sudo rabbitmq-plugins list -e -m

関連プラグインだけを抽出する場合は、次のように実行します。

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

特に確認するプラグインは次の3つです。

rabbitmq_management
rabbitmq_federation
rabbitmq_federation_management

rabbitmq-plugins list -eは、明示的または依存関係によって有効になっているプラグインを表示します。RabbitMQの公式ドキュメントでも、Federationを管理画面から扱う場合はrabbitmq_federation_managementを有効にする構成が案内されています。(RabbitMQ)

rabbitmq_federation_managementが現在無効であれば、問題の表示経路へ到達する可能性は下がります。ただし、将来有効化される可能性や、脆弱なパッケージが残り続けることを考慮し、更新対象から除外しないでください。

Federationの設定と権限を確認する

まずユーザーとタグを確認します。

sudo rabbitmqctl list_users

特に、次のタグを持つユーザーを確認してください。

policymaker
administrator

policymakerは、アクセス可能な仮想ホストのpolicyやparameterを作成・削除できます。administratorにはpolicymaker相当の権限も含まれます。攻撃者側の条件を調べる場合は、この2種類のタグを持つユーザーと、各仮想ホストへのアクセス権を重点的に確認します。(RabbitMQ)

仮想ホストを一覧表示します。

sudo rabbitmqctl list_vhosts name

各仮想ホストについて、Federation upstreamを含むparameterとpolicyを確認します。

sudo rabbitmqctl list_parameters -p <vhost>
sudo rabbitmqctl list_policies -p <vhost>

Federationリンクの現在の状態をJSONで確認する場合は、次のコマンドを使用できます。

sudo rabbitmqctl federation_status --formatter=json

consumer_tagに、業務上不要なHTMLタグ、イベントハンドラーのような文字列、スクリプトを意図した不自然な記述がないか確認します。疑わしい値を見つけた場合は、すぐに削除する前に設定、ログ、操作日時などの証跡を保存してください。

管理画面の公開範囲を確認する

リスナーの状態を確認します。

sudo rabbitmq-diagnostics listeners

RabbitMQ管理画面では通常15672番ポートが使われますが、HTTPS化や構成変更により別ポートの場合もあります。ポート番号だけでなく、待ち受けアドレス、ロードバランサー、リバースプロキシ、ファイアウォール、VPN経由のアクセス経路まで確認してください。RabbitMQの管理UIとHTTP APIは、ユーザータグと認証によってアクセス制御されます。(RabbitMQ)

Azure Linux 3.0で3.13.7-7へ更新する手順

更新前に確認する項目

本番環境では、パッケージ更新だけでなくRabbitMQプロセスの再起動を伴う可能性があります。事前に次の項目を確認します。

RabbitMQクラスタを構成する全ノード
quorum queue、classic queue、streamの配置と冗長性
アプリケーションの自動再接続設定
未処理メッセージ数と処理遅延
Federationリンクの稼働状態
設定ファイル、定義情報、認証情報のバックアップ方法
障害時の切り戻し手順
更新対象リポジトリで3.13.7-7以上が取得できること

定義情報をエクスポートする場合、Federation upstreamの接続情報など機密性のある値が含まれる可能性があります。保存先の権限と削除時期も決めておきましょう。

パッケージを更新する

リポジトリのキャッシュを消去し、候補パッケージを確認します。

sudo tdnf clean all
sudo tdnf list rabbitmq-server

3.13.7-7以上が表示されることを確認してから更新します。

sudo tdnf upgrade rabbitmq-server

Azure Linux 3.0ではtdnfがパッケージ管理に使われ、パッケージのアップグレードにはtdnf upgradeを利用できます。(Microsoft Learn)

更新後、RPMの完全なバージョンを確認します。

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

期待する出力例は次のとおりです。

rabbitmq-server-3.13.7-7.azl3.x86_64

RabbitMQを再起動して正常性を確認する

単一ノード環境では、保守時間内にサービスを再起動します。

sudo systemctl restart rabbitmq-server
sudo systemctl --no-pager --full status rabbitmq-server
sudo rabbitmq-diagnostics ping
sudo rabbitmqctl cluster_status

続けてFederationリンクを確認します。

sudo rabbitmqctl federation_status --formatter=json

クラスタ環境では全ノードを同時に停止せず、原則として1ノードずつ更新します。各ノードの復帰、キューの可用性、クライアントの再接続、Federationリンクの復旧を確認してから次のノードへ進んでください。

管理プラグインが有効なクラスタでは、いずれかの管理ノードからクラスタ全体の情報へアクセスできます。1台だけを更新して完了とせず、対象クラスタの全ノードについてRPMのリリース番号を確認する必要があります。(RabbitMQ)

3.13.7-7が表示されない場合

修正版が候補に表示されないときは、次を確認します。

sudo tdnf clean all
sudo tdnf makecache
sudo tdnf list available rabbitmq-server

あわせて、リポジトリ設定、プロキシ、ミラーの同期状況、パッケージを固定するversion lockや独自リポジトリの有無を確認してください。

Azure Linuxの修正PRがマージ済みでも、組織内ミラーや閉域リポジトリへの反映には別の同期処理が必要な場合があります。出所の不明なRPMをインターネット上から個別に取得して適用するのではなく、信頼しているAzure Linuxリポジトリへ修正版を取り込んでください。

コンテナでRabbitMQを動かしている場合の注意点

RabbitMQがコンテナ内で動いている場合、ホスト側のRPMを確認しても判定できません。実際に稼働しているコンテナ内で確認します。

Dockerの例です。

docker exec <container-name> \
  rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' rabbitmq-server

Kubernetesの例です。

kubectl exec -n <namespace> <pod-name> -- \
  rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' rabbitmq-server

修正時は稼働中のコンテナへ直接パッケージを追加するのではなく、ベースイメージやDockerfileを更新し、新しいイメージをビルドして再デプロイします。複数のPodや古いReplicaSetに3.13.7-6が残っていないことも確認してください。

修正版を適用できるまでの暫定的なリスク低減策

MSRCはCVE-2026-57213に対する個別の回避策を掲載していません。次の対応は攻撃経路を狭めるための補助策であり、3.13.7-7以上への更新を置き換えるものではありません。(マイクロソフトセキュリティ応答センター)

暫定対応	期待できる効果	注意点
管理画面をVPNや管理ネットワークに限定	被害者となる管理利用者と攻撃経路を限定	内部ユーザーによる悪用は防げない
不要な`policymaker`、`administrator`を削除	不正なupstreamやpolicyを保存できる利用者を減らす	業務影響を確認してから変更する
不要なら`rabbitmq_federation_management`を無効化	脆弱なFederation管理画面の表示経路を停止	Federationの監視・管理手順が変わる
Federation Status画面を開かない	画面表示による実行を一時的に避ける	誤操作や監視担当者のアクセスを完全には防げない
管理専用ブラウザーや端末を分離	他システムへの影響拡大を抑えやすくする	根本的な修正にはならない

管理画面が不要な環境では、影響を確認したうえで管理拡張プラグインの一時停止を検討できます。

sudo rabbitmq-plugins disable rabbitmq_federation_management

ただし、プラグイン停止後もFederationの監視方法、HTTP APIを利用するツール、運用手順への影響を確認してください。

更新後に実施する侵害確認

修正は管理画面でconsumer_tagを安全に表示するためのエスケープ処理です。そのため、更新前に保存された不審な値が設定データから自動的に削除されるとは限りません。修正後もparameter、policy、Federation statusを確認する必要があります。(GitHub)

確認する項目は次のとおりです。

Federation upstreamに不審なconsumer-tagがないか
覚えのないupstream、upstream set、policyがないか
policymakerやadministratorタグが不要なユーザーへ付いていないか
管理画面やHTTP APIへの不審なアクセスがないか
更新前にFederation Status画面を開いた管理者がいないか
OAuthトークンや管理資格情報に異常がないか
全ノード、全コンテナ、待機系環境が修正版になっているか

不審な設定やアクセスが見つかった場合は、証跡を保存したうえで、該当upstreamやpolicyの削除、管理資格情報の変更、OAuthトークンの失効、関連する管理操作の確認を行います。

対応時に起きやすい判断ミス

RabbitMQの表示が3.13.7なので更新済みと判断する

Azure Linuxでは上流バージョンを3.13.7のまま維持し、RPMリリース-7へ修正をバックポートしています。rabbitmqctl versionだけでは判定できません。

rpm -q rabbitmq-server

この結果で3.13.7-7.azl3以上を確認してください。

Federationを使っていないので何もしない

現在プラグインが無効なら、直接的な悪用可能性は低下します。しかし、構成変更や復旧作業で将来有効化される可能性があります。脆弱なRPMを資産として残さず、通常の更新対象に含めるべきです。

管理画面がインターネット非公開なので安全と判断する

攻撃者にはFederation upstreamやpolicyを設定できる権限が必要ですが、内部アカウントの侵害や過剰な権限付与でも条件を満たす可能性があります。外部公開の有無だけで対象外にはできません。

1台だけ更新してクラスタ対応を完了する

古いパッケージのノードで管理プラグインが稼働していれば、脆弱な表示処理が残ります。ロードバランサーの配下、待機系、災害対策環境も含めて確認してください。

CVE-2026-57213への対応を完了するための手順

CVE-2026-57213への対応は、次の順番で進めると漏れを防げます。

Azure Linux 3.0のRabbitMQノードとコンテナをすべて洗い出す
rpm -qで3.13.7-6か3.13.7-7以上かを確認する
rabbitmq_federation_managementの有効状態を確認する
Federation upstream、policy、権限ユーザーを調査する
rabbitmq-server 3.13.7-7以上へ更新する
RabbitMQを計画的に再起動し、クラスタとFederationの状態を確認する
不審なconsumer-tagや管理操作がないか確認する
全ノードと全コンテナのRPMリリース番号を再確認する

対応完了の基準は、単にサービスが起動したことではありません。全対象でrabbitmq-server-3.13.7-7.azl3以上が確認でき、Federationリンクとアプリケーション接続が正常で、不審な保存データがないことまで確認してください。

この記事を書いた人

佐藤健司

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

CVE-2026-57213対策：RabbitMQ Federationのstored XSSと修正版3.13.7-7

CVE-2026-57213の概要と修正版

RabbitMQ Federationでstored XSSが発生する仕組み

想定される影響

自分の環境が影響を受けるか確認する

Azure LinuxとRPMのバージョンを確認する

対象プラグインが有効か確認する

Federationの設定と権限を確認する

管理画面の公開範囲を確認する

Azure Linux 3.0で3.13.7-7へ更新する手順

更新前に確認する項目

パッケージを更新する

RabbitMQを再起動して正常性を確認する

3.13.7-7が表示されない場合

コンテナでRabbitMQを動かしている場合の注意点

修正版を適用できるまでの暫定的なリスク低減策

更新後に実施する侵害確認

対応時に起きやすい判断ミス

RabbitMQの表示が3.13.7なので更新済みと判断する

Federationを使っていないので何もしない

管理画面がインターネット非公開なので安全と判断する

1台だけ更新してクラスタ対応を完了する

CVE-2026-57213への対応を完了するための手順

この記事を書いた人

コメント

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

CVE-2026-57213対策：RabbitMQ Federationのstored XSSと修正版3.13.7-7

CVE-2026-57213の概要と修正版

RabbitMQ Federationでstored XSSが発生する仕組み

想定される影響

自分の環境が影響を受けるか確認する

Azure LinuxとRPMのバージョンを確認する

対象プラグインが有効か確認する

Federationの設定と権限を確認する

管理画面の公開範囲を確認する

Azure Linux 3.0で3.13.7-7へ更新する手順

更新前に確認する項目

パッケージを更新する

RabbitMQを再起動して正常性を確認する

3.13.7-7が表示されない場合

コンテナでRabbitMQを動かしている場合の注意点

修正版を適用できるまでの暫定的なリスク低減策

更新後に実施する侵害確認

対応時に起きやすい判断ミス

RabbitMQの表示が3.13.7なので更新済みと判断する

Federationを使っていないので何もしない

管理画面がインターネット非公開なので安全と判断する

1台だけ更新してクラスタ対応を完了する

CVE-2026-57213への対応を完了するための手順

この記事を書いた人

関連記事

コメント

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

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