MENU

CVE-2026-57220とは？Azure Linux 3.0のRabbitMQ Stream未認証DoSと更新手順

Azure

Azure Linux 3.0で rabbitmq-server-3.13.7-6.azl3 を使用し、RabbitMQ Streamのリスナーへネットワーク経由で接続できる状態なら、3.13.7-7 以上へ更新し、RabbitMQを再起動する必要があります。

CVE-2026-57220は、Stream接続の認証が完了する前にフレームサイズの制限が適切に機能せず、未認証の攻撃者がRabbitMQのメモリを大量に消費させられる脆弱性です。認証情報は不要で、悪用されるとRabbitMQプロセスやノードが停止し、メッセージの送受信ができなくなる可能性があります。MSRCは個別の回避策を示していないため、ネットワーク制限だけで済ませず、修正版への更新を本対策としてください。(Microsoft Security Response Center)

この記事では、影響を受ける構成の見分け方、Azure Linux 3.0での更新手順、クラスタ更新時の注意点、更新までの一時的な露出低減策、更新後の確認方法を具体的に解説します。

目次

CVE-2026-57220とは

CVE-2026-57220は、RabbitMQのStreamプロトコルを処理するリスナーに存在する、未認証のメモリ枯渇DoS脆弱性です。

Azure Linux 3.0では、次のパッケージが重要な判断基準になります。

項目内容
対象OSAzure Linux 3.0
対象パッケージrabbitmq-server
影響を受ける版3.13.7-6.azl3
修正版3.13.7-7.azl3以上
攻撃に必要な権限不要
主な成立条件RabbitMQ Streamリスナーへ到達できること
主な影響メモリ消費増大、RabbitMQプロセス停止、ノード停止、サービス拒否
CVSS v3.17.5、High
MSRCの個別回避策掲載なし

公開されているRabbitMQのアドバイザリでは、攻撃元はネットワーク経由、攻撃条件は低難度、認証不要、ユーザー操作不要と評価されています。機密性や完全性よりも、可用性への影響が中心となる脆弱性です。(GitHub)

未認証でメモリ枯渇が起きる仕組み

通常、RabbitMQ Streamでは、クライアントとの接続処理中に通信条件を調整し、認証や仮想ホストへのアクセス確認を行います。

CVE-2026-57220では、この認証前の段階で次の処理が発生します。

  1. 攻撃者がRabbitMQ Streamリスナーへ接続する
  2. 実際のデータ量よりも大きなフレーム長を宣言する
  3. 不完全なフレームのデータを継続的に送信する
  4. RabbitMQが認証前のデータをメモリへ蓄積する
  5. 多数の接続や高速な送信によってメモリ使用量が増える
  6. メモリ不足やOOM KillerによってRabbitMQプロセスが停止する

重要なのは、ユーザー名やパスワードの検証より前にメモリが消費される点です。そのため、強力なパスワードを設定していても、この脆弱性の直接的な対策にはなりません。

単発の短いパケットだけで必ずメモリ不足になるわけではありません。実際の影響は、接続数、送信速度、RabbitMQに割り当てたメモリ、コンテナのメモリ制限などに左右されます。しかし、未認証の接続を並行して作成できるため、外部や信頼できないネットワークからリスナーへ到達できる環境では優先度の高い問題です。(GitHub)

3.13.7-7では認証前接続のメモリ制限が追加される

Azure Linuxの修正パッチでは、認証前の接続を処理するErlangプロセスにヒープ上限を設定し、上限を超えた接続プロセスを終了させる処理が追加されています。

RabbitMQ Streamの接続処理にも認証前のヒープ制限が適用され、認証に成功した後で制限を解除する構成です。これにより、未認証の接続が無制限にメモリを使用し続けるリスクを抑えます。

Azure Linuxのパッケージ定義では、CVE-2026-57220.patch が rabbitmq-server 3.13.7-7 に組み込まれています。単なるパッケージ番号の変更ではなく、認証前接続のメモリ消費を制御するコード修正を含む更新です。(GitHub)

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

RabbitMQの上流アドバイザリでは、上流版RabbitMQ 4.2系列の修正版として4.2.6が示されています。一方、Azure Linux 3.0では、3.13.7をベースとするディストリビューションパッケージに修正をバックポートし、3.13.7-7.azl3 として提供しています。(GitHub)

したがって、Azure Linux 3.0では次のように判断します。

導入方法更新先の判断基準
Azure LinuxのRPMパッケージ3.13.7-7.azl3以上
RabbitMQ上流のパッケージ上流アドバイザリで示された修正版
コンテナイメージイメージ提供元の修正版とベースOSを確認
独自ビルド取り込んだコミットやパッチを確認

Azure LinuxのRPMを利用している環境へ、上流版4.2.6をそのまま上書きインストールするのは避けてください。設定形式、Erlangの依存関係、プラグイン、クラスタ互換性が変わる可能性があります。

影響を受ける環境か確認する方法

影響の有無は、次の3点で判断します。

  • Azure Linux 3.0上で対象パッケージを使用しているか
  • rabbitmq_stream プラグインが有効か
  • Streamリスナーへ攻撃元から到達できるか

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.x86_64

修正済みであれば、少なくとも次の版になっている必要があります。

rabbitmq-server-3.13.7-7.azl3.x86_64

確認には rabbitmqctl version ではなく、rpm -q を使用するのが確実です。RabbitMQ本体のバージョン表示が 3.13.7 のままでも、Azure Linux側のセキュリティ修正はRPMのRelease番号である -6 と -7 に分かれているためです。

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

次のコマンドで、有効なプラグインを確認します。

sudo rabbitmq-plugins list -e | grep -w rabbitmq_stream

rabbitmq_stream が表示された場合は、Streamプラグインが有効です。

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

sudo -u rabbitmq rabbitmq-diagnostics -q listeners

標準的な構成では、RabbitMQ StreamはTCP 5552番ポートを使用します。ただし、ポート番号やバインド先は変更できるため、5552番だけを調べて安全と判断してはいけません。rabbitmq-diagnostics listeners の結果を優先してください。(RabbitMQ)

OS側から5552番ポートを確認する場合は、次のコマンドも利用できます。

sudo ss -lntp | grep ':5552'

出力例のアドレスにも注意してください。

待ち受けアドレス判断
0.0.0.0:5552すべてのIPv4インターフェースで待ち受け
[::]:5552IPv6を含む全インターフェースで待ち受ける可能性
127.0.0.1:5552同一ホストからのみ接続可能
プライベートIP:5552VNetや社内ネットワークから接続可能
パブリックIP相当インターネットから到達できる可能性を確認

0.0.0.0 で待ち受けていても、Azure Network Security Groupやホストファイアウォールで遮断されていれば、直ちにインターネット公開されているとは限りません。待ち受け状態とネットワーク経路の両方を確認する必要があります。

対応優先度の判断表

パッケージStreamリスナー到達範囲判断
3.13.7-6有効インターネット最優先で遮断または制限し、直ちに更新
3.13.7-6有効社内・VNet内侵害端末から悪用される可能性があるため早急に更新
3.13.7-6無効リスナーなしこの攻撃経路は成立しにくいが、パッケージ更新を推奨
3.13.7-7以上有効任意修正済み。再起動と稼働確認を実施
Azure Linux以外のパッケージ有効任意パッケージ提供元の修正版を確認

「インターネットへ公開していないから対応不要」とは判断しないでください。VNet内の侵害されたVM、VPN接続端末、踏み台サーバー、誤設定されたロードバランサーなどから到達できる場合があります。

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

更新前に稼働状態を確認する

単一ノードの場合は、再起動中にRabbitMQが停止します。業務影響の少ない時間帯に実施してください。

更新前に、RabbitMQが正常に稼働しているか確認します。

sudo -u rabbitmq rabbitmq-diagnostics -q ping
sudo -u rabbitmq rabbitmq-diagnostics -q check_running
sudo -u rabbitmq rabbitmq-diagnostics -q check_local_alarms

クラスタ環境では、クラスタ状態も記録します。

sudo -u rabbitmq rabbitmqctl cluster_status

設定ファイル、定義情報、データディレクトリのバックアップ方針も確認してください。RabbitMQ公式ドキュメントでは、アップグレード前のデータディレクトリのバックアップと、クラスタのクォーラム維持が推奨されています。(RabbitMQ)

DNFでrabbitmq-serverを更新する

Azure LinuxではDNFを使用してパッケージを更新できます。最初にリポジトリ情報を更新します。

sudo dnf makecache --refresh

利用可能な更新を確認します。

sudo dnf check-upgrade rabbitmq-server

修正版が表示されたら更新します。

sudo dnf upgrade rabbitmq-server

トランザクションの確認画面では、更新後のRelease番号が 7.azl3 以上になっていることを確認してください。Azure LinuxではDNFによるパッケージ更新と、リポジトリメタデータや署名を利用したパッケージ検証が提供されています。(Microsoft Learn)

更新後のRPMを確認します。

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

期待する結果は次のとおりです。

rabbitmq-server-3.13.7-7.azl3.x86_64

3.13.7-8 など、Release番号が7より新しいパッケージでも、修正を引き継いでいれば問題ありません。

RabbitMQを再起動する

RPMを更新しただけでは、すでにメモリへ読み込まれている旧コードが動作し続ける可能性があります。更新後はRabbitMQを再起動します。

sudo systemctl restart rabbitmq-server

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

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

続いてRabbitMQの診断コマンドを実行します。

sudo -u rabbitmq rabbitmq-diagnostics -q ping
sudo -u rabbitmq rabbitmq-diagnostics -q check_running
sudo -u rabbitmq rabbitmq-diagnostics -q check_local_alarms
sudo -u rabbitmq rabbitmq-diagnostics -q listeners

CLIでErlang Cookieに関するエラーが発生する場合は、RabbitMQサービスと同じCookieへアクセスできるユーザーで実行してください。通常は sudo -u rabbitmq を使用します。

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

MSRCで修正版が案内されていても、組織内のミラーやキャッシュへ反映されていない場合があります。

次の点を確認してください。

  • Azure Linux 3.0用のMicrosoftリポジトリが有効か
  • プロキシやリポジトリミラーが古いメタデータを保持していないか
  • 社内リポジトリへの同期が完了しているか
  • バージョン固定や除外設定がないか
  • DNFのキャッシュを更新したか

リポジトリ一覧は次のコマンドで確認できます。

sudo dnf repolist

キャッシュに問題がある場合は、再生成します。

sudo dnf clean all
sudo dnf makecache --refresh

非公式サイトから入手したRPMを直接インストールするのは避けてください。依存関係や署名を検証できず、別の改ざんリスクを持ち込む可能性があります。

RabbitMQクラスタは1台ずつローリング更新する

複数ノードのRabbitMQクラスタでは、すべてのノードを同時に再起動してはいけません。クォーラムキューやストリームの可用性を維持しながら、1台ずつ更新します。

3ノード構成であれば、原則として常に2ノード以上を稼働させます。RabbitMQ公式ドキュメントでも、更新前に対象ノードがクォーラム維持に不可欠な状態ではないことを確認する手順が案内されています。(RabbitMQ)

対象ノードで次のコマンドを実行します。

sudo -u rabbitmq rabbitmq-diagnostics -q check_if_node_is_quorum_critical

一般的な更新順序は次のとおりです。

順序作業
1クラスタ全体の状態とアラームを確認
2対象ノードがクォーラム維持に不可欠でないことを確認
31台目の rabbitmq-server を更新
41台目を再起動
5クラスタへの復帰、キュー、ストリーム、リスナーを確認
6クライアントの再接続と送受信を確認
7問題がなければ次のノードを更新

各ノードの更新後に、少なくとも次の確認を行います。

sudo -u rabbitmq rabbitmqctl cluster_status
sudo -u rabbitmq rabbitmq-diagnostics -q check_running
sudo -u rabbitmq rabbitmq-diagnostics -q check_local_alarms

クォーラムキューやストリームのレプリカ数が少ない環境では、ノード停止によって可用性を失うことがあります。パッケージ更新だけでなく、レプリカ配置とクラスタ構成も確認してください。

コンテナ環境ではホスト側の更新だけでは直らない

RabbitMQをAzure Linux 3.0ベースのコンテナ内で動かしている場合、ホストOSで dnf upgrade rabbitmq-server を実行しても、コンテナ内のパッケージは更新されません。

次の場所を区別して確認します。

rpm -q rabbitmq-server
  • Azure VMのホスト上で直接稼働している場合は、ホストのRPMを更新する
  • コンテナ内で稼働している場合は、コンテナイメージ内のRPMを更新する
  • Kubernetes環境では、修正版を含むイメージを再ビルドしてローリング展開する
  • 既存コンテナへ一時的にパッチを当てるだけでなく、Dockerfileやビルドパイプラインを修正する

公式RabbitMQコンテナなど、Azure LinuxのRPMを使用していない環境では、3.13.7-7.azl3 は判断基準になりません。イメージ提供元のセキュリティ情報とRabbitMQ上流版の修正状況を確認してください。

更新までに実施できる一時対策

MSRCはCVE-2026-57220について個別の回避策を掲載していません。以下は脆弱なコードを修正するものではなく、更新までの間に攻撃面を狭めるための一時措置です。(Microsoft Security Response Center)

Streamを使用していなければプラグインを無効化する

専用のRabbitMQ Streamプロトコルを使用していない場合は、rabbitmq_stream プラグインを無効にします。

sudo rabbitmq-plugins disable rabbitmq_stream

無効化後は、リスナーが消えたことを確認します。

sudo -u rabbitmq rabbitmq-diagnostics -q listeners
sudo ss -lntp | grep ':5552'

専用Streamクライアントを利用している場合は接続できなくなるため、無効化前にアプリケーションへの影響を確認してください。

リスナーのバインド先を限定する

同一ホストからしか利用しない場合は、Streamリスナーをループバックアドレスへ限定できます。

stream.listeners.tcp.1 = 127.0.0.1:5552

リモート接続が必要な場合は、必要なプライベートIPだけへバインドします。RabbitMQのStreamプラグインは、設定しなければ標準的には5552番ポートで全インターフェースを待ち受けるため、利用目的に合わせたバインド先の明示が重要です。(RabbitMQ)

設定変更後はRabbitMQを再起動し、実際のリスナーを確認してください。

Azure NSGとファイアウォールで接続元を限定する

Azure VMの場合は、Network Security Group、Azure Firewall、ロードバランサー、ホストファイアウォールを確認します。

Streamリスナーのポートについて、次のように制限してください。

  • インターネットからの受信を拒否する
  • RabbitMQを利用するアプリケーションのサブネットだけを許可する
  • 管理端末や踏み台サーバーから不要な接続を許可しない
  • IPv4だけでなくIPv6の経路も確認する
  • パブリックロードバランサーのバックエンドポートを確認する
  • カスタムポートを使用している場合は、そのポートを制限する

Streamクライアントがクラスタ内の各ノードへ直接接続する構成では、制限を強くしすぎると再接続やトポロジー取得が失敗することがあります。許可対象は単一のロードバランサーだけでなく、実際のクライアント接続経路を基準に決めてください。

フレームサイズ設定だけを対策にしない

この脆弱性の原因は、設定されたフレームサイズ制限が認証前の処理で適切に適用されないことです。そのため、通常のフレーム上限を小さく設定するだけでは、確実な対策になりません。(GitHub)

同様に、次の設定だけで安全と判断しないでください。

  • 強力なRabbitMQユーザーパスワード
  • 仮想ホストのアクセス権
  • 通常のサーバー証明書によるTLS
  • RabbitMQのメモリアラーム
  • HTTP向けWAF
  • 低いコンテナメモリ上限

通常のユーザー認証は問題が起きる段階より後で行われます。サーバー証明書だけのTLSも、接続元を認証前に排除する仕組みではありません。mTLSやネットワークファイアウォールで接続元を事前に限定すれば露出は減らせますが、修正版への更新は必要です。

更新後に確認すべき項目

更新が成功したかどうかは、RPMのバージョンだけでなく、稼働中のRabbitMQとアプリケーション通信まで確認します。

パッケージとサービスを確認する

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

sudo systemctl is-active rabbitmq-server

sudo -u rabbitmq rabbitmq-diagnostics -q ping
sudo -u rabbitmq rabbitmq-diagnostics -q check_running
sudo -u rabbitmq rabbitmq-diagnostics -q check_local_alarms

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

確認項目正常な状態
RPM3.13.7-7.azl3以上
systemdactive
ping成功
check_runningノードが稼働中
local alarmsメモリ・ディスクアラームなし
listeners必要なポートだけが待ち受け
cluster_status全ノードが想定どおり参加

実際のStream通信を確認する

Streamを業務で使用している場合は、診断コマンドだけで終わらせず、アプリケーションから確認します。

  • Streamクライアントが再接続できる
  • Producerがメッセージを送信できる
  • Consumerがメッセージを取得できる
  • 接続先ノードが切り替わっても再接続できる
  • 認証エラーやタイムアウトが増えていない
  • メッセージの遅延やバックログが増えていない

RabbitMQの起動に成功していても、ファイアウォール、プラグイン、リスナー設定の変更によってStreamクライアントだけが接続できなくなる場合があります。

メモリ枯渇攻撃の兆候を確認する

更新前に不審なメモリ増加やサービス停止が発生していた場合は、ホストとRabbitMQのログを確認します。

RabbitMQのメモリ内訳を確認する

sudo -u rabbitmq rabbitmq-diagnostics -q memory_breakdown --unit MB

connection_readers など、接続処理に関連するメモリが短時間で増えていないか確認します。RabbitMQ公式の診断コマンドでは、接続、プロセス、バイナリ、キューなどのカテゴリ別にメモリ使用量を確認できます。(RabbitMQ)

systemdとOOMの記録を確認する

sudo journalctl -u rabbitmq-server --since "1 hour ago" --no-pager

sudo dmesg -T | grep -Ei 'out of memory|oom|killed process'

次のような事象がないか確認します。

  • RabbitMQプロセスの突然の終了
  • systemdによる繰り返し再起動
  • OOM KillerによるErlangプロセスの終了
  • 短時間でのホストメモリ使用率上昇
  • Streamポートへの大量の同時接続
  • 接続直後に切断される通信の急増

接続状態は次のコマンドでも確認できます。

sudo ss -antp | grep ':5552'

ただし、CVE-2026-57220専用の一意なログメッセージが必ず残るとは限りません。メモリ不足が発生していたからといって、この脆弱性が悪用されたと断定することもできません。通信ログ、Azureのフローログ、ホストメトリクス、RabbitMQログを組み合わせて判断してください。

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

RabbitMQが3.13.7だから修正済みだと思う

Azure Linuxでは、上流バージョンだけでなくRPMのRelease番号を確認します。

3.13.7-6.azl3  脆弱
3.13.7-7.azl3  修正済み

3.13.7 という表示だけでは判別できません。

パッケージ更新後に再起動しない

ディスク上のファイルが更新されても、稼働中のErlang VMが旧コードを読み込んだままの場合があります。更新後はRabbitMQを再起動し、診断コマンドで確認してください。

5552番が閉じているだけで安全と判断する

Streamのポート番号は変更できます。ss で5552番だけを確認するのではなく、rabbitmq-diagnostics listeners でプロトコルと実際のリスナーを確認します。

社内ネットワークだから更新を後回しにする

未認証で成立する脆弱性は、侵害された社内端末や別のサーバーから悪用される可能性があります。ネットワーク分離は重要ですが、パッチ適用の代わりにはなりません。

ホストだけを更新してコンテナを見落とす

実際にRabbitMQが動いている場所で rpm -q rabbitmq-server を実行してください。コンテナイメージ内の古いRPMは、ホストの更新では置き換わりません。

上流版4.2.6へ直接置き換える

Azure Linuxのディストリビューションパッケージを使用している場合は、Microsoftが提供する 3.13.7-7.azl3 以上へ更新します。大きなバージョン変更は、セキュリティ更新とは別のアップグレード計画として扱ってください。

CVE-2026-57220対応で今すぐ行うこと

CVE-2026-57220は、RabbitMQ Streamの認証前処理を利用してメモリを消費させる、未認証DoS脆弱性です。Azure Linux 3.0で rabbitmq-server-3.13.7-6.azl3 を使用している場合は、次の順番で対応してください。

  • rpm -q でRPMのRelease番号を確認する
  • rabbitmq_stream と実際のリスナーを確認する
  • 到達可能なStreamポートをNSGやファイアウォールで限定する
  • rabbitmq-server-3.13.7-7.azl3 以上へ更新する
  • RabbitMQを再起動する
  • クラスタでは1台ずつローリング更新する
  • 更新後にパッケージ、サービス、クラスタ、Stream通信を確認する
  • コンテナ環境では修正版を含むイメージを再ビルドする

MSRCに個別の回避策が掲載されていない以上、Streamを使用していない場合の無効化やネットワーク制限は、一時的な露出低減策にすぎません。最終的には修正版の導入と再起動まで完了させることが重要です。

Azure
脆弱性 RabbitMQ Azure Linux DoS CVE-2026-57220

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次