CVE-2026-57217対策：Azure Linux 3.0のRabbitMQを3.13.7-7へ更新

Azure Linux 3.0でrabbitmq-server-3.13.7-6.azl3を使用している場合は、修正版の3.13.7-7以上へ更新する必要があります。CVE-2026-57217は、RabbitMQのtopic認可処理がメタデータストアのエラーを正しく区別できず、本来拒否されるrouting keyへのpublishやbindを許可する可能性がある脆弱性です。

特に対応を急ぐべきなのは、Khepriをメタデータストアとして使用し、同じ仮想ホストやtopic exchangeを複数テナントで共有しながら、正規表現によるtopic permissionでテナントを分離している環境です。RabbitMQ側の評価はHigh、CVSS v4.0の基本値は7.0です。MSRCでは個別の回避策が示されていないため、設定変更だけで済ませず、パッケージ更新を正式な対策としてください。(Microsoft セキュリティ応答センター)

なお、Azure Linux版ではRabbitMQ本体のバージョン番号が更新前後とも「3.13.7」のままです。rabbitmqctl versionだけでは修正済みか判断できません。RPMのRelease番号が-7以上になっていることを確認するのが重要です。

CVE-2026-57217の概要と影響範囲

項目	内容
CVE番号	CVE-2026-57217
対象	Azure Linux 3.0のrabbitmq-server
影響を受けるパッケージ	rabbitmq-server-3.13.7-6.azl3
修正版	rabbitmq-server-3.13.7-7.azl3以上
脆弱性の種類	RabbitMQ topic認可のフェイルオープン
主な発生条件	Khepriのtopic permission照会でタイムアウトやエラーが発生すること
想定される影響	許可されていないrouting keyへのpublishまたはbind
攻撃に必要な権限	RabbitMQへ接続できる認証済み低権限ユーザー
公式の個別回避策	掲載なし。修正版への更新が必要

RabbitMQのアップストリームでは、3.13系の影響範囲を3.13.0以上3.13.15未満とし、3.13.15を修正版としています。一方、Azure Linux 3.0は修正コードを3.13.7へバックポートしているため、Azure LinuxのRPMを利用している環境では3.13.7-7.azl3が修正済みパッケージです。(GitHub)

この違いを理解せず、「RabbitMQ 3.13.15ではないから未修正」と判断したり、逆に「3.13.7と表示されているから全ノード同じ状態」と判断したりしないよう注意してください。

RabbitMQのtopic認可バイパスはなぜ発生するのか

topic permissionはrouting keyを制限する仕組み

RabbitMQでは、仮想ホストへのアクセス許可やexchange、queueに対するconfigure、write、read権限に加えて、topic exchangeのrouting keyを制限するtopic permissionを設定できます。

例えば、テナントAに次のような書き込み許可を設定したとします。

^tenant-a\..*

この場合、通常は次のように判定されます。

routing key	期待される結果
tenant-a.orders.created	許可
tenant-a.users.updated	許可
tenant-b.orders.created	拒否
internal.audit.security	拒否

RabbitMQのtopic認可は、routing keyを設定済みの正規表現と照合する追加の認可層です。AMQP 0-9-1ではtopic exchangeへのpublishやbind、MQTTやSTOMPではトピックへのアクセス制御に関係します。(RabbitMQ)

エラーが「topic permissionなし」と誤認される

問題は、topic permissionをKhepriから読み込む処理にあります。

脆弱な処理では、Khepriからtopic permissionを取得できなかった際、次の二つの状態が同じundefinedとして扱われていました。

1. 対象ユーザーにtopic permissionが設定されていない
2. Khepriへの照会がタイムアウトまたはエラーになった

RabbitMQの標準認可バックエンドは、topic permissionが設定されていない場合、通常のリソース権限を通過していればtopic操作を許可します。そのため、本来は認可処理を中断すべきKhepriのエラーまで「topic permissionなし」と誤認され、許可扱いになることがありました。

つまり、通常時には拒否されるrouting keyでも、Khepriの照会エラーが発生している短い時間だけ許可される可能性があります。これは、認可基盤が異常になったときに安全側へ拒否するフェイルクローズではなく、許可側へ倒れるフェイルオープンです。(GitHub)

修正版では、次の状態を区別します。

Khepriの応答	修正版の処理
topic permissionが見つかった	正規表現でrouting keyを判定
対象キーが存在しない	topic permission未設定として処理
タイムアウトやその他のエラー	エラーを認可処理へ返し、暗黙に許可しない

Azure Linuxの修正パッチでは、Khepriのnode_not_foundだけを「設定なし」と扱い、それ以外のエラーは認可バックエンドへ伝播するよう変更されています。(GitHub)

クロステナントのrouting-keyバイパスにつながる条件

CVE-2026-57217は、RabbitMQへ接続できない外部ユーザーが無条件で悪用できる脆弱性ではありません。主に次の条件が重なった環境で問題になります。

• 攻撃者がRabbitMQへ接続可能な有効な認証情報を持っている
• Khepriをメタデータストアとして使用している
• topic permissionでrouting keyをテナントごとに制限している
• 複数テナントが同じ仮想ホストまたはtopic exchangeを共有している
• Khepriへのtopic permission照会でタイムアウトやエラーが発生する

この状態では、低権限ユーザーが自分に許可された正規表現の範囲外へpublishしたり、許可されていないrouting keyでqueueやexchangeをbindしたりする可能性があります。RabbitMQのアドバイザリでは、共有topic exchangeにおけるテナント境界の逸脱と、機密性への高い影響が示されています。(GitHub)

RabbitMQ 3.13におけるKhepriは、Mnesiaを将来的に置き換えるために導入された実験的なメタデータストアです。そのため、3.13.7を使っていてもKhepriを有効化していない環境では、今回説明されているKhepri照会エラーの経路は通常利用されません。ただし、パッケージ自体に脆弱なコードが含まれていることに変わりはないため、将来の構成変更も考慮して修正版へ更新してください。(RabbitMQ)

自社環境が影響を受けるか確認する手順

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

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

cat /etc/os-release

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

出力の判断例は次のとおりです。

出力例	判断
rabbitmq-server-3.13.7-6.azl3.x86_64	CVE-2026-57217の修正前
rabbitmq-server-3.13.7-7.azl3.x86_64	修正済み
rabbitmq-server-3.13.7-8.azl3.x86_64	-7より新しいため修正を含むと判断可能
package rabbitmq-server is not installed	そのホストにはRPM版RabbitMQが未導入
Azure Linux以外のパッケージ	利用元ディストリビューションのアドバイザリを確認

アーキテクチャによって末尾はx86_64やaarch64などに変わります。重要なのは、3.13.7の後にあるRPMのRelease番号です。

次のコマンドだけでは、今回の修正状態を判別できません。

sudo rabbitmqctl version

3.13.7-6と3.13.7-7はどちらもRabbitMQ本体としては3.13.7であるため、上記コマンドでは両方とも3.13.7と表示される可能性があります。Azure LinuxのSPECでは、CVE-2026-57217のパッチがRelease 7で追加されています。(GitHub)

Khepriが有効か確認する

RabbitMQのfeature flagを確認します。

sudo rabbitmqctl list_feature_flags | grep khepri_db

出力形式は環境によって異なりますが、khepri_dbが有効と表示される場合は、今回の脆弱性が問題になるメタデータストア構成です。

利用できる環境では、次の診断コマンドでもメタデータストアの状態を確認します。

sudo rabbitmq-diagnostics metadata_store_status

grepで何も表示されない場合は、念のため全feature flagを確認してください。

sudo rabbitmqctl list_feature_flags

本番環境でKhepriを使用している場合は、単に有効かどうかだけでなく、クラスタの過半数喪失、ノード間通信、ディスク遅延、タイムアウトなど、メタデータ照会が不安定になる要因も確認します。

topic permissionの使用状況を確認する

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

sudo rabbitmqctl list_vhosts name

各仮想ホストについてtopic permissionを確認します。

sudo rabbitmqctl list_topic_permissions -p "<vhost>"

デフォルトの仮想ホストを確認する場合は、次のように実行します。

sudo rabbitmqctl list_topic_permissions -p "/"

必要に応じて、通常のリソース権限とbindingも確認します。

sudo rabbitmqctl list_permissions -p "<vhost>"

sudo rabbitmqctl list_bindings -p "<vhost>"

list_topic_permissionsにユーザー、exchange、write用正規表現、read用正規表現が表示される環境は、topic認可を利用しています。これらのコマンドはRabbitMQの公式CLIで提供されています。(RabbitMQ)

topic permissionが一件も設定されていない場合、標準の認可バックエンドではtopic認可自体がオプトインされていない状態です。この場合、今回の「設定済みのtopic permissionをKhepriエラー時に迂回する」という影響条件には合致しにくくなります。ただし、通常のexchangeやqueueに対するリソース権限が安全であることを別途確認し、パッケージ更新も実施してください。(RabbitMQ)

テナントの分離方法を確認する

次の構成では優先度を高くします。

構成	対応優先度
3.13.7-6、Khepri有効、topic permissionあり、共有topic exchangeあり	最優先で更新
3.13.7-6、Khepri有効、topic permissionあり、単一テナント	早急に更新
3.13.7-6、Khepri有効、topic permissionなし	更新が必要。通常のリソース権限も確認
3.13.7-6、Khepri未使用	説明されている攻撃経路の可能性は低いが更新が必要
テナントごとに仮想ホストを完全分離	クロステナントの影響範囲は縮小するが更新が必要
3.13.7-7以上	CVE-2026-57217は修正済み

仮想ホストはRabbitMQの主要なアクセス境界です。同じ名前のexchangeやqueueでも、異なる仮想ホストに存在すれば別リソースとして扱われます。複数テナントを同じ仮想ホストへ収容し、routing keyの正規表現だけで分離している環境は、今回の問題の影響を受けやすい構成です。(RabbitMQ)

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

更新前にクラスタ状態を確認する

更新作業の前に、RabbitMQが正常な状態であることを確認します。

sudo rabbitmq-diagnostics -q check_running
sudo rabbitmq-diagnostics -q check_alarms
sudo rabbitmqctl cluster_status

アラームが発生している、クラスタノードが停止している、queue replicaの同期が完了していない、大量のメッセージ滞留があるといった状態で、そのまま更新を開始しないでください。

定義情報を退避する場合は、次のようにエクスポートできます。

BACKUP_FILE="/var/tmp/rabbitmq-definitions-$(date +%Y%m%d-%H%M%S).json"

sudo rabbitmqctl export_definitions "$BACKUP_FILE"
sudo chmod 600 "$BACKUP_FILE"

definitionsには仮想ホスト、ユーザー、権限、exchange、queue、binding、policyなどが含まれます。ただし、queue内のメッセージそのものをバックアップするものではありません。また、認証関連情報を含む可能性があるため、出力ファイルを一般ユーザーが読める状態で放置しないでください。

単一ノード構成では、RabbitMQの再起動中に接続できない時間が発生します。クラスタ構成では、バージョン互換性、feature flag、アラーム、レプリカ同期を確認したうえで、原則として1ノードずつ更新します。RabbitMQの公式アップグレードガイドでも、ローリングアップグレードはノードを順番に停止、更新、起動し、各段階で健全性を確認する方法として案内されています。(RabbitMQ)

tdnfで修正版を取得する

Azure Linux 3.0では、パッケージ管理にtdnfを使用します。

まず、現在のパッケージとリポジトリ上の候補を確認します。

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

sudo tdnf clean all
sudo tdnf list rabbitmq-server

候補として3.13.7-7.azl3以上が表示されることを確認したら、RabbitMQを更新します。

sudo tdnf upgrade -y rabbitmq-server

環境によってはupdateサブコマンドでも更新できます。

sudo tdnf update -y rabbitmq-server

Azure Linuxではrpmによるインストール済みパッケージの確認、tdnf clean allによるキャッシュ削除、tdnf listによる候補確認、tdnf upgradeによる更新が利用できます。(Microsoft Learn)

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

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

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

rabbitmq-server-3.13.7-7.azl3.x86_64

tdnf upgradeが正常終了していても、出力が3.13.7-6.azl3のままなら対策完了ではありません。次の点を確認してください。

• 社内パッケージミラーが最新状態まで同期されているか
• Azure Linux 3.0用の正しいリポジトリが有効か
• プロキシやファイアウォールでリポジトリ通信が遮断されていないか
• バージョン固定や除外設定が行われていないか
• コンテナーやイメージビルド時の古いキャッシュを参照していないか

RabbitMQを再起動する

更新したコードを実行中のRabbitMQへ確実に反映させるため、運用手順に従ってサービスを再起動します。

sudo systemctl restart rabbitmq-server

クラスタ構成では全ノードを同時に再起動せず、1ノードごとに次の流れで進めます。

1. 対象ノードの状態とレプリカ配置を確認する
2. 対象ノードを更新して再起動する
3. ノードがクラスタへ復帰したことを確認する
4. アラームと同期状態を確認する
5. 問題がなければ次のノードへ進む

単にRPMを更新しただけで、古いRabbitMQプロセスを動かし続けないよう注意してください。

更新後の状態を検証する

サービスとRabbitMQの状態を確認します。

sudo systemctl is-active rabbitmq-server

sudo rabbitmq-diagnostics -q ping
sudo rabbitmq-diagnostics -q check_running
sudo rabbitmq-diagnostics -q check_alarms

sudo rabbitmqctl cluster_status

RabbitMQのrabbitmq-diagnosticsには、ノードへの接続確認、アプリケーション稼働確認、クラスタ内アラーム確認などの診断機能があります。(RabbitMQ)

更新完了の判断基準は次のとおりです。

確認項目	合格基準
RPMバージョン	全ノードが3.13.7-7.azl3以上
systemdサービス	active
RabbitMQアプリケーション	check_runningが成功
クラスタ	想定する全ノードが稼働
リソースアラーム	なし
アプリケーション接続	publisherとconsumerが再接続できる
通常のメッセージ配送	許可されたrouting keyで成功
拒否テスト	許可外のrouting keyが拒否される

ステージング環境または専用のテスト用exchangeとqueueを利用し、次のような境界テストを行うと確実です。

許可対象: tenant-a.orders.created
拒否対象: tenant-b.orders.created

許可対象は正常に配送され、拒否対象はACCESS_REFUSEDなどで拒否されることを確認します。実際の業務用queueへテストメッセージを混入させないよう、テスト専用の構成を使用してください。

RabbitMQはアクセス制御結果を接続またはチャネル単位でキャッシュする場合があります。権限設定を変更したうえでテストする場合は、既存のクライアント接続を切断し、新しい接続で確認してください。(RabbitMQ)

コンテナー環境ではイメージを再作成する

Azure Linuxベースのコンテナー内へRabbitMQをRPMで導入している場合、実行中コンテナー内だけでtdnf upgradeしても、コンテナー再作成時に元の脆弱なイメージへ戻る可能性があります。

Dockerfileやイメージビルド処理を更新し、修正版を含む新しいイメージを作成して再デプロイしてください。デプロイ後はコンテナー内で次のコマンドを実行し、実際に稼働しているイメージのRPMを確認します。

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

イメージタグやビルド日時だけを根拠に修正済みと判断しないことが重要です。

更新できない場合の暫定的なリスク低減策

MSRCではCVE-2026-57217に対する個別の回避策が示されていません。以下は正式な修正ではなく、更新までの間に攻撃対象と影響範囲を小さくするための補助策です。(Microsoft セキュリティ応答センター)

RabbitMQへ接続できる主体を限定する

AMQP、MQTT、STOMP、Management APIなどのポートを、実際に接続が必要なアプリケーションネットワークだけに限定します。

インターネットや広い社内ネットワークから直接アクセスできる場合は、ファイアウォール、NSG、ロードバランサー、Kubernetes NetworkPolicyなどを見直してください。

テナントごとに仮想ホストを分離する

routing keyの正規表現だけでテナントを分けるのではなく、可能であれば仮想ホストも分離します。より高い分離が必要な環境では、RabbitMQクラスタ自体をテナントや信頼境界ごとに分けることも検討します。

ただし、既存環境の仮想ホストを変更すると接続先URL、ユーザー権限、exchange、queue、binding、policyなどへの影響が生じます。緊急回避として無計画に変更せず、まず修正版への更新を優先してください。

共有topic exchangeを減らす

複数テナントが一つのtopic exchangeを共有し、routing keyのprefixだけで分離されている場合は、exchange分離の可否を確認します。

例えば、次の構成です。

共有exchange: events
tenant-aのrouting key: tenant-a.#
tenant-bのrouting key: tenant-b.#

更新までの間、不要なpublisherアカウントを停止する、利用していないbindingを削除する、テナント間で共有するexchangeを限定するといった対策で影響範囲を縮小できます。

Khepriのエラーを監視する

今回のバイパスには、Khepriへのtopic permission照会が失敗する時間帯が関係します。次のような状態を監視してください。

• Khepriのタイムアウト
• Raftメンバーの停止
• ノード間通信の遅延や切断
• ディスクI/Oの遅延
• RabbitMQノードの頻繁な再起動
• クラスタの過半数を維持できない状態

Khepriを無効化するためにfeature flagを本番環境で安易に操作することは避けてください。メタデータストアの変更は、認可設定だけでなくRabbitMQクラスタ全体へ影響する可能性があります。

topic permissionを削除しない

認可エラーを避ける目的でtopic permissionを削除するのは逆効果です。RabbitMQの標準認可バックエンドでは、topic permissionが設定されていない場合、topic認可の追加制限が適用されません。結果としてrouting keyの制限そのものを失う可能性があります。(RabbitMQ)

不正利用の可能性を調査する方法

CVE-2026-57217のバイパスは、Khepriの照会エラーが発生している時間だけ成立する可能性があります。正常時には同じ操作が拒否されるため、事後調査では「一時的なKhepri障害」と「想定外のrouting key操作」が同じ時間帯に発生していないかを確認します。(GitHub)

RabbitMQログからKhepri関連エラーを探す

systemd journalを使用している場合の例です。

sudo journalctl -u rabbitmq-server \
  --since "YYYY-MM-DD HH:MM:SS" \
  --until "YYYY-MM-DD HH:MM:SS" \
  | grep -Ei 'khepri|timeout|error|raft'

ログファイルへ直接出力している環境では、RabbitMQのログディレクトリとログ転送先も確認します。

調査対象には、次の時間帯を含めてください。

• RabbitMQノードが停止または再起動した時間
• ネットワーク障害が発生した時間
• ディスク遅延や容量不足が発生した時間
• KhepriやRaftに関するアラートが出た時間
• アプリケーション側でメッセージ誤配送が疑われた時間

topic permissionとbindingを確認する

現在の設定を保存します。

sudo rabbitmqctl list_topic_permissions -p "<vhost>" \
  > /var/tmp/topic-permissions.txt

sudo rabbitmqctl list_bindings -p "<vhost>" \
  > /var/tmp/bindings.txt

次のような状態がないか確認します。

• 管理台帳にないユーザーへtopic permissionが付与されている
• 正規表現が.*など過度に広い
• 他テナントのprefixを含むbindingが存在する
• 一時的な名称のqueueやexchangeが残っている
• 想定していないテナントのユーザーが同じ仮想ホストへ接続できる

アプリケーション側のログも確認する

RabbitMQの標準ログに、すべてのpublish内容やrouting keyが履歴として残るとは限りません。そのため、publisher、consumer、API Gateway、サービスメッシュ、監査基盤などのログも確認します。

特に次の兆候が重要です。

• テナントAのconsumerがテナントBのメッセージを受信している
• 通常利用しないrouting keyへのpublishがある
• 想定外のqueueへメッセージが配送されている
• 低権限ユーザーがbindingを作成している
• Khepri障害の直前または障害中に接続が集中している

不正利用が疑われる場合は、ログとdefinitionsを保全したうえで、対象アカウントの無効化または認証情報のローテーション、不要な接続の切断、想定外のbindingの隔離、下流システムでのデータ確認を行います。

3.13.15ではなく3.13.7-7でよい理由

RabbitMQアップストリームの修正版は3.13.15ですが、Azure Linux 3.0では、アップストリームの修正コードを3.13.7へ適用したバックポートパッケージが提供されています。

バージョンを分解すると、次の違いがあります。

rabbitmq-server-3.13.7-7.azl3.x86_64
                └────┘ └┘
                Version Release

• 3.13.7はRabbitMQ本体のVersion
• 7はAzure Linux RPMのRelease
• azl3はAzure Linux 3.0向けパッケージ

Azure LinuxのSPECでは、Release 7の変更履歴にCVE-2026-57217が明記され、専用の修正パッチも組み込まれています。したがって、Azure Linux公式RPMを使用している環境では、3.13.7-7.azl3以上が今回の受け入れ基準です。(GitHub)

一方、RabbitMQ公式配布物、別のLinuxディストリビューション、独自ビルド、コンテナーイメージを使用している場合は、Azure LinuxのRelease番号を基準にできません。それぞれの配布元が示す修正版、またはアップストリームの3.13.15、4.0.21、4.1.11、4.2.6以上を基準にしてください。(GitHub)

対策時に失敗しやすいポイント

失敗例	問題点	正しい対応
rabbitmqctl versionだけを確認する	-6と-7を区別できない	rpm -qでRelease番号まで確認
RPM更新後に再起動しない	実行中プロセスが古いコードのままになる可能性	計画的にRabbitMQを再起動
クラスタの1台だけ更新して終了する	他ノードに脆弱なパッケージが残る	全ノードを台帳化して確認
tdnfが正常終了したので修正済みと判断する	社内ミラーに-7がなく、更新されていない場合がある	更新後のRPM出力を確認
topic permissionを削除する	routing key制限そのものを失う可能性	permissionを維持してパッチ適用
Khepriのfeature flagを急に変更する	クラスタやメタデータへ別の障害を起こす可能性	ベンダー手順なしに変更しない
コンテナー内だけを更新する	再デプロイ時に脆弱なイメージへ戻る	イメージを再ビルドして配布
許可されるrouting keyだけをテストする	認可境界が機能しているか確認できない	許可と拒否の両方をテスト

まとめ：今すぐ実施すべきこと

CVE-2026-57217への対応では、まず全RabbitMQノードで次のコマンドを実行し、RPMのRelease番号を確認します。

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

rabbitmq-server-3.13.7-6.azl3が確認された場合は、tdnfで3.13.7-7.azl3以上へ更新し、RabbitMQを再起動してください。クラスタでは1ノードずつ作業し、最終的に全ノードが修正版になっていることを確認します。

あわせてKhepri、topic permission、共有topic exchange、仮想ホストの分離状況を確認します。特に、複数テナントをrouting keyの正規表現だけで分離している環境は、更新優先度を上げるべきです。

更新後は、RPMバージョン、クラスタ状態、アラーム、アプリケーション接続に加え、許可対象のrouting keyが成功し、許可対象外のrouting keyが確実に拒否されることまで検証してください。