SDDC ManagerのBrotli脆弱性に暫定対策 9.1.1と旧系列で異なる手順を確認

Google Cloudは2026年11月5日、VMware solution on Google Cloudの一部構成が、SDDC Managerに含まれるNode.jsのBrotli脆弱性の影響を受けると案内しました。Webサービスを載せる仮想基盤を自社で管理している場合、アプリ側のNode.js更新とは別に、基盤の管理アプライアンスを確認してください。

対象のCVE-2026-111497について、11月8日に確認したBroadcomの勧告は修正パッチを待つ状態で、暫定回避策を案内しています。SDDC Manager 9.1.1.xとそれ以前の対象系列では手順が異なります。適用前に系列を特定し、作業後の動作確認と、次のアップグレード後の再点検まで計画する必要があります。

同じBrotliでもSDDC Managerは別の対応対象

BroadcomのVMSA-2026-0008.1は、SDDC ManagerのBrotliデコーダーに境界外書き込みによるコード実行の可能性があると説明しています。管理面へネットワーク到達できる攻撃者が対象です。9.1.1の評価はCVSS 3.1で9.8、9.0.x・9.1.0・5.2.xは7.5で、構成ごとの評価を区別しています。

本記事で示す9.8はSDDC Manager 9.1.1に対する値です。Brotliを含むすべての製品に同じ点数を当てはめるものではありません。勧告の応答表は対象系列を挙げていますが、回避策の手順書が自分のビルドを対象にしているかも確認し、不一致があればBroadcomのサポートへ照会します。

Node.jsの10月21日の公式告知では、細工したBrotliデータが解凍処理へ届くことが原因となり、メモリー破損からクラッシュ、情報開示、コード実行につながる可能性を説明しています。CVEはこの時点で公表済みで、Broadcomの勧告は10月27日公開・28日改訂、今回のGoogle Cloudの案内は11月5日です。新しいCVEの発生と混同しないでください。

Google Cloudの二つの提供形態を区別する

Google CloudのGCP-2026-079は、VMware Cloud Foundation 9.1.xで動くVMware solution on Google Cloudを対象とし、Google Cloud VMware Engineは影響を受けないと明記しています。似たサービス名を一括して「Google CloudのVMware」と呼ぶと、不要な作業依頼や対象の取りこぼしにつながります。

運用担当者は、契約しているサービス名、管理アプライアンスの製品と版、作業権限を持つ組織を対応付けます。基盤を委託しているなら、本記事の手順を利用者が直接実行するのではなく、提供元に当該勧告への対応状況を確認します。ホスト上のWebアプリ担当と、仮想基盤の管理者が異なる場合も、確認先を分けましょう。

自社のアプリサーバーでNode.jsを更新した記録は、SDDC Managerの対策完了を示しません。反対に管理アプライアンスへ回避策を入れても、ゲストOS内のNode.jsやPythonの依存関係は別に残ります。資産一覧では、同じCVEに対する作業を製品ごとに分け、完了の証拠を共有します。

系列に合う公式手順を選ぶ

SDDC Manager	公式の案内先	主に点検する経路
9.1.1.x	KB 460732	nginx経由とUI直接の受信本文
5.2.x・9.0.x・9.1.0.x	KB 460734	UI側のBrotli解凍機能と起動設定
5.1.x以前	両KBでは影響なしと記載	今回の手順を機械的に適用しない

この表は回避策を選ぶ入口です。公式KBの見出しやEnvironment欄では、旧系列について5.2.4、9.0.2、9.1.0などの具体的な版も示されています。一方、追加情報には系列全体の説明があります。表に系列名があることだけで任意のビルドへ適用できるとせず、実際の版をスクリプトの確認処理とサポート情報で照合してください。

Web基盤を支える管理面なので、稼働中の作業との衝突も確認します。基盤のアップグレード、ワークロードドメインの操作、証明書交換を進めている最中なら、どこで作業を止めて切り替えるかを管理者と決めます。回避策を急ぐ場合も、復旧用のバックアップと管理接続を確保してから着手します。

9.1.1.xは443番だけの遮断で完了にしない

Broadcom KB 460732の手動手順は、nginxの443番経路でBrotliの要求本文を拒否する設定と、UIサーバーへの直接経路を保護する設定を組み合わせます。nginxだけでは127.0.0.1:7500への直接要求を見られないためです。対策は圧縮形式を申告するContent-Encodingに関係し、通常の応答圧縮を一括停止する話ではありません。

同KBの確認では、Brotliとして申告した本文が両経路で415となり、通常のJSONは同じ拒否を受けないことを確かめます。ログインしていない通常要求の401や403と、本文形式を拒否した415は意味が違います。画面が開くことと、対象の入力が解凍処理の前で止まることを分けて記録します。

適用方法には公式添付スクリプトと手動設定があります。いずれか一方を使い、戻す際も適用時の方式を合わせます。手動設定済みの環境へ、確認せず自動手順を重ねないでください。本文では変更コードを抜粋して再配布せず、現行KBを開いて、対象ファイル・配置場所・復旧手順を一組で確認する方法を勧めます。

旧系列へ9.1.1用の変更を流用しない

Broadcom KB 460734は、旧系列に対してUIサービスのNode.js起動時に読み込ませるファイルを追加し、Brotli解凍の生成機能を取り除く別方式を示しています。9.1.1.xへこの方式を適用しないよう明記されています。UIへの受信要求を止める手順と、解凍機能を変える手順を同じ設定として扱わないことが重要です。

確認項目には、対象サービスの環境変数が主プロセスと子プロセスへ反映されていること、InventoryとDomainsのページが開くこと、再起動後にBrotliや解凍に関するエラーが出ていないことが含まれます。設定ファイルへ一行を書いただけでは、起動済みのプロセスが新しい条件で動いている証拠にはなりません。

現場では、設定した担当者と確認した担当者が違っても追える記録を用意します。対象アプライアンス、適用したKB、適用方式、再起動時刻、確認したプロセス、画面の結果を対応付けます。自動処理の終了コードだけで判断せず、通常機能が維持されたかまで確認してください。本サイトで実機へ回避策を適用した実測結果ではありません。

アップグレードの予定に再確認を組み込む

両KBは、未修正のNode.jsを含むリリースへアップグレードすると回避策が外れる点を説明しています。その場合は、アップグレード後に確認処理からやり直します。修正を含むリリースなら回避策は不要になりますが、今回確認した勧告の応答表はPatch pendingであり、将来の提供予定を修正済みとは扱えません。

本サイトの提案は、更新チケットに「更新前の回避策」「更新先の修正有無」「更新後の再確認」の三項目を残すことです。保守担当が交代しても、以前は保護できていた入力経路が再び有効にならないようにします。定例更新と緊急回避策の記録が別々にあるなら、互いのチケットを参照できる状態にします。

パッチが公開された際は、提供元が当該CVEを修正したと明示した製品版を確認し、暫定変更をどう扱うかも最新KBで読み直します。OSの汎用パッケージ管理でNode.jsだけを独自に交換すると、製品としての動作やサポート条件を崩す可能性があるため、製品向け手順に沿って移行することを勧めます。

悪用確認と自社の侵害判断は分ける

CISAの公式KEVデータでは、CVE-2026-111497は10月27日追加、ランサムウェア利用はUnknownです。確認したcatalogVersionは2026.11.06でした。これは脆弱性全体の悪用確認であり、自社のSDDC ManagerやGoogle Cloud上の特定環境が侵害されたと示す記録ではありません。

優先順位を付けるときは、管理面へ到達できる範囲、対象系列、回避策の実施状況を照合します。管理アクセスを必要な接続元へ絞る案も考えられますが、それだけでBrotliの処理経路をすべて塞げたと判断せず、製品の暫定策を実施します。変更前後の接続要件は管理者と確認してください。

不審な管理アクセス、UIの異常終了、予期しない外部接続などがあれば、時刻と対象をそろえて記録を保全し、基盤管理者や提供元と調査します。単一の解凍エラーだけで悪用成立とは断定しません。また、回避策が有効になったことは、すでに起きた不正な変更が消えたことを意味しないため、予防と調査の記録を分けます。

完了条件はアプライアンスごとに残す

今回の作業は、対象があるか調べる段階、公式の暫定策を入れる段階、正常機能と拒否動作を確認する段階、正式修正へ移る段階に分けると管理しやすくなります。委託環境では、対応中・適用済み・対象外の理由を製品名と版付きで受け取り、単なる「クラウド側対応済み」という回答で閉じない運用が有用です。

待機系や検証用アプライアンスも、業務ネットワークから到達できるなら同じ一覧へ加えます。正常に利用されていない環境ほど、更新担当が曖昧になりがちです。対象数、確認できた数、保留した理由を残し、未確認の一台を他の一台の成功で埋めないようにします。

Webサービス担当者が今行う判断は、自分たちの仮想基盤にSDDC Managerが含まれるかを確認し、管理者へ系列別の対応を依頼することです。同じCVEのNode.js更新が終わっていても、製品固有の暫定策と更新後の再確認は別に必要です。正式修正の提供状況が変わった際も、同じ資産記録で追跡しましょう。

関連記事

Node.jsのBrotli修正と本番・CIのランタイム更新は、アプリ側の更新を扱います。SDDC Managerは本稿の製品別手順で別途確認してください。