CVE-2026-57211とは？RabbitMQ管理UIのUNC SSRFと修正版3.13.7-7

Azure Linux 3.0で rabbitmq-server 3.13.7-6 を使用している場合、CVE-2026-57211への基本対応は、修正版の3.13.7-7以降へ更新することです。MSRCは個別の回避策を示していないため、管理UIを外部から遮断するだけでは正式な対応になりません。パッケージ更新後はRabbitMQを再起動し、実行中のプロセスが修正済みコードを読み込んだことまで確認する必要があります。(Microsoft Security Response Center)

CVE-2026-57211は、RabbitMQ管理UIがUNC形式として解釈できるパスを処理する際、意図しない外向き通信が発生する可能性があるSSRF脆弱性です。上流の攻撃シナリオはWindows固有のUNC、DNS、SMB処理を前提としていますが、Azure Linux側では該当コードへの修正がバックポートされています。そのため、「Linuxなので関係ない」と判断せず、MSRCが示すAzure Linuxパッケージの修正版を適用することが実務上の正しい対応です。(GitHub)

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

CVE-2026-57211について、Azure Linux 3.0の管理者が最初に確認すべき内容は次のとおりです。

項目	内容
脆弱性	RabbitMQ管理UIにおけるUNCパス処理のSSRF
対象ディストリビューション	Azure Linux 3.0
対象パッケージ	`azl3 rabbitmq-server`
MSRC掲載バージョン	`3.13.7-6`
修正版	`3.13.7-7`
上流での主な影響	UNC解決に伴うDNS・SMB通信、Windows環境でのNTLM情報漏えいやリレーの可能性
認証の要否	上流アドバイザリでは認証不要
MSRCの回避策	個別の回避策は掲載されていない
推奨対応	`3.13.7-7`以降への更新とRabbitMQの再起動

ここでいう 3.13.7-7 の末尾の -7 は、RabbitMQ本体の新しい上流バージョン番号ではなく、Azure Linux向けRPMパッケージのリリース番号です。たとえば、更新後のRPM名は環境やアーキテクチャによって次のように表示されます。

rabbitmq-server-3.13.7-7.azl3.x86_64

したがって、RabbitMQコマンドで表示される製品バージョンが引き続き 3.13.7 であっても、RPMのリリース部分が -7.azl3 以降なら、Azure Linux向け修正が適用されている可能性があります。確認するときは、製品バージョンだけでなくRPMの完全なバージョンを確認してください。

RabbitMQ管理UIのUNC SSRFとは

一般的なHTTP型SSRFとは挙動が異なる

SSRFは、サーバー側の機能を利用して、本来アクセスさせるべきでないネットワーク上の宛先へ通信させる脆弱性です。

ただし、CVE-2026-57211は、入力されたURLを使って任意のWebサイトへアクセスする典型的なHTTP型SSRFとは異なります。RabbitMQ管理UIが受け取ったパスをファイルパスとして処理し、Windows上でUNCパスとして解釈されることにより、外部ホストへのDNS名前解決やSMB接続が発生するタイプです。

UNCパスは、Windowsでネットワーク共有を表すために使用される次のような形式です。

\\server-name\shared-folder

上流のRabbitMQアドバイザリによると、URLエンコードされたバックスラッシュがWebサーバー側でデコードされ、適切なパス検証より前にファイル情報確認処理へ渡されることが問題でした。Windowsでは、その処理がUNCパスの解決につながり、攻撃者が制御するホストへのDNSやSMB通信が発生する可能性があります。(GitHub)

管理UIと追加プラグインの組み合わせが成立条件になる

上流アドバイザリでは、管理UIの静的ファイル処理に複数のローカルパスが登録される構成で、問題のある処理経路に入ると説明されています。

具体的には、rabbitmq_management に加えて、管理UIを拡張するプラグインが少なくとも1つ有効になっている構成が該当し得ます。例として、次のプラグインが挙げられています。

rabbitmq_shovel_management
rabbitmq_federation_management
rabbitmq_tracing
rabbitmq_top
rabbitmq_stream_management

管理UI自体が1つのパスを登録し、追加プラグインが別のパスを登録することで、上流アドバイザリが示す複数パスの条件を満たす可能性があります。また、脆弱な処理経路については認証不要とされているため、「管理画面にはログインが必要だから問題ない」という判断はできません。(GitHub)

Windows向けの問題がAzure Linuxに掲載される理由

CVE-2026-57211を調べると、上流RabbitMQの説明ではWindows環境が中心で、修正版もRabbitMQ 4.1.11および4.2.6とされています。一方、MSRCはAzure Linux 3.0のRabbitMQ 3.13.7パッケージに対して、3.13.7-7を修正版として示しています。(GitHub)

両者は次のように整理できます。

観点	上流RabbitMQ	Azure Linux 3.0
明示されている製品系列	RabbitMQ 4.1、4.2	RabbitMQ 3.13.7のAzure Linuxパッケージ
修正版	4.1.11、4.2.6	`3.13.7-7.azl3`
主な攻撃シナリオ	WindowsのUNC・DNS・SMB処理	対応コードをAzure Linuxパッケージへバックポート
管理者が基準にする情報	上流アドバイザリ	MSRCとAzure Linuxリポジトリのパッケージ情報

Azure Linuxの修正作業では、公開データベース上でRabbitMQ 3.13.7が明示的な対象になっていない一方、対象となる処理コードが3.13.7系のブランチにも存在するため、修正を適用したことが説明されています。Azure Linux上でWindowsと同じNTLM漏えいやSMBリレーがそのまま成立すると断定することはできませんが、コードレベルの対策として修正済みパッケージへ更新する必要があります。(GitHub)

このようなケースでは、上流製品のバージョン表だけを見て対象外と判断してはいけません。Linuxディストリビューションは、上流の修正を古い製品系列へバックポートし、RPMのリリース番号だけを更新することがあります。Azure Linuxを運用している場合は、MSRCとディストリビューション側のパッケージ番号を優先して確認してください。

自分のAzure Linux環境が対象か確認する手順

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

最初に、OSとインストール済みRPMの情報を確認します。

cat /etc/os-release

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

対象となる表示例は次のとおりです。

rabbitmq-server-3.13.7-6.azl3.x86_64

この場合はMSRCが示す修正版より古いため、更新対象です。

更新後に次のように表示されれば、修正版のRPMリリースがインストールされています。

rabbitmq-server-3.13.7-7.azl3.x86_64

3.13.7-8など、修正を含む後続リリースが提供されている場合は、通常は後続リリースを適用します。ただし、独自リポジトリや社内ミラーを使用している環境では、提供元の更新情報も併せて確認してください。

有効な管理プラグインを確認する

次のコマンドで、有効になっているRabbitMQプラグインを名前だけ表示できます。

sudo rabbitmq-plugins list -e -m

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

rabbitmq_management
rabbitmq_management_agent
rabbitmq_web_dispatch
rabbitmq_federation
rabbitmq_federation_management

この例では、管理UIに加えて rabbitmq_federation_management が有効です。上流アドバイザリで説明されている複数の管理拡張パスが構成される可能性があるため、更新の優先度を上げるべき環境です。rabbitmq-plugins list -e は、明示的または依存関係によって有効になっているプラグインを確認するための公式な方法です。(RabbitMQ)

管理UIの待受状態を確認する

RabbitMQ管理UIの標準ポートは、HTTPが15672、HTTPSが15671です。実際の待受状態は次のように確認できます。

sudo ss -lntp | grep -E ':(15671|15672)\b'

何も表示されない場合でも、ポート番号が変更されている可能性があります。次の設定ファイルも確認してください。

sudo grep -RIn 'management' /etc/rabbitmq/

管理UIが待ち受けていることだけで、直ちにインターネットへ公開されているとは限りません。次の経路も併せて確認します。

Azure Network Security Group
ホスト側のファイアウォール
ロードバランサー
リバースプロキシ
VPNや管理用ネットワーク
コンテナやKubernetesのService、Ingress

管理UIの標準ポートはRabbitMQの公式ネットワークドキュメントでも15672および15671として案内されています。(RabbitMQ)

状況別の対応優先度

現在の状態	対応判断
`3.13.7-6`で管理UIと追加管理プラグインが有効、外部から到達可能	最優先で更新。更新まで外部公開を停止する
`3.13.7-6`で管理UIは社内ネットワーク限定	早期に更新。社内限定を理由に先送りしない
`3.13.7-6`だが管理UIは無効	攻撃経路は限定されるが、計画的に更新する
`3.13.7-7`以降だがサービスを再起動していない	再起動して修正済みコードを読み込ませる
`3.13.7-7`以降で再起動・動作確認済み	ログ監視と構成確認を継続する

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

更新前に定義と設定を退避する

RabbitMQのdefinitionsには、ユーザー、仮想ホスト、権限、ポリシー、交換機、キューなどの構成情報が含まれます。更新前には、最低限の構成バックアップを取得しておくと復旧しやすくなります。

STAMP=$(date +%F-%H%M%S)

sudo rabbitmqctl export_definitions \
  "/root/rabbitmq-definitions-${STAMP}.json"

sudo tar -C / -czf \
  "/root/rabbitmq-config-${STAMP}.tgz" \
  etc/rabbitmq

sudo chmod 600 \
  "/root/rabbitmq-definitions-${STAMP}.json" \
  "/root/rabbitmq-config-${STAMP}.tgz"

definitionsのエクスポートにはパスワードハッシュなどの機密情報が含まれる可能性があります。バックアップファイルは一般ユーザーが読み取れない場所に保存し、作業後の保管期間も決めてください。

RabbitMQの公式ドキュメントでは、definitionsのエクスポートが構成バックアップの方法として案内されています。一方、稼働中のRabbitMQデータディレクトリを単純にコピーする方法は、一貫性のないバックアップになる可能性があるため避けるべきです。(RabbitMQ)

tdnfでパッケージを更新する

Azure Linuxでは、パッケージ管理にTiny DNFである tdnf を使用します。まずメタデータを更新し、その後RabbitMQパッケージを更新します。

sudo tdnf makecache
sudo tdnf upgrade rabbitmq-server

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

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

期待する表示は、次のいずれかです。

rabbitmq-server-3.13.7-7.azl3.x86_64

または、修正を含むそれ以降のAzure Linux向けリリースです。

tdnf upgrade rabbitmq-serverを実行しても 3.13.7-6のままの場合は、次の点を確認してください。

Azure Linux 3.0向けの正しいリポジトリが有効か
社内ミラーへの同期が完了しているか
パッケージがバージョン固定されていないか
古いコンテナイメージやVMイメージを参照していないか
リポジトリメタデータのキャッシュが残っていないか

Azure Linuxでは、他のディストリビューションにおけるパッケージ更新に相当する操作として tdnf upgrade が使用されます。tdnf makecacheは、リポジトリのメタデータキャッシュを更新するコマンドです。(Microsoft Learn)

RabbitMQを再起動する

RPMファイルを更新しただけでは、すでにメモリへ読み込まれているRabbitMQのコードが修正版へ切り替わったことを保証できません。メンテナンス手順に従ってRabbitMQサービスを再起動します。

sudo systemctl restart rabbitmq-server

再起動後は、サービスの状態を確認します。

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

クラスター構成の場合は、クラスター状態も確認してください。

sudo rabbitmqctl cluster_status

RPMベースのLinux環境では、RabbitMQサービスは通常 rabbitmq-server というsystemdサービスとして管理されます。(RabbitMQ)

更新後の確認項目

パッケージ更新を完了扱いにする前に、次の項目を確認します。

確認項目	合格条件
RPMバージョン	`3.13.7-7.azl3`以降
サービス状態	`active`
RabbitMQ診断	`rabbitmq-diagnostics status`が正常終了
クラスター状態	想定した全ノードが参加
管理UI	許可された管理端末からのみアクセス可能
アプリケーション接続	PublisherとConsumerが正常に再接続
監視	キュー滞留、接続数、エラー率に異常がない
ログ	起動失敗、プラグイン読込失敗、設定エラーがない

更新直後に管理画面が表示できることだけを確認して終わるのは不十分です。RabbitMQを使用するアプリケーションからの接続、メッセージ送受信、クラスター参加状態まで確認してください。

クラスターとコンテナ環境での注意点

クラスターでは全ノードを確認する

RabbitMQクラスターでは、1台だけを更新しても、ほかのノードに 3.13.7-6 が残っていれば対応は完了していません。

各ノードで次のコマンドを実行し、インストール済みRPMを確認します。

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

ノードを1台ずつ更新するローリング方式を採用できるかは、キューの複製方式、クォーラムキューの状態、接続先の冗長化、ロードバランサーの設定によって異なります。十分な冗長性を確認せずにノードを停止すると、メッセージ処理が中断する可能性があります。

単一ノード構成ではサービス再起動中に停止時間が発生するため、利用部門とメンテナンス時間を調整してください。

コンテナではホストではなくイメージを更新する

RabbitMQがコンテナ内で動作している場合、Azure Linuxホスト上の rabbitmq-server RPMを更新しても、コンテナ内部のパッケージは更新されません。

確認すべき対象は次のように異なります。

配置方式	更新対象
Azure Linux VMへRPMを直接導入	VM上の `rabbitmq-server`
DockerまたはPodmanコンテナ	コンテナイメージ内のRPM
Kubernetes上のRabbitMQ	StatefulSetなどが参照するコンテナイメージ
独自ビルドイメージ	Dockerfile、Containerfile、SBOM、ビルド済み成果物

コンテナの場合は、稼働中のコンテナへ一時的にパッケージを上書きするのではなく、修正版を含むイメージを再ビルドし、レジストリへ登録して再デプロイします。再作成後のコンテナ内でRPMバージョンを確認し、古いPodやコンテナが残っていないことまで確認してください。

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

MSRCはCVE-2026-57211に対する個別の回避策を掲載していません。そのため、以下は正式な修正ではなく、更新までの暫定的なリスク低減策です。(Microsoft Security Response Center)

管理UIの到達元を制限する

管理UIの15672または15671番ポートをインターネットへ公開している場合は、公開を停止します。

アクセス元は、次のような管理経路に限定してください。

管理用サブネット
踏み台サーバー
VPN接続元
Zero Trust型アクセスプロキシ
指定した運用端末のIPアドレス

Azure上では、NSGだけでなくロードバランサー、Application Gateway、リバースプロキシ、KubernetesのIngressなど、実際に通信を受け付けるすべての経路を確認します。

不要な管理拡張プラグインを見直す

使用していない管理拡張プラグインが有効になっている場合は、依存関係と運用影響を確認したうえで無効化を検討します。

ただし、プラグインの無効化により、フェデレーション、Shovel、トレーシング、監視画面などの機能が利用できなくなる可能性があります。パッチを適用せず、プラグインの無効化だけで恒久対応とすることは避けてください。

外向き通信を制御する

上流のWindows向け攻撃シナリオでは、DNSとSMBによる外向き通信が重要になります。ネットワークポリシーとして、少なくとも次の制御を検討します。

インターネット向けTCP 445番ポートを遮断する
DNS通信を組織指定のリゾルバーだけに限定する
RabbitMQサーバーから不要な外向き通信を許可しない
NSGフローログやファイアウォールログを監視する

これらは多層防御として有効ですが、修正版パッケージへの更新を不要にするものではありません。

悪用が疑われる場合に確認するログ

管理UIが外部公開されていた、または不審なアクセスが確認された場合は、更新作業だけで終了せず、次の記録を保全して調査します。

リバースプロキシやロードバランサーのアクセスログ
WAFの検知ログ
RabbitMQのログ
DNSクエリログ
ファイアウォールやNSGのフローログ
外向きTCP 445番ポートの通信記録
管理UIへのアクセス元IPアドレス
URLエンコードされたバックスラッシュを含む異常なリクエストパス

上流のWindows環境では、外部SMB接続によるNTLMv2情報の漏えいや認証リレーが影響として挙げられています。組織内にWindows版RabbitMQも存在する場合は、Active DirectoryやWindowsセキュリティの担当者と連携し、認証情報の悪用可能性を別途評価してください。(GitHub)

本番環境で公開されている攻撃コードを実行し、脆弱性の有無を確かめる方法は避けるべきです。意図しない外向き通信や認証処理を発生させる可能性があるため、パッケージ番号、構成、到達性、ログを基に判断してください。

CVE-2026-57211対応で起こりやすい失敗

上流の4.xだけを見て対象外と判断する

上流アドバイザリの影響バージョンだけを見ると、RabbitMQ 3.13.7は対象外に見える可能性があります。しかし、Azure Linuxではディストリビューション独自のバックポート修正が提供されています。

Azure Linux 3.0の管理者は、MSRCが示す 3.13.7-6と3.13.7-7の比較を優先してください。

RabbitMQ本体のバージョンだけを確認する

更新前後でRabbitMQ本体のバージョンは、どちらも 3.13.7 と表示される可能性があります。重要なのはRPMリリース番号の -6と-7です。

次のような簡略表示だけではなく、RPMの完全な情報を確認します。

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

RPMを更新してサービスを再起動しない

ディスク上のパッケージだけが更新され、稼働中のRabbitMQプロセスが古いコードを保持している状態を避けるため、計画したサービス再起動と動作確認を実施します。

ログイン画面があるので安全だと判断する

上流アドバイザリでは、問題のあるリクエスト処理に認証は不要とされています。管理UIへ通常アクセスした際にログイン画面が表示されても、それだけでは脆弱な処理経路が保護されている証拠になりません。(GitHub)

ファイアウォール制限を修正版の代わりにする

到達元の制限は重要ですが、設定変更や別経路の追加によって再び露出する可能性があります。MSRCが個別の回避策を示していない以上、最終的な完了条件は修正版パッケージの適用です。

よくある質問

Azure LinuxではWindowsのUNC攻撃がそのまま成立しますか

上流で説明されているDNS、SMB、NTLMを含む攻撃連鎖はWindows固有の処理を前提としています。そのため、Azure Linux上で同一の影響がそのまま発生すると断定することはできません。

一方、MicrosoftはAzure Linux 3.0の該当パッケージに修正版を提供しています。直接的な影響の推測よりも、パッケージベンダーが示す修正状況を基準にして 3.13.7-7以降へ更新してください。

管理UIをインターネットへ公開していなければ更新は不要ですか

不要ではありません。外部公開されていない環境は攻撃可能性が下がりますが、社内端末、侵害済みホスト、VPN接続者、設定ミスによる再公開などの経路が残ります。

修正版が提供されているため、到達性の制限は更新までの暫定対策として扱い、計画的にパッケージを更新してください。

`3.13.7-7`はRabbitMQ 3.13.7.7という意味ですか

違います。3.13.7が上流のRabbitMQバージョン、後ろの -7がAzure Linux向けRPMのリリース番号です。

今回の修正では、上流RabbitMQのメジャーまたはマイナーバージョンを変更せず、修正コードをAzure Linuxの3.13.7系パッケージへ取り込んでいます。

OS全体の再起動は必要ですか

CVE-2026-57211への対応として重要なのは、修正版RPMをインストールし、RabbitMQプロセスを再起動することです。RabbitMQ以外の更新内容や組織の運用ルールによってOS再起動が必要になる場合はありますが、このパッケージ更新だけを理由に常にOS全体の再起動が必要とは限りません。

更新後も管理UIの公開制限は必要ですか

必要です。修正版を適用しても、RabbitMQ管理UIは管理者向けの機能であり、インターネットへ無制限に公開すべきではありません。

HTTPS、アクセス元制限、VPN、強力な認証、最小権限、ログ監視を組み合わせ、管理経路を継続的に保護してください。

まず実施すべき対応

CVE-2026-57211への対応は、次の順番で進めると判断を誤りにくくなります。

rpm -qで rabbitmq-server の完全なRPMバージョンを確認する
3.13.7-6.azl3であれば、管理UIの公開範囲を直ちに制限する
definitionsと設定ファイルをバックアップする
tdnfで 3.13.7-7.azl3以降へ更新する
RabbitMQサービスを再起動する
サービス、クラスター、アプリケーション接続、ログを確認する
クラスター全ノードやコンテナイメージに旧パッケージが残っていないか確認する

CVE-2026-57211では、Windows向けの上流説明とAzure Linuxのパッケージ情報を混同しないことが重要です。Azure Linux上でWindows固有の影響を過大評価する必要はありませんが、逆に「Linuxだから対象外」と判断することもできません。MSRCが示す rabbitmq-server 3.13.7-7以降への更新を完了条件とし、再起動と稼働確認まで一連の作業として実施してください。

この記事を書いた人

佐藤健司

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

CVE-2026-57211とは？RabbitMQ管理UIのUNC SSRFと修正版3.13.7-7

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

RabbitMQ管理UIのUNC SSRFとは

一般的なHTTP型SSRFとは挙動が異なる

管理UIと追加プラグインの組み合わせが成立条件になる

Windows向けの問題がAzure Linuxに掲載される理由

自分のAzure Linux環境が対象か確認する手順

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

有効な管理プラグインを確認する

管理UIの待受状態を確認する

状況別の対応優先度

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

更新前に定義と設定を退避する

tdnfでパッケージを更新する

RabbitMQを再起動する

更新後の確認項目

クラスターとコンテナ環境での注意点

クラスターでは全ノードを確認する

コンテナではホストではなくイメージを更新する

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

管理UIの到達元を制限する

不要な管理拡張プラグインを見直す

外向き通信を制御する

悪用が疑われる場合に確認するログ

CVE-2026-57211対応で起こりやすい失敗

上流の4.xだけを見て対象外と判断する

RabbitMQ本体のバージョンだけを確認する

RPMを更新してサービスを再起動しない

ログイン画面があるので安全だと判断する

ファイアウォール制限を修正版の代わりにする

よくある質問

Azure LinuxではWindowsのUNC攻撃がそのまま成立しますか

管理UIをインターネットへ公開していなければ更新は不要ですか

`3.13.7-7`はRabbitMQ 3.13.7.7という意味ですか

OS全体の再起動は必要ですか

更新後も管理UIの公開制限は必要ですか

まず実施すべき対応

この記事を書いた人

コメント

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

CVE-2026-57211とは？RabbitMQ管理UIのUNC SSRFと修正版3.13.7-7

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

RabbitMQ管理UIのUNC SSRFとは

一般的なHTTP型SSRFとは挙動が異なる

管理UIと追加プラグインの組み合わせが成立条件になる

Windows向けの問題がAzure Linuxに掲載される理由

自分のAzure Linux環境が対象か確認する手順

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

有効な管理プラグインを確認する

管理UIの待受状態を確認する

状況別の対応優先度

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

更新前に定義と設定を退避する

tdnfでパッケージを更新する

RabbitMQを再起動する

更新後の確認項目

クラスターとコンテナ環境での注意点

クラスターでは全ノードを確認する

コンテナではホストではなくイメージを更新する

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

管理UIの到達元を制限する

不要な管理拡張プラグインを見直す

外向き通信を制御する

悪用が疑われる場合に確認するログ

CVE-2026-57211対応で起こりやすい失敗

上流の4.xだけを見て対象外と判断する

RabbitMQ本体のバージョンだけを確認する

RPMを更新してサービスを再起動しない

ログイン画面があるので安全だと判断する

ファイアウォール制限を修正版の代わりにする

よくある質問

Azure LinuxではWindowsのUNC攻撃がそのまま成立しますか

管理UIをインターネットへ公開していなければ更新は不要ですか

3.13.7-7はRabbitMQ 3.13.7.7という意味ですか

OS全体の再起動は必要ですか

更新後も管理UIの公開制限は必要ですか

まず実施すべき対応

この記事を書いた人

関連記事

コメント

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

`3.13.7-7`はRabbitMQ 3.13.7.7という意味ですか

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