CVE-2026-57216とは？Azure LinuxのRabbitMQ guest制限迂回と修正版

Azure Linux 3.0でrabbitmq-server 3.13.7-6を使用している場合は、修正版の3.13.7-7以上へ更新することが基本対応です。CVE-2026-57216は、RabbitMQがローカル接続だけに許可しているguestなどのユーザーについて、特定のPROXY protocol構成で接続元を正しく判定できず、リモートからセッションが成立する可能性がある脆弱性です。MSRCでは個別の回避策が示されていないため、設定変更だけで済ませず、パッケージ更新を完了させる必要があります。(Microsoft セキュリティ応答センター)

ただし、パスワードを知らない攻撃者が無条件でログインできる問題ではありません。攻撃成立には、guestなどのloopback制限ユーザーの有効な認証情報と、脆弱性の影響を受けるPROXY protocol構成が必要です。一方、標準のguestアカウントや初期認証情報が残り、広い権限が設定されている環境では、メッセージの参照や送信、RabbitMQの設定変更などにつながるおそれがあります。(RabbitMQ)

CVE-2026-57216とは

CVE-2026-57216は、RabbitMQのloopbackユーザー制限に関する認証制御の不備です。AMQP 0-9-1、AMQP 1.0、RabbitMQ Stream Protocolのリスナーが影響対象に含まれます。

RabbitMQでは通常、guestユーザーはlocalhostからの接続に限定されます。リモートホストから正しいユーザー名とパスワードを入力しても、接続元がloopbackアドレスでなければ拒否される設計です。ところが、PROXY protocolを使用する一部の構成では、実際の接続元ではなくRabbitMQリスナー側のアドレスを基準にloopback判定していたため、リモート接続をローカル接続と誤認する可能性がありました。(RabbitMQ)

Azure Linux 3.0で確認すべき情報は次のとおりです。

確認項目	内容
対象パッケージ	Azure Linux 3.0の`rabbitmq-server`
影響を受けるパッケージ	`3.13.7-6`を使用中なら影響対象として扱う
Azure Linux向け修正版	`3.13.7-7`以上
主な成立条件	PROXY protocol、loopback側のバックエンドリスナー、loopback制限ユーザーの有効な認証情報
MSRC掲載の個別回避策	なし
恒久対策	修正版への更新

RabbitMQ本体のアップストリームでは、3.13系の修正版は3.13.15です。一方、Azure Linuxでは修正コードを3.13.7系へバックポートし、RPMのリリース番号を-6から-7へ更新しています。そのため、バージョンの3.13.7だけを見て未修正と判断してはいけません。Azure LinuxではRPMのリリース番号まで確認することが重要です。(Microsoft セキュリティ応答センター)

アップストリーム版や独自コンテナイメージを使用している場合は、次の修正版が基準になります。

系列	影響を受ける範囲	修正版
RabbitMQ 3.13	3.13.0以上、3.13.15未満	3.13.15
RabbitMQ 4.0	4.0.0以上、4.0.20未満	4.0.20
RabbitMQ 4.1	4.1.0以上、4.1.11未満	4.1.11
RabbitMQ 4.2	4.2.0以上、4.2.6未満	4.2.6

Azure Linuxの公式RPMと、RabbitMQ公式イメージや独自ビルドでは判定基準が異なります。ホストOSだけでなく、コンテナ内部で実際に稼働しているパッケージも確認してください。(GitHub)

リモートguestセッションが成立する仕組み

通常のRabbitMQでは、loopback_usersに登録されたユーザーの接続元を確認し、localhost以外からのログインを拒否します。標準設定ではguestがこの制限対象です。(RabbitMQ)

脆弱な構成では、次の流れで制限をすり抜ける可能性があります。

リモートクライアントがL4プロキシやロードバランサーへ接続する
プロキシがPROXY protocolを利用してRabbitMQへ転送する
RabbitMQのバックエンドリスナーが127.0.0.1や::1などで待ち受けている
脆弱な処理が実際のクライアント側アドレスではなく、リスナー側アドレスをloopback判定に使用する
接続元がlocalhostだと誤認され、有効なguestなどの認証情報でセッションが成立する

問題の中心は、リスナー側のローカルアドレスを取得するsockname相当の情報を使用していた点です。修正では、実際の接続相手を示すpeername側の情報を使用するよう変更されています。(GitHub)

これはパスワード認証そのものを無効化する脆弱性ではありません。有効な認証情報は必要ですが、接続元制限を信頼して初期資格情報や共有資格情報を残している環境では、実害につながりやすくなります。

影響を受ける環境の判断基準

パッケージのバージョンだけでなく、RabbitMQの実行時設定、ユーザー、ネットワーク経路を組み合わせて判断します。

状況	判断と対応
`3.13.7-6`でPROXY protocolを使用している	優先度を上げて直ちに更新する
バックエンドリスナーがloopbackアドレスで待ち受けている	脆弱性の成立条件に該当する可能性がある
`guest`が存在し、認証情報が初期値または共有されている	危険度が高い。更新と同時に認証情報を無効化する
`guest`は削除済みだが、別ユーザーを`loopback_users`に登録している	引き続き影響を受ける可能性がある
PROXY protocolを使用していない	公開されている主要な成立条件には該当しにくいが、修正版へ更新する
`loopback_users = none`を設定している	回避策ではない。リモート接続制限そのものを解除する危険な設定
`3.13.7-7`以上へ更新済み	本脆弱性の修正済みパッケージ。過去の不審接続は別途確認する

ここでいうプロキシは、RabbitMQ Management UIの前段に置いた一般的なHTTPリバースプロキシだけを意味するものではありません。AMQPやStream ProtocolのTCP接続でPROXY protocolを使用している経路が主な確認対象です。

また、guestだけを検索して終わらせないでください。loopback_usersへ独自ユーザーを追加している場合、そのユーザーも同様の制限迂回対象になり得ます。

Azure Linux 3.0でパッケージを確認する方法

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

最初に、対象サーバーがAzure Linux 3.0であることと、インストール済みRPMの完全なバージョンを確認します。

cat /etc/os-release

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

出力のバージョン部分が次のようになっているか確認します。

rabbitmq-server-3.13.7-6...

3.13.7-6であれば、影響対象として更新を進めます。次のように-7以上であれば、MSRCが示す修正版です。

rabbitmq-server-3.13.7-7...

コンテナでRabbitMQを実行している場合は、ホスト側ではなくコンテナ内部で確認します。

kubectl exec -n <namespace> <pod-name> -- rpm -q rabbitmq-server

Dockerを直接使用している場合の例は次のとおりです。

docker exec <container-name> rpm -q rabbitmq-server

ホストOSのパッケージが修正済みでも、古いコンテナイメージが稼働していれば対策は完了していません。

PROXY protocolとリスナー設定を確認する

RabbitMQの実行時設定を確認します。

sudo rabbitmqctl environment \
  | grep -E 'proxy_protocol|loopback_users|tcp_listeners|stream'

続いて、現在待ち受けているリスナーを確認します。

sudo rabbitmq-diagnostics listeners

次の項目を重点的に確認してください。

proxy_protocolが有効になっているか
AMQPまたはStream Protocolのリスナーがloopbackアドレスで待ち受けているか
前段にTCPプロキシやロードバランサーが存在するか
そのプロキシへ社外や利用者ネットワークから到達できるか
プロキシを経由せずRabbitMQへ直接接続できる経路がないか

設定ファイルも確認できますが、環境変数や生成済み設定が使われることがあるため、最終的には実行時情報を優先します。

sudo grep -RniE \
  'proxy_protocol|loopback_users|listeners\.|stream\.' \
  /etc/rabbitmq/

guestとloopback制限ユーザーを確認する

登録済みユーザーを一覧表示します。

sudo rabbitmqctl list_users

guestが存在する場合は、付与されている仮想ホスト権限も確認します。

sudo rabbitmqctl list_user_permissions guest

確認すべきポイントは、ユーザーの存在だけではありません。

administratorなどの強いタグが付与されていないか
不要な仮想ホストへアクセスできないか
configure、write、readの権限が広すぎないか
アプリケーションや監視ツールがguestを使用していないか
認証情報が初期値、共有値、固定値になっていないか

guestを削除する前に、ローカル監視や保守スクリプトが依存していないことを確認してください。

修正版3.13.7-7へ更新する手順

Azure Linux 3.0では、パッケージ管理にtdnfを使用します。MicrosoftのAzure Linux向けドキュメントでも、パッケージ更新にはtdnf upgradeが案内されています。(Microsoft Learn)

更新前に確認すること

本番環境では、いきなり全ノードを再起動せず、次の項目を確認します。

RabbitMQクラスタの全ノードと役割
キューの種類とレプリカ状態
キュー滞留数とメッセージ処理状況
接続中のアプリケーションと再接続動作
設定ファイル、ユーザー、権限、定義情報のバックアップ
利用可能な保守時間と障害時の切り戻し手順
更新対象リポジトリで3.13.7-7以上が配信されていること

パッケージ情報を更新し、候補バージョンを確認します。

sudo tdnf clean all
sudo tdnf list rabbitmq-server

パッケージを更新する

sudo tdnf upgrade rabbitmq-server

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

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

出力が3.13.7-7以上になっていることを確認してください。

RabbitMQを再起動して動作確認する

パッケージ更新後も古いプロセスが動作し続けないよう、環境の運用手順に従ってRabbitMQを再起動します。

sudo systemctl restart rabbitmq-server

再起動後は、サービスとRabbitMQの応答を確認します。

sudo systemctl is-active rabbitmq-server
sudo rabbitmq-diagnostics ping
sudo rabbitmqctl cluster_status
sudo rabbitmq-diagnostics listeners

さらに、実際のアプリケーションから次の動作を確認します。

AMQP接続が正常に再確立される
メッセージの送信と受信ができる
キューの滞留が増加し続けていない
Management UIや監視ツールが正常に接続できる
TLS、認証、仮想ホスト権限に異常がない
RabbitMQログに新しいエラーが記録されていない

クラスタ環境では、設計と運用手順がローリング更新を許容する場合、1ノードずつ更新します。1台だけ修正済みにしても、別のノードに脆弱なリスナーが残っていれば攻撃経路は残ります。最終的に全ノードのRPMバージョンを一覧化し、修正済みであることを確認してください。

すぐに更新できない場合の暫定対応

MSRCではCVE-2026-57216に対する個別の回避策を掲載していません。以下は攻撃成立の可能性や被害範囲を抑えるための補完策であり、修正版への更新を置き換えるものではありません。(Microsoft セキュリティ応答センター)

guestユーザーを削除する

アプリケーションや監視処理がguestを使用していないことを確認したうえで削除します。

sudo rabbitmqctl delete_user guest

業務アプリケーションには、用途ごとの専用ユーザーを作成し、必要な仮想ホストと操作だけを許可します。共通の管理者ユーザーを複数アプリケーションで共有しないことが重要です。

ただし、guestを削除しても、別のユーザーがloopback_usersへ登録されていれば影響が残る可能性があります。

認証情報を変更する

すぐに削除できない場合は、長くランダムなパスワードへ変更し、Secret管理サービスなどで安全に保管します。

特に、次の認証情報は速やかに変更してください。

guest/guestなどの初期認証情報
構築手順書に平文で記録されたパスワード
複数環境で使い回しているパスワード
退職者や委託先が把握している共有アカウント
リポジトリやコンテナイメージへ埋め込まれた認証情報

認証情報を変更した後は、既存セッションが残っていないかも確認します。

不要なPROXY protocolを無効化する

PROXY protocolを使用する必要がない構成では、無効化を検討できます。ただし、プロキシ側とRabbitMQ側の設定が一致しないと接続障害が発生します。

本番環境で変更する前に、次の点を確認してください。

接続元IPを監査やアクセス制御に使用していないか
ロードバランサーが常にPROXYヘッダーを送信していないか
AMQPクライアントの接続先変更が必要にならないか
複数プロトコルで同じリスナーを共有していないか

構成を十分に確認できない場合は、PROXY protocolの変更よりもパッケージ更新を優先します。

ネットワーク経路を制限する

ファイアウォール、Azureのネットワーク制御、ロードバランサーのアクセス制御を使い、接続元を必要なアプリケーションに限定します。

特に、次の状態は避けてください。

PROXY protocolを信頼するリスナーへ任意の端末から直接接続できる
バックエンドポートがインターネットへ公開されている
管理用ネットワークと利用者ネットワークが分離されていない
プロキシ以外のホストからRabbitMQへ接続できる
開発環境と本番環境で同じ認証情報を使用している

PROXY protocolを受け入れるリスナーは、信頼できるプロキシだけが到達できるネットワークに配置する必要があります。

loopback_usersを無効化しない

次のような設定を回避策として使用してはいけません。

loopback_users = none

この設定は脆弱性を修正するものではなく、loopbackユーザーのリモート接続制限そのものを解除します。RabbitMQ公式ドキュメントでも、本番環境でリモートguest接続を許可する設定は強く非推奨とされています。(RabbitMQ)

不正なguestセッションがなかったか確認する方法

修正版へ更新した後も、影響を受ける期間中に不審な接続がなかったか確認します。公開アドバイザリには概念実証コードも含まれているため、実悪用が確認されていない場合でも、外部から到達できる環境では調査を省略しない方が安全です。(GitHub)

現在の接続を確認する

sudo rabbitmqctl list_connections \
  name user peer_host peer_port protocol state

次の接続を重点的に調べます。

guestによる接続
loopback制限ユーザーによる接続
想定外のIPアドレスからの接続
通常使用しないプロトコルでの接続
長時間継続している不明なセッション
業務システムの接続元一覧と一致しないセッション

PROXY protocolを使用している場合は、RabbitMQ側の接続情報だけでなく、前段プロキシやロードバランサーのログも照合します。

RabbitMQのログを確認する

調査対象期間を指定してログを検索します。

sudo journalctl -u rabbitmq-server \
  --since "YYYY-MM-DD" \
  | grep -Ei 'guest|authentication|login|connection'

ファイルへログを出力している場合は、環境に応じたログディレクトリも確認します。

ただし、標準設定のログだけで、すべての成功した接続やメッセージ操作を追跡できるとは限りません。該当ログが見つからないことだけを理由に、侵害なしと断定しないでください。

ユーザーと設定変更を確認する

不審なセッションが疑われる場合は、次の項目も調査します。

知らないユーザーや管理者タグが追加されていないか
仮想ホストの権限が変更されていないか
新しいキューやExchangeが作成されていないか
PolicyやRuntime Parameterが追加されていないか
FederationやShovelの転送先が変更されていないか
メッセージの異常な減少や外部送信がなかったか
Management APIへの不審なアクセスがなかったか
アプリケーション用Secretが参照または変更されていないか

侵害の可能性がある場合は、ログを保全したうえで、不審な接続の遮断、関連資格情報のローテーション、不要ユーザーの削除を行います。

対応時に間違えやすいポイント

誤った判断	正しい考え方
`3.13.7`なのでアップストリームの3.13.15まで上げなければ直らない	Azure Linux公式RPMでは`3.13.7-7`に修正がバックポートされている
パスワードなしで侵入される脆弱性である	有効なloopback制限ユーザーの認証情報が必要
`guest`を削除すればパッチは不要	独自のloopbackユーザーや将来の設定変更を考慮し、更新も必要
リスナーがlocalhostなので外部から届かない	前段プロキシがリモート接続をloopbackリスナーへ中継する構成が問題になる
`loopback_users = none`にすれば判定処理を回避できる	リモート接続制限を意図的に解除するため、むしろ危険
1台だけ更新すればクラスタ全体が安全になる	脆弱なリスナーが残る全ノードを更新する必要がある
ホストのRPMだけ確認すればよい	コンテナや独自イメージ内のRabbitMQも確認する

まず実施すべき対応

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

Azure Linux 3.0で稼働するRabbitMQの全ノード、仮想マシン、コンテナを洗い出す
rpm -qでVERSION-RELEASEまで確認する
PROXY protocol、リスナー、loopback_users、登録ユーザーを確認する
rabbitmq-server 3.13.7-7以上へ更新する
RabbitMQプロセスを安全に再起動し、全ノードのバージョンを再確認する
guestと不要なloopbackユーザーを削除または資格情報を変更する
RabbitMQ、プロキシ、ロードバランサーのログから不審な接続を調査する
PROXY protocolを信頼するネットワーク境界を文書化し、接続元を制限する

特に重要なのは、3.13.7という本体バージョンだけで判断せず、Azure LinuxのRPMリリース番号が-7以上であることを確認することです。更新後は、標準のguestアカウントを残さず、用途別の専用ユーザーと最小権限へ移行することで、同種の認証制御問題が発生した場合の被害も抑えられます。

この記事を書いた人

佐藤健司

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

CVE-2026-57216とは？Azure LinuxのRabbitMQ guest制限迂回と修正版

CVE-2026-57216とは

リモートguestセッションが成立する仕組み

影響を受ける環境の判断基準

Azure Linux 3.0でパッケージを確認する方法

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

PROXY protocolとリスナー設定を確認する

guestとloopback制限ユーザーを確認する

修正版3.13.7-7へ更新する手順

更新前に確認すること

パッケージを更新する

RabbitMQを再起動して動作確認する

すぐに更新できない場合の暫定対応

guestユーザーを削除する

認証情報を変更する

不要なPROXY protocolを無効化する

ネットワーク経路を制限する

loopback_usersを無効化しない

不正なguestセッションがなかったか確認する方法

現在の接続を確認する

RabbitMQのログを確認する

ユーザーと設定変更を確認する

対応時に間違えやすいポイント

まず実施すべき対応

この記事を書いた人

コメント

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

CVE-2026-57216とは？Azure LinuxのRabbitMQ guest制限迂回と修正版

CVE-2026-57216とは

リモートguestセッションが成立する仕組み

影響を受ける環境の判断基準

Azure Linux 3.0でパッケージを確認する方法

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

PROXY protocolとリスナー設定を確認する

guestとloopback制限ユーザーを確認する

修正版3.13.7-7へ更新する手順

更新前に確認すること

パッケージを更新する

RabbitMQを再起動して動作確認する

すぐに更新できない場合の暫定対応

guestユーザーを削除する

認証情報を変更する

不要なPROXY protocolを無効化する

ネットワーク経路を制限する

loopback_usersを無効化しない

不正なguestセッションがなかったか確認する方法

現在の接続を確認する

RabbitMQのログを確認する

ユーザーと設定変更を確認する

対応時に間違えやすいポイント

まず実施すべき対応

この記事を書いた人

関連記事

コメント

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

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