CVE-2026-57215を解説：Azure Linux 3.0のRabbitMQを3.13.7-7へ更新

CVE-2026-57215は、RabbitMQのDirect Reply-toで不正なバインディングが残存し、認証済みユーザーによる返信チャネルへのメッセージ注入やルーティング異常につながる脆弱性です。Azure Linux 3.0でrabbitmq-server 3.13.7-6を使用している場合は、修正版の3.13.7-7以降へ更新することが結論です。MSRCでは個別の回避策が示されていないため、権限制限などの一時対策だけで済ませず、パッケージ更新を優先してください。(Microsoft Security Response Center)

この脆弱性は、インターネットから誰でも即座に悪用できるタイプではありません。しかし、複数のアプリケーションや利用者が同じRabbitMQのvhostを共有している環境では、返信メッセージの信頼性や未配送検知に影響する可能性があります。ここでは、Direct Reply-toの仕組み、影響範囲の判断方法、Azure Linux 3.0での確認・更新手順、更新後に確認すべきポイントまで解説します。

CVE-2026-57215の概要

項目	内容
CVE番号	CVE-2026-57215
対象製品	RabbitMQ Server
Azure Linuxの対象	Azure Linux 3.0のrabbitmq-server 3.13.7-6
Azure Linuxの修正版	rabbitmq-server 3.13.7-7
脆弱性の種類	Direct Reply-toの不正バインディング、返信チャネル注入、phantom binding
主な攻撃条件	RabbitMQへ認証済みで、共有vhost内に必要なバインド・パブリッシュ権限があること
想定される影響	正規クライアントへの未認可返信の送信、ルーティング状態の誤認、未配送の見逃し
RabbitMQ公式の深刻度	High、CVSS v4.0で7.0
個別の回避策	MSRCでは案内なし。修正版への更新が基本

RabbitMQ公式アドバイザリでは、上流版の影響範囲を3.13.0以上3.13.15未満、4.0.0以上4.0.20未満、4.1.0以上4.1.11未満、4.2.0以上4.2.6未満としています。Azure Linux 3.0では、上流版をそのまま3.13.15へ上げるのではなく、修正を3.13.7-7へバックポートしています。(GitHub)

上流版の3.13.15とAzure Linux版の3.13.7-7を混同しない

運用上、最も間違いやすいのがバージョンの見方です。

RabbitMQ上流版では3.13系の修正版が3.13.15ですが、Azure Linux 3.0のRPMでは、RabbitMQ本体のバージョンを3.13.7に維持したまま、RPMのリリース番号を-6から-7へ更新しています。Azure Linuxのspecファイルにも、Version: 3.13.7、Release: 7、CVE-2026-57215.patchの適用が記録されています。(GitHub)

そのため、Azure Linux 3.0では次のように判断します。

表示	CVE-2026-57215への対応状況
3.13.7-6.azl3	影響を受ける
3.13.7-7.azl3	修正済み
3.13.7-8.azl3など、それ以降	通常は修正を含む
RabbitMQ上流版の3.13.15	上流プロジェクト側の修正版

3.13.7という本体バージョンだけを見て、修正済みかどうかを判断してはいけません。Azure LinuxではRPMのリリース番号まで確認する必要があります。

RabbitMQのDirect Reply-toとは

Direct Reply-toは、RabbitMQでRPC形式のリクエスト・レスポンスを実装するときに、クライアントごとの返信キューを作成せず、レスポンスを要求元のチャネルへ直接返す仕組みです。

一般的なRPCでは、クライアントが返信用キューを作成し、そのキュー名をリクエストのreply-toプロパティに指定します。Direct Reply-toでは、実在する返信キューの代わりに、次の疑似キュー名を使用します。

amq.rabbitmq.reply-to

AMQP 0-9-1では、おおむね次の流れで処理されます。

1. クライアントがamq.rabbitmq.reply-toを購読する
2. リクエストのreply-toに同じ名前を設定する
3. RabbitMQが内部的にamq.rabbitmq.reply-to.<opaque-suffix>という返信先へ書き換える
4. RPCサーバーがその返信先へ結果を送信する
5. RabbitMQが実在するキューを経由せず、要求元のチャネルへ返信を届ける

Direct Reply-toの返信先は通常のキューではありません。RabbitMQ内部ではrabbit_volatile_queueとして扱われ、メタデータストアに保存されず、メッセージを保持するバッファも持ちません。Management UIやrabbitmqctl list_queuesにも表示されず、配送保証はat-most-onceです。(RabbitMQ)

この「キューのように見えるが、実際のキューとしては保存されない」という特殊な構造が、CVE-2026-57215の発生条件になっています。

CVE-2026-57215で返信チャネル注入が起きる仕組み

脆弱なRabbitMQでは、amq.rabbitmq.reply-to.*というDirect Reply-toの仮想返信先を、通常のキューと同じようにバインディング先として扱える場合があります。

問題は、バインディング作成時と削除時で、仮想返信先の扱いが一致していないことです。

脆弱な処理の流れ

1. 認証済みユーザーが、特定のamq.rabbitmq.reply-to.*を宛先とするバインディングを作成する
2. RabbitMQはDirect Reply-to名を有効なルーティング対象として扱う
3. しかし、仮想返信先は通常のキューレコードとしてKhepriに保存されていない
4. バインディング削除時、宛先のキューレコードが見つからないため、実際のルートを削除しないまま正常終了する場合がある
5. 削除したはずのバインディングが「phantom binding」として残る

RabbitMQ公式の検証では、被害側のDirect Reply-toコンシューマーへ未認可メッセージが配送され、queue_unbind後にもバインディングが残る動作が確認されています。また、通常ならmandatory指定のメッセージに対して返るはずのNO_ROUTEが、汚染されたexchangeでは返らないケースも確認されています。(GitHub)

想定される影響

影響	実際に起こり得ること
返信チャネル注入	RPCクライアントが、正規サーバー以外から送られた返信を受信する
phantom binding	削除操作が成功したように見えても、不正なルートが残る
未配送検知の失敗	本来は配送不能でも、RabbitMQ側で「ルーティング済み」と扱われる
共有vhost内の影響	同じvhostを使う別アプリケーションや別テナントの返信チャネルが標的になる
障害調査の複雑化	キュー一覧にはDirect Reply-toが表示されず、通常のキュー監視だけでは見つけにくい

実際の業務影響は、RPCクライアントが返信内容やcorrelation_idをどの程度検証しているかによって変わります。返信を無条件に正規応答として処理する実装では、影響が大きくなる可能性があります。

修正版では仮想返信先へのバインディングを拒否する

Azure Linux 3.0の修正パッチでは、バインディング先が次のいずれかに該当した場合、access_refusedとして処理を拒否します。

amq.rabbitmq.reply-to
amq.rabbitmq.reply-to.*

これにより、Direct Reply-toの仮想キューを通常のキューとしてbindまたはunbindする経路が遮断されます。(GitHub)

どの環境を優先して対応すべきか

CVE-2026-57215は、認証不要のリモートコード実行脆弱性ではありません。RabbitMQ公式の評価では、ネットワーク経由で到達可能ですが、認証済みの低権限ユーザーが必要で、攻撃の複雑さはHighとされています。(GitHub)

ただし、次の条件に当てはまる環境は優先度を上げる必要があります。

環境条件	対応優先度
3.13.7-6で、複数の利用者やサービスが同じvhostを共有	最優先
Direct Reply-toを使ったRPC処理がある	最優先
vhost権限が.*など広い正規表現で設定されている	高
外部組織、委託先、複数チームへRabbitMQアカウントを発行している	高
アプリケーションがcorrelation_idを検証していない	高
単一アプリケーション専用のvhostで権限も限定している	相対的には低いが早期更新
Direct Reply-toを使っていないことが確認できている	悪用可能性は下がるが更新対象
RabbitMQがコンテナ内で稼働している	ホストではなくコンテナイメージを確認

共有vhostを使用している場合は、「信頼できる社内サービスだけだから問題ない」と判断しないことが重要です。認証情報の漏えい、侵害されたサービスアカウント、過剰な権限設定によって、同じ攻撃経路が利用される可能性があります。

Azure Linux 3.0で影響を確認する方法

OSとRPMパッケージのバージョンを確認する

まず、RabbitMQが動作しているOSとRPMの完全なバージョンを確認します。

cat /etc/os-release

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

影響を受ける環境では、次のような結果になります。

rabbitmq-server 3.13.7-6.azl3

修正済みであれば、次のように-7以降が表示されます。

rabbitmq-server 3.13.7-7.azl3

パッケージが見つからない場合は、RabbitMQがコンテナ、Kubernetes Pod、独自イメージ、別ホストで稼働していないか確認してください。

たとえばPodmanコンテナ内のRPMを確認する場合は、次のように実行します。

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

ホストOSが修正済みでも、コンテナイメージ内のRabbitMQが古ければ対応は完了していません。

RabbitMQの実行時バージョンだけでは判断しない

次のコマンドはRabbitMQ本体のバージョン確認には役立ちます。

sudo rabbitmq-diagnostics server_version

しかし、Azure Linuxの3.13.7-6と3.13.7-7は、どちらもRabbitMQ本体のバージョンが3.13.7です。このコマンドだけではRPMのリリース番号を区別できません。

必ず次のRPM照会結果を判断基準にしてください。

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

vhostと権限設定を確認する

まず、vhostの一覧を取得します。

sudo rabbitmqctl list_vhosts name

各vhostについて、ユーザー権限を確認します。

sudo rabbitmqctl list_permissions -p "/"

出力されるconfigure、write、readの正規表現が、すべて.*になっているユーザーは広い権限を持っています。

特に、次のような状態は見直し対象です。

• 複数のアプリケーションが同じユーザーを共有している
• 複数部署や複数顧客が同じvhostを使用している
• 必要なexchangeやqueueだけでなく、すべてのリソースへアクセスできる
• 使用されていないサービスアカウントが残っている
• 認証情報のローテーションが行われていない

Direct Reply-to宛ての不審なバインディングを確認する

list_queuesではDirect Reply-toの仮想キューは確認できません。バインディングを直接調べます。

デフォルトvhostの場合は、次のコマンドで候補を抽出できます。

sudo rabbitmqctl -q list_bindings -p "/" \
  source_name destination_name destination_kind routing_key |
awk -F '\t' '$2 == "amq.rabbitmq.reply-to" || $2 ~ /^amq\.rabbitmq\.reply-to\./'

別のvhostを使っている場合は、-p "/"を対象のvhost名に変更してください。

正常なDirect Reply-toでは、通常のキューバインディングを作成する必要はありません。したがって、destination_nameがamq.rabbitmq.reply-toまたはその接頭辞で始まる結果は、調査すべき候補です。rabbitmqctl list_bindingsでは、バインディングのsource、destination、種類、routing keyを確認できます。(RabbitMQ)

結果が表示された場合は、直ちにKhepriの内部データを手作業で編集しないでください。対象vhost、exchange、接続ユーザー、作成時刻に関連するログを保全し、MicrosoftまたはRabbitMQのサポートへ相談するのが安全です。

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

更新前に構成と稼働状態を記録する

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

• RabbitMQクラスタのノード数
• 各ノードのRPMバージョン
• vhost、ユーザー、権限
• exchange、queue、bindingの数
• quorum queueやstreamの同期状態
• メモリ・ディスクアラームの有無
• 更新前のRPC疎通結果

RabbitMQのdefinitionsには、ユーザー、vhost、権限、queue、exchange、binding、policyなどが含まれます。更新前にJSONへエクスポートしておくと、構成比較や障害調査に利用できます。(RabbitMQ)

sudo install -d -m 700 /var/backups/rabbitmq

sudo rabbitmqctl export_definitions \
  /var/backups/rabbitmq/definitions-$(date +%Y%m%d-%H%M).json

definitionsファイルにはパスワードハッシュなどの機密情報が含まれるため、アクセス権を制限し、安全な場所へ保管してください。

リポジトリ情報を更新する

sudo tdnf makecache
sudo tdnf info rabbitmq-server

社内ミラーや固定されたリポジトリスナップショットを使用している場合は、3.13.7-7が同期されているか確認します。

候補が古いままの場合は、次を確認してください。

• Azure Linux公式リポジトリが有効か
• 社内ミラーの最終同期日時
• パッケージのバージョン固定設定
• 除外設定やallowlist
• コンテナイメージのベースタグとdigest

出所が確認できないRPMを外部サイトから個別にダウンロードして適用するのは避けてください。

単一ノード環境を更新する

単一ノード構成ではRabbitMQの停止時間が発生します。アプリケーション側のリトライ動作を確認したうえで、メンテナンス時間内に実施します。

sudo systemctl stop rabbitmq-server

sudo tdnf update rabbitmq-server

sudo systemctl start rabbitmq-server

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

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

次のように表示されることを確認します。

rabbitmq-server 3.13.7-7.azl3

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

RabbitMQクラスタでは、全ノードを同時に停止・更新しないでください。

RabbitMQ公式のローリングアップグレード手順では、更新前にアラームやネットワーク分断がないことを確認し、各ノードを1台ずつ停止、更新、起動したうえで、クラスタへ正常復帰したことを確認してから次のノードへ進みます。パッチリリース間の更新は、ローリングアップグレードの対象になります。(RabbitMQ)

各ノードについて、次の順番で実施します。

1. クラスタとキューの状態を確認する
2. 対象ノードを停止する
3. rabbitmq-serverを更新する
4. 対象ノードを起動する
5. クラスタへの復帰とアラームを確認する
6. アプリケーション通信を確認する
7. 問題がなければ次のノードへ進む

更新前後の確認には、次のコマンドを使用できます。

sudo rabbitmqctl cluster_status

sudo rabbitmq-diagnostics -q ping

sudo rabbitmq-diagnostics -q check_running

sudo rabbitmq-diagnostics -q check_local_alarms

quorum queueやstreamを利用している場合は、ノード停止前にオンラインレプリカ数と同期状態を確認してください。クラスタ全体が更新済みになるまで、修正前ノードと修正後ノードが混在するため、途中で作業を中断しないことも重要です。

更新後に確認すべきポイント

全ノードが3.13.7-7以降になっているか

ロードバランサー配下のノード、待機系、災害対策環境、検証環境も含めて確認します。

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

1台でも3.13.7-6が残っている場合、対応完了とは判断できません。

RPCの正常系と異常系を確認する

最低限、次のテストを実施します。

テスト	確認内容
正常なRPC要求	正しいレスポンスが返る
タイムアウト	応答がない場合に処理が終了する
再接続	RabbitMQノード切り替え後に再接続できる
correlation_id不一致	不明な返信を破棄する
重複返信	同一処理を二重実行しない
未配送	mandatoryやpublisher confirmの処理が想定どおり動く

RabbitMQ公式チュートリアルでも、RPC要求ごとに一意のcorrelation_idを設定し、未知のIDを持つ返信は破棄すること、重複応答を考慮して処理を冪等にすることが推奨されています。(RabbitMQ)

不審なバインディングを再確認する

更新後にも、各vhostでDirect Reply-to宛てのバインディングを確認してください。

sudo rabbitmqctl -q list_bindings -p "/" \
  source_name destination_name destination_kind routing_key |
awk -F '\t' '$2 == "amq.rabbitmq.reply-to" || $2 ~ /^amq\.rabbitmq\.reply-to\./'

少なくとも公開されているAzure Linuxのバックポート差分は、今後のbind・unbind要求を拒否する修正です。既存の不正バインディングを一括削除する処理は、公開差分上では示されていません。したがって、更新すれば過去に残されたphantom bindingも自動的に消えるとは仮定せず、更新後の監査まで行うべきです。これは公開された修正内容から導かれる運用上の判断です。(GitHub)

不審なバインディングが残っている場合は、次の対応を優先します。

• 対象vhostへの新規接続を制限する
• 関連するサービスアカウントの認証情報を変更する
• RabbitMQとアプリケーションのログを保全する
• 対象exchangeやrouting keyを特定する
• サポートへ安全な削除・復旧方法を確認する
• 必要に応じてvhostやexchangeの再作成を検討する

内部データベースを直接編集すると、クラスタメタデータの不整合や復旧不能につながる可能性があるため避けてください。

修正版を適用できない場合の一時的なリスク低減策

MSRCではCVE-2026-57215に対する個別の回避策を案内していません。次の対策は悪用可能性や被害範囲を抑えるためのものであり、修正版の代替にはなりません。(Microsoft Security Response Center)

対策	目的
利用者・システムごとにvhostを分離する	共有vhost内での横方向の影響を抑える
configure、write、read権限を限定する	不要なbind・publish操作を防ぐ
未使用ユーザーを削除する	悪用可能な認証情報を減らす
認証情報をローテーションする	漏えい済み資格情報の無効化
RabbitMQ接続元を制限する	不要なネットワーク経路を閉じる
correlation_idを厳密に検証する	不明な返信をアプリケーションで拒否する
返信スキーマと値を検証する	不正なメッセージを業務処理へ渡さない
RPC処理を冪等にする	重複・再送時の二重処理を防ぐ

特に、複数サービスへ同一のRabbitMQユーザーを配布している場合は、アプリケーション単位でユーザーとvhostを分けることが有効です。

対応時によくある間違い

間違い	正しい対応
server_versionが3.13.7なので修正済みと判断する	RPMの-6と-7まで確認する
上流版が3.13.15未満なので、Azure Linuxの3.13.7-7も未修正と判断する	Azure Linuxのバックポート版を基準にする
ホストOSだけ確認する	コンテナやPod内部のパッケージも確認する
list_queuesに異常がないため安全と判断する	list_bindingsで仮想返信先を調べる
クラスタの1ノードだけ更新する	全ノードをローリング更新する
更新後にサービスを再起動しない	更新済みコードを読み込ませ、稼働確認する
更新だけで既存のphantom bindingも消えると考える	更新後にバインディング監査を行う
権限制限だけで恒久対応とする	一時対策と位置付け、3.13.7-7以降へ更新する
公開PoCを本番環境で実行する	読み取り中心の監査とサポートへの相談を優先する

CVE-2026-57215への対応を完了するためのチェックリスト

CVE-2026-57215への対応では、パッケージを更新するだけでなく、影響調査と更新後確認までを一連の作業として扱う必要があります。

1. rpm -qでrabbitmq-serverの完全なバージョンを確認する
2. 3.13.7-6であれば3.13.7-7以降へ更新する
3. コンテナやクラスタの全ノードを確認する
4. クラスタでは1ノードずつローリング更新する
5. 更新後にRPC、再接続、タイムアウトをテストする
6. 全vhostのバインディングを監査する
7. 共有vhostと過剰なユーザー権限を見直す
8. correlation_idの検証と冪等性をアプリケーション側で確認する
9. 不審なバインディングが見つかった場合はログを保全し、サポートへ相談する

最初に実行すべきコマンドは、次のRPM確認です。

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

結果が3.13.7-6.azl3であれば、権限制限や監視強化だけで対応を終えず、3.13.7-7以降への更新計画を直ちに進めてください。