Cisco ASA・FTDの脆弱性で起きること

Ciscoは2026年10月28日（日本時間10月29日）に、ASAとFTDのリモートアクセスSSL VPNの脆弱性CVE-2026-76418を公表しました。トンネルグループに二次認証を設定したときの処理の誤りが原因で、SSL VPNへの接続時に細工した要求を送られると、機器が予期せず再起動し、サービス停止（DoS）になります。[1]

攻撃に認証は要りません。深刻度はCiscoの評価でCVSS 3.1の8.6（高）で、影響は可用性だけです。弱点の分類はCWE-690（戻り値を確かめずにNULLポインターを参照する）です。[1][3]

対象になる構成（SSL VPNと二次認証）

修正前のASA・FTDの版で、SSL VPNのログインが届き、トンネルグループに二次認証が設定されている機器が対象です。[1]

FTDのリモートアクセスVPNは、Secure Firewall Management Center（FMC）の Devices > VPN > Remote Access、またはSecure Firewall Device Manager（FDM）の Remote Access VPN で有効にします。FTDでは、展開したリモートアクセスVPNのポリシーと、機器の実行中の設定を確かめます。[1]

Ciscoは、Cloud-delivered Firewall（CDFW）、Cloud-delivered Firewall Management Center（cdFMC）、Secure Access、Secure FMC Softwareは対象外と確認しています。[1]

悪用の状況（KEV）

CiscoのPSIRTは、2026年10月にこの脆弱性の悪用を把握しました。[1]米CISAは10月29日（米国の日付）にKEVへ追加し、対応の期限を11月1日としました。[2][4]

攻撃の手口、被害の範囲、侵害の痕跡は、Ciscoの告知に記載がありません。[1]JPCERT/CC・IPAの注意喚起は出ていません（2026-11-02確認）。

外から見えているか

リモートアクセスSSL VPNは社外からの接続を受けるため、SSL VPNのログインが外から届く機器が対象になりえます。[1]

本社・拠点・クラウド上の仮想版（ASAv・Firepower NGFW Virtual）を含めてASA・FTDを一覧にし、SSL VPNを有効にしているインターフェースと、二次認証の有無を書き出します。保守を委託している機器も含めます。

対象と修正版（ASA・FTDの系列ごと）

修正版は系列ごとに違います。ASAは9.22系なら9.22.3.200、9.20系なら9.20.4.50、FTDは7.4系なら7.4.9、7.6系なら7.6.7が最初の修正版です。9.16より前のASAは9.16.4.104、7.0より前のFTDは7.0.11に上げます。[1]

Ciscoは、回避策や緩和策は修正版に上げるまでの一時的な策だとして、修正版への更新を強く勧めています。[1]

版の確かめ方と上げる手順

CiscoのSoftware Checkerで、ソフトウェア（ASA・FTD）、機種、今の版（ASAは9.20.3.4、FTDは7.4.2の形）を入れると、当てはまるアドバイザリと最初の修正版が出ます。ほかのアドバイザリもまとめて直る版（Combined First Fixed）も確かめられます。[1]

今の版は次の方法で確かめます。FTDは、機器のCLIでshow versionを実行すると、動いているFTDの版が出ます。[5]ASAをフェイルオーバーの組（Active/Standby）で使っている場合は、show failoverの出力のVersionの行（例：Version: Ours 9.16(4), Mate 9.16(4)）か、ASDMの Monitoring > Properties > Failover > Status で、2台の版を確かめられます。[6]単体のASAの版の確かめ方と更新の手順は、Ciscoの「Cisco Secure Firewall ASA Upgrade Guide」（日本語版「ASA のアップグレード」）にあります。[7]

1. 機器ごとに、ASAかFTDか、版、機種を確かめます。
2. Software Checkerで、今回の件とほかの重大・高のアドバイザリを合わせて確かめ、上げる先を決めます。
3. ASAは「Cisco Secure Firewall ASA Upgrade Guide」、FTDはFMCの更新の手引きに沿って上げます。アドバイザリが推奨リリースより新しい版を示すときは、アドバイザリに従います。[1][7]
4. 上げた後に、上の方法でもう一度版を確かめ、修正版以上になったかを確かめます。

保守の会社に頼むときは、機器と版、SSL VPNの有無、二次認証の有無（02の表）、上げる先（Software Checkerの結果）を伝え、上げるまでの間に緩和策を当てるかを決めます。

すぐに上げられないとき（二次認証を外す緩和策）

Ciscoは、回避策は無いとしたうえで、二次認証を外す緩和策を示しています。[1]

• 既定のDefaultWEBVPNGroupが二次認証を使っていない場合：WebVPNの設定モードでno tunnel-group-list enableを入れ、トンネルグループの一覧を無効にします。利用者は一覧から接続プロファイルを選べなくなり、正しいプロファイル名を知っている必要があります。
• DefaultWEBVPNGroupが二次認証を使っている場合：no secondary-authentication-server-groupで二次認証を外します。リモートアクセスVPNの安全性は下がります。

Ciscoは試験の環境で効果を確かめたとしつつ、機能・性能・安全性への影響を自社の環境で評価してから当てるよう求めています。[1]

BeyondTrust Remote Supportの脆弱性で起きること

CVE-2026-102764を悪用されると、遠隔の攻撃者に、Remote Supportの機器（アプライアンス）上でファイルを操作されるおそれがあります。Remote Supportの内部の部品が、受け取ったメッセージの送り元を十分に確かめていないことが原因で、条件がそろうとファイルの操作に使われます。BeyondTrustは2026年10月15日（米国の日付）に勧告BT26-05で公表し、CVSS v4の基本値を9.3（緊急）としています。[1][4]

米CISAはこの脆弱性を、緊急の認証の回避の脆弱性と説明しています。[2]Mandiantは、認証なしで機器上のファイルを操作でき、機器のroot権限の掌握と、機器が保存・中継するすべての認証情報への到達につながりうるとしています。[5]

対象になる製品と構成

対象は、Remote Supportの26.2.3以前のすべての版です。BeyondTrustの勧告とCVEの記録が対象に挙げている製品は、Remote Supportだけです。[1][4]

BeyondTrustのクラウドで動くRemote Support（SaaS）には、2026年10月9日にすべてパッチが当てられています。パッチの作業が要るのは、自社で設置した機器です。[1][2][5]

悪用の状況（KEV追加と米CISAの告知）

米CISAは2026年10月16日（米国の日付）、CVE-2026-102764をKEVへ追加し、同じ日に修正を促す告知を出しました。攻撃者はこの脆弱性を最初の侵入に使い、その後、居座り、権限の昇格、横への広がりを行っています。[2][3]

KEVでは、米国の連邦機関への対応期限を2026年10月19日とし、侵害の調査（Forensic Triage）の対象としています。ランサムウェアでの利用は不明としています。[3]

Mandiantは、インシデント対応の中で、中国とのつながりが疑われる攻撃者ARMORY CASTLE（旧称UNC5221）が、2026年8月下旬にこの脆弱性をゼロデイとして悪用していた証拠を見つけました。攻撃者はWebシェルを置いてroot権限を取り、機器の認証情報の保管庫を抜き出そうとし、機器のログを消していました。Mandiantは、公表の後に広い範囲で悪用される可能性があるとしています。[5]

JPCERT/CCの注意喚起の一覧には、2026年11月2日の時点でこの件はありません。

外から見えているか

米CISAは、Remote Supportの機器に外から届く範囲を、利用者や顧客の支援に要るサービスだけに絞り、管理画面への接続は信頼できるネットワークに限るよう求めています。[2]Mandiantは、管理画面（/login と /appliance）への接続をIPアドレスかネットワークで絞り、インターネットから届くのはサポート担当者のコンソール、顧客向けの窓口、Jump Clientの通信だけにするよう勧めています。[5]

まず、自社で設置したRemote Supportの機器がどこにあるか（社内、データセンター、クラウド上の仮想アプライアンス）と、どの名前・IPアドレスで外から見えているかを一覧にします。保守を委託している機器も含めます。Mandiantは、対象の版のままインターネットから届いていた機器は、調べ終わるまで侵害されたものとして扱うよう求めています。[5]

攻撃を受けていないかの確認

米CISAは、自社で設置した対象の機器について、ネットワークとメモリの調査で侵害の痕跡を調べるよう求めています。調べる点として、次の4つを挙げています。[2]

1. 心当たりのない特権・管理者のセッション
2. 心当たりのないスクリプトのファイル
3. ログやログの転送の、思いがけない途切れ
4. 許可していないアカウント・権限・セッションの方針の変更

Mandiantは、利用者は機器のファイルシステムを直接調べられず、攻撃者は機器の上のログを消していたとしています。そのため、機器の外に残る記録で調べるよう勧めています。[5]

1. /login の設定を、悪用の期間より前の状態と比べる。特に、Jump Itemの役割が「No Access」から「Administrator」に上げられた利用者（syslogの user_changed）、心当たりのない利用者・APIアカウント・セキュリティプロバイダー、送り先が変わったsyslog・外部へのイベント通知
2. リバースプロキシ・WAFの記録で、Remote Supportで使わない経路への要求（見知らぬ .php、Mandiantが観測した /app_84304470%2Ephp や /uidchanarge）と、想定外の相手からのWebSocketへの切り替え
3. /login への、家庭用回線や商用VPNのアドレスからのログイン、業務時間外の管理者のログイン
4. サポートのセッションの記録で、期間中のファイル転送と、どの端末に入られたか
5. 機器から送るsyslogの途切れ

侵害が疑われるときの対応を、米CISAは次の順で示しています。[2]

1. 疑わしい機器を切り離す。仮想アプライアンスはスナップショット、物理の機器はフォレンジック用のイメージを取る。機器のsyslogとセッションの記録をすぐにSIEMへ送り、WAF・リバースプロキシ・境界のファイアウォールのログも、外から見えていた期間の分を集める
2. ネットワークとフォレンジックの調査で、侵害の証拠と上の点を調べる
3. 問題の無い状態から作り直してBT26-05-RSパッチを当てる。そのうえで、機器が保存・入力したすべての認証情報を変え、有効なサポートのセッションをすべて取り消し、特権アカウントに新しく登録された多要素認証を見直す

Mandiantは、物理の機器（B Series）とSaaSの証拠の保全はBeyondTrustのサポートに頼むこと、認証情報の入れ替えはパッチか作り直しの後に行うこと、入れ替えた後にJump Client・Jumpoint・担当者のコンソールを配り直すことも挙げています。[5]

対象と修正版

対象は26.2.3以前のすべての版で、修正はBT26-05-RSパッチです。パッチは24.3.1〜26.2.3に当てられ、24.3.1より前の版は、先に新しい版へ上げてからパッチを当てます。[1][2]

版とパッチの確かめ方、当て方と保守の会社に伝えること

1. 版を確かめます。Remote Supportの管理画面（サイトのURLの後ろに /login）にログインし、左のメニューの［Status］を開くと、［Product Version］に版、［Installed patches］に入っているパッチが出ます。[6]
2. 機器の管理画面（サイトのURLの後ろに /appliance）の［Updates］→［Installed Patches］で、入っているパッチの名前・版・入れた日時を確かめます。[7]自動更新に登録している機器も、BT26-05-RSパッチが当たったかをここで確かめます。[5]
3. 当たっていなければ、/appliance の［Updates］で［Check for updates］を押し、出てきたパッケージの［Install This Update］で入れます。機器がインターネットにつながらない場合は、［Appliance Download Key］で鍵を作り、別の端末からBeyondTrustの更新サーバーで更新を取得して、［Manual Installation］から入れます。入れている間、ログイン中の担当者のセッションは一時的に切れます。[8]
4. /appliance にパッチが出てこないときは、BT26-05を挙げてBeyondTrustのサポートに問い合わせます。[5]
5. 24.3.1より前の版は、先に新しい版へ上げてからパッチを当てます。[1][2]

一般の自動更新は既定で無効です。[8]

保守の会社に頼むときは、CVE-2026-102764とBeyondTrustの勧告BT26-05の番号、いまの版（24.3.1より前かどうか）、自動更新に登録しているかを伝えます。あわせて、上の確認点で侵害の痕跡を調べてもらいます。

すぐにパッチを当てられないとき

BeyondTrustの勧告には、パッチの代わりになる回避策は書かれていません。[1]

米CISAは、パッチとあわせて、機器に外から届く範囲を利用者や顧客の支援に要るサービスだけに絞り、管理画面への接続を信頼できるネットワークに限るよう求めています。[2]

SiteGuard Server Editionの脆弱性で起きること

CVE-2026-106931は、SiteGuard Server Editionの統計機能にあるOSコマンドインジェクション（CWE-78）で、悪用されると製品が動くサーバー上で、rootまたはSYSTEM権限で任意のOSコマンドを実行されるおそれがあります。開発元のEGセキュアソリューションズは2026年10月14日に公表し、深刻度を「緊急」としています。[1][3]

SiteGuard Server Editionは、Webサーバーに組み込んで使うホスト型のWAFです。CVSSの基本値はv4.0で8.5、v3.0で7.8です。いずれも攻撃元区分はローカル、必要な特権は「低」と評価されています。[1][3]

対象になる構成（統計機能）

統計機能が有効な場合に影響を受け、統計機能は初期値で有効です。設定を変えていなければ対象と考えます。[1]

IIS版のVer3.10からVer4.00 Update4は、この脆弱性の影響を受けません。[1][2]

悪用の状況

EGセキュアソリューションズは、この脆弱性の悪用を確認しています。サポート契約のある利用者には、2026年9月29日に個別に知らせていました。[1]修正版のVer8.00 Update5とVer7.00 Update6（FreeBSD版）も、同じ9月29日にリリースされています。[7]

JPCERT/CCは2026年10月14日に注意喚起を出し、この製品が国内で広く使われていることを確認しているとして、対策と侵害調査を検討するよう求めています。[2]米CISAは2026年10月20日（米国時間）にKEVへ追加し、更新の前に侵害の有無を調べる対象（Forensic Triage）にも指定しました。[4][5]

攻撃を受けていないかの確認

アップデートやパッチを当てると、攻撃の痕跡が消える可能性があります。EGセキュアソリューションズは、当てる前に「診断情報」を取得して保管するよう案内しています。[1][2]

1. アップデート・パッチの前に、ウェブ管理画面の［診断情報］→［診断情報をダウンロード］で診断情報を取得し、保管する（アップデートで攻撃の痕跡が消えることがある）

保管した診断情報は、侵害の調査を頼むときに渡せるようにしておきます。JPCERT/CCは、対策とあわせて侵害調査の実施を検討するよう求めています。[2]

対象バージョンと修正版

Ver2.20以降で、Apache版・Nginx版・IIS版はVer8.00 Update5より前、FreeBSDのApache版・Nginx版はVer7.00 Update6より前が対象です。[1][2][6]

版の確かめ方とアップデートの手順、頼むときに伝えること

1. いまの版を確かめます。版の確かめ方を書いた管理者用のマニュアルは、EGセキュアソリューションズのサポートページの「ダウンロード」にあり、契約内容確認書に書かれたサポートID・パスワードでログインして入手します。[8]版ごとのリリース日とサポートの状況は、公開の「サポートバージョン情報」で確かめられます。[7]
2. ウェブ管理画面の［診断情報］→［診断情報をダウンロード］で診断情報を取得し、保管します。[1]
3. 開発元の情報をもとに、最新版（上の表の修正版）にアップデートします。最新版は同じダウンロードのページから入手します。[1][8]バージョンアップが難しい場合は、統計処理の対象ファイルを差し替えるパッチを当てます。パッチの入手先は告知に書かれていないため、サポート窓口で確かめます。[1]
4. 不明な点は、サポート窓口かJPCERT/CCに問い合わせます。サポート窓口は、納品時の契約内容確認書か、購入した販売店で確かめます。[1]
5. 保守の会社・制作会社に頼むときは、SiteGuardを入れているサーバーとWebサーバーの種類（Apache・Nginx・IIS、FreeBSDか）、いまの版、診断情報を先に保管すること、修正版かパッチのどちらで対応するかを伝えます。

すぐにアップデートできないとき

統計機能を無効にすれば、この脆弱性の影響を回避できます。無効にする手順は公開されておらず、JPCERT/CCは開発元の最新の情報で確かめるよう案内しています。[2]バージョンアップが難しい利用者向けには、統計処理の対象ファイルを差し替えるパッチも出ています。[1]

サポートが終わった版を使っているとき

統計処理の対象ファイルを差し替えるパッチは、サポートが終わった版も対象に提供されています。[1][3]

サポートバージョン情報では、Ver6.00以前はすでにサポートが終わっています。Ver7.00〜Ver7.00 Update3と、IIS版のVer7.00 Update4・Update5は、2026年11月30日にサポートが終わります。Ver8.00系と、FreeBSD版のVer7.00 Update4〜Update6は、2026年11月2日の時点で「現行」です。[7]

11月30日にサポートが終わる版を使っている場合は、パッチで済ませるか、Ver8.00 Update5へ上げるかを、サポートの期限とあわせて決めます。

GitLabの脆弱性CVE-2026-97229で起きること

CVE-2026-97229は、GitLabがCI/CD設定の中の正規表現を十分に検証していないために起きる整数オーバーフロー（CWE-190）で、条件によっては認証されていない攻撃者にGitLabサーバー上で任意のコードを実行されるおそれがあります。GitLabは深刻度をCritical、CVSS v3.1の基本値を10.0としています。[1][3]

原因は、GitLabが使うRubyの正規表現エンジン（Onigmo）で、細工したパターンをコンパイルするとメモリが壊れることです。GitLabは、自社で同梱するRubyに修正を当てて直しました。[4]

対象になるGitLab（CE/EE、セルフマネージド）

対象は、自社で運用するGitLab CE/EEの19.2〜19.4の系列です。GitLabの告知は配布の形（Linuxパッケージ、ソースからの導入、Helm チャートなど）を挙げておらず、この場合はすべての形が対象です。[1]

GitLab.comはすでに修正済みの版で動いており、GitLab Dedicatedも告知の前に修正済みです。[1]

悪用の状況

米CISAは2026年10月29日（米国時間）に、悪用の証拠に基づいてCVE-2026-97229をKEVへ追加し、米連邦政府機関の対応期限を11月1日としました。KEVでは、更新の前に侵害の有無を調べる対象（Forensic Triage）にも指定されています。[2][10]

悪用の確認とは別に、攻撃用のコードも公開されています。CI Lintを使ってGitLabでコードを実行するMetasploitのモジュールは、2026年10月14日に公開の場で提案され、10月30日（米国時間）に取り込まれました。[9]

2026年11月2日に確認した時点で、JPCERT/CCとIPAの注意喚起の一覧にこの脆弱性はありません。

外から届くGitLabがあるか

GitLabは、条件によっては認証されていない攻撃者がコードを実行できるとしています。条件の詳細は公開していません（GitLabは脆弱性の課題を修正の90日後に公開します）。[1]Metasploitのモジュールの説明では、公開プロジェクトにpushできる利用者のアカウントで細工したCI設定とリポジトリのパスを置き、そのうえで認証なしのCI Lintの要求を送ると、GitLabのgitアカウントの権限でコマンドが動きます。[9]

インターネットや取引先から届き、外部の人がアカウントを作れる・公開プロジェクトがあるGitLabほど急ぎます。社内のGitLab（本番・検証・部署ごとのもの、クラウド上に立てたものを含む）を一覧にし、それぞれの版と、外から届くかを書き出します。

攻撃を受けていないかの確認

GitLabは、自社で運用するGitLab向けに、この脆弱性を狙った攻撃の試みを見つけるための検知ルールを6つ公開しています。[1]それぞれ、次のログの記録を手がかりにします。[6][7][8]

1. Pumaのエラーログ（puma_stderr.log）に、Onigmo（正規表現のエンジン）の関数を経由したRubyの異常終了の報告（[BUG]）が無いか
2. Workhorseのアクセスログに、/api/v4/projects/:id/ci/lint や /api/graphql へのPOSTが502（badgateway: failed to receive response: EOF）で終わった記録が無いか
3. application_json.log に、CIの正規表現の安全確認が拒否した警告（regexp rejected at compile time など）が無いか
4. graphql_json.log に、ciLint の変数として細工した正規表現（{96000,} のような大きな繰り返しなど）が送られた記録が無いか
5. api_json.log に、同じクライアントから ci/lint への5xxの応答が短い間に続いた記録が無いか
6. リポジトリのパスに、255バイト近い長さで非ASCIIの文字を含む不審なものが無いか
7. 細工した .gitlab-ci.yml をpushする経路では、Sidekiqのログに「A worker terminated, shutting down the cluster」が出て、パイプラインが作られていない記録が無いか

攻撃が成功するとワーカーが異常終了し、その要求はRailsのログ（api_json.log・graphql_json.log）に残らないことがあります。Workhorseのログも合わせて見ます。[7]

対象バージョンと修正版

CVE-2026-97229の対象は19.2〜19.2.7、19.3〜19.3.4、19.4〜19.4.1で、19.2.8・19.3.5・19.4.2で直ります。[1][3]ただし、同じ種類の脆弱性CVE-2026-110264（認証なしのコード実行、CVSS 10.0）が7.0以降の幅広い版を対象に10月21日に直っています。[5]使っている系列の最新のパッチ版まで上げます。

GitLabのセキュリティチームは、19.4.1に入っていたCVE-2026-93577の修正が不十分で、CVE-2026-97229で回避されたとしています。19.4.1で止めず、上の版に上げます。[6]最新の版は[11]で確かめます。

バージョンの確認方法と上げる手順

1. 版を確かめる：Linuxパッケージで入れた場合は sudo gitlab-rake gitlab:env:info、ソースから入れた場合は bundle exec rake gitlab:env:info RAILS_ENV=production を実行し、「GitLab information」の Version を見ます。複数台の構成では、GitLab Railsが動くサーバーで実行します。[12]
2. 上げる：19.4.2などのパッチにはデータベースの移行が含まれます。1台構成では、移行が終わるまでGitLabが起動しないため停止時間が出ます。複数台の構成では、停止なしの手順で上げられます。[1]
3. 反映を確かめる：上げた後に同じコマンドで版が修正版以上になったことを確かめます。[12]
4. 保守の会社に頼むときは、GitLabのサーバーの台数と構成（1台か複数台か）、いまの版、上げる先の版、作業の前後でログを残しておくことを伝えます。

すぐに上げられないとき

GitLabの告知に、CVE-2026-97229の回避策の記載はありません。GitLabは、対象の版を使うすべての環境をできるだけ早く最新の版に上げるよう強く勧めています。[1]

Rubyで動くほかのアプリケーション

米CISAは、同じRuby（Onigmo）の整数オーバーフローの問題で、GitLab以外の製品も影響を受ける可能性があるとしています。[10]Rubyの開発チームは2026年10月23日に、修正を含むRuby 4.0.9・3.4.12・3.3.13を公開しました。[4]

Rubyの開発チームによると、影響を受けるのは、攻撃者が操作できる文字列から正規表現を作るアプリケーション（Regexp.new などに入力を渡すもの）だけです。Regexp.timeout や、パターンの長さの制限では防げません。上げられない場合は、信頼できない入力から正規表現を作らないよう求めています。[4]

Ivanti Connect Secureの脆弱性で起きること

Ivantiは2026年10月13日にCVE-2026-104935を公表し、10月29日に、連鎖して悪用されたCVE-2026-111357とCVE-2026-118527の修正版を出しました。3件を連鎖させた悪用を、公表の時点で限られた数の顧客で確認しています。[1]

CVE-2026-111357は単独ではローカルで認証済みの攻撃者が前提ですが、連鎖させると前提が無くなります。Volexityの調査では、連鎖は認証の回避、wu.cgiでのファイルの書き込み、dsinvokedでの権限の昇格の3段で、認証なしでroot権限のコード実行に至りました。[1][4][5]

攻撃者は、機器に保存されたLDAPのドメインの認証情報を抜き出し、Active Directoryの情報、LAPSのローカル管理者のパスワード、BitLockerの回復キーを探していました。[4]

対象になる製品と系列

対象はIvanti Connect Secure（ICS）です。CVE-2026-104935は22.7R2.14以前には影響しません。Ivantiは、22.7.Xとそれより前の版にはこの脆弱性が無いとしています。[1]

25.1.3.0（2026年7月公開、ISA4500・ISA6500・ISA8500で動く版）以降にも、この脆弱性は無いとしています。Ivantiは25.1.3.0で一部をすでに直しており、ほかの系列へ移す作業の途中で悪用が起きました。[1]

Ivantiの告知は、設定による条件を挙げていません。[1]

悪用の状況（KEV・Volexityの報告）

Ivantiは、限られた数の顧客での悪用を確認しています。米CISAは、CVE-2026-104935を2026年10月13日に、CVE-2026-111357とCVE-2026-118527を10月30日にKEVへ追加しました。CISAは、攻撃者がこれらを悪用して認証情報の窃取とデータの持ち出しをしていると述べています。[1][2][3][6]

Volexityは、2026年10月の第1週に、当時の最新版だった22.8R2.4のICSが、未知の攻撃者（UTA0576）に未公表の脆弱性の連鎖で侵害されたのを見つけました。悪用は10月3日から繰り返されていました。機器にWebシェルや裏口は置かれず、コマンドは攻撃の要求のたびに送られていました。[4]

JPCERT/CC・IPAの注意喚起は出ていません（2026-11-02確認）。

外から見えているか

ICSはSSL-VPNの装置で、社外からの接続を受けるため、インターネットから届く場所に置かれます。連鎖の最初の段は、ログイン画面を出す公開のCGI（/dana-na/auth/url_default/welcome.cgi）への要求から始まります。[4]

自社のICS（ハードウェアのISA、仮想、クラウド）がどこにあり、どの名前とIPアドレスで外から見えているかを、版と機種を含めて一覧にします。保守を委託している機器も含めます。

侵害の確認（整合性チェックだけでは足りない）

米CISAは、侵害を受けたかの判断にはネットワークとメモリのフォレンジックが要るとしています。Ivantiの整合性チェックツール（ICT）は、攻撃者のコマンドがメモリ上で動くため、CVE-2026-104935の悪用を見つけられないことがあります。[3]Volexityの調査でも、攻撃者はメモリ上のライブラリを書き換えて元に戻しており、ICTは何も見つけませんでした。[4]

Ivantiは、Volexityのブログの痕跡を確かめ、ICTを定期的に動かすよう求めています。[1]Volexityが挙げる確認点は次のとおりです。[4]

1. /dana-na/auth/url_default/welcome.cgiへの大量の要求と、X-DSCGI-PATHヘッダーで別のスクリプト（/home/webserver/htdocs/dana/fb/smb/wu.cgiや/home/runtime/tmp/<ファイル名のMD5>）を指すもの。URLとX-DSCGI-PATHの食い違い。
2. /tmp/に残る攻撃後の作業の跡（ml.py・rq5.py・mk.py・rr.py・pu.txt・sp_out.txt・spray_hits.jsonなど）。
3. 隠しディレクトリ/data/.icscap/と、その中のパケットの記録（cap0など）やh.py、tcpdumpの名前を変えたdsstatmondのプロセス。
4. /home/runtime/dlogs/debuglogと/var/log/audit/audit.logで、ある時間帯の記録だけが抜けていないか。
5. ICSから社内へ広がろうとする通信（Active DirectoryへのLDAPの問い合わせ、パスワードスプレー、Kerberosの試行）。
6. Volexityが観測した攻撃元108.165.147[.]64との通信。

侵害が疑われるとき、CISAはIvantiの復旧手順に沿って、次の順で進めるよう勧めています。[3]

1. 機器の設定をバックアップする。
2. 工場出荷時の状態に戻し、最新版に上げる。クラウドと仮想の機器は作り直して最新版に上げる。
3. 1のバックアップから設定を戻す。
4. ドメイン・管理者・ローカルのすべてのアカウントのパスワードを替える。保存された証明書を取り消して出し直し、APIキーとライセンスサーバーの認証情報を替える。

対象と修正版（25.1・22.8）

Ivantiの告知では、CVE-2026-111357とCVE-2026-118527は25.1.1.2以前と22.8R2.5以前が対象で、25.1.1.3と22.8R2.6で直ります。CVE-2026-104935は25.1.1.1以前、25.1.2.2以前、22.8R2.4以前が対象で、25.1.1.2、25.1.3.0・25.1.3.1、22.8R2.5で直ります。[1]

CVE-2026-111357のCVEの記録（採番：MITRE）は、影響を受ける版として22.8R2.4だけを挙げており、Ivantiの告知の範囲（25.1.1.2以前・22.8R2.5以前）より狭くなっています。対象かどうかは、提供元のIvantiの告知の範囲で判断します。[5]

25.1.2系について、Ivantiの表はCVE-2026-111357・118527の行を設けていません。米CISAは、3件の対象として25.1.2.2以前も挙げています。[1][3]

Ivantiは、22.8系では25.1.1.3以降への更新を勧めています。すぐに25.1へ移れない場合は、22.8R2.6で今回の全件が直るとしています。25.1.1.1（ISA6000・ISA8000）は25.1.1.3に上げると全件が直ります。[1]

版の確かめ方と上げる手順

1. 機器ごとに、今の版と機種（ISA6000・ISA8000、ISA4500・ISA6500・ISA8500、仮想・クラウド）を確かめます。
2. 06の表で上げる先を決めます。
3. 修正版は、Ivantiのダウンロード（ILS）から入手できます。[1]
4. 25.1.3.0に移るには、新しい機種（ISA4500・ISA6500・ISA8500）が必要です。ハードウェアは新しい機器を用意し、仮想・クラウドは25.1.3.0のテンプレートで作り直します。手順はIvantiの「Ivanti Connect Secure 25.x Upgrade and Migration Compatibility Guide」にあり、CISAも参照を勧めています。[1][3]
5. 上げた後に版が上げる先になったかを確かめます。

保守の会社に頼むときは、機種と版、上げる先（25.1.1.3、22.8R2.6など）を伝え、上げる前に侵害の調査（05）をするか、侵害が疑われる場合は工場出荷時に戻してから上げる手順で進めるかを決めます。上げた後のパスワードと証明書の入れ替えまでを頼みます。

すぐに上げられないとき

Ivantiの告知に、回避策の記載はありません。Ivantiは、修正版への更新で直すとしています。[1]

保守終了の系列（22.7・22.8）を使っているとき

Ivantiは、22.7と22.8のサポートが2027年1月31日に終わるとしています。22.8は22.7から25.1へ移るまでの一時的な橋渡しの系列で、25.1には重要なセキュリティの機能があるとして、期日までに25.1への移行を終えるよう求めています。米CISAも、22.8のサポートの終了日を示しています。[1][3]

25.1.3.0以降は新しい機種が要るため、ハードウェアで使っている場合は、機器の入れ替えの時期と予算を早めに決めます。[1]

Cisco SD-WANの脆弱性で起きること

CVE-2026-76504を悪用されると、認証されていない遠隔の攻撃者が、Cisco Catalyst SD-WAN Managerの管理用のAPIに管理者（admin）の権限で入れるおそれがあります。HTTPの要求に含まれるURLの符号化の扱いに誤りがあり、特定のAPIの入口を守る認証の決まりをすり抜けられることが原因です。Ciscoは2026年9月30日に公表し、CVSS 3.1の基本値を9.8としています。[1]

CVE-2026-20127は、Controller（旧vSmart）・Manager（旧vManage）・Validator（旧vBond）の間の相互認証（ピアリング）がうまく働かない脆弱性です。悪用されると、認証なしで内部の高い権限のアカウントでログインされ、NETCONFを通じてSD-WAN全体のネットワーク設定を書き換えられるおそれがあります。Ciscoは2026年2月26日に公表し、CVSS 3.1の基本値を10.0としています。[2]

対象になる製品と構成

CVE-2026-76504は、Cisco Catalyst SD-WAN Managerが対象で、設定に関係なく当てはまります。Ciscoが管理するクラウド（Cisco SD-WAN Cloud、Cisco Managed）は、Ciscoが20.15.605で直しており、利用者の作業は要りません。[1]

CVE-2026-20127は、Controller・Manager・Validatorが対象で、設定に関係なく当てはまります。自社で設置したもの（On-Prem）のほか、Ciscoが提供するクラウド（Cisco Hosted SD-WAN Cloud、Cisco Managed、FedRAMP環境）も対象の構成に挙げられています。[2]

製品名は20.12.1から変わっています。vManageはSD-WAN Manager、vSmartはSD-WAN Controller、vBondはSD-WAN Validatorです。[2]

悪用の状況（KEV追加と悪用確認）

Cisco PSIRTは、2026年9月にCVE-2026-76504が実際に悪用されていることを把握しました。この脆弱性は、Ciscoのサポート窓口（TAC）への問い合わせを調べる中で見つかったものです。[1]

米CISAは、CVE-2026-76504を2026年9月30日（米国の日付）にKEVへ追加し、侵害の調査（Forensic Triage）の対象としています。CVE-2026-20127は2026年2月25日（米国の日付）にKEVへ追加されています。[3]

CVE-2026-20127について、Ciscoは限られた範囲での悪用を把握しています。この脆弱性はオーストラリア信号局のサイバーセキュリティセンター（ACSC）が報告したものです。[2]

Ciscoは2026年10月28日（米国時間）、CVE-2026-20127を悪用した攻撃者（UAT-11473）の侵入後の活動の分析をCisco Talosのブログで公表し、告知（改訂2.1）に追記しました。攻撃者は認証の回避の後、Controllerのプロセス（vdaemon）に入り込む仕組みを置き、裏口と鍵の情報の収集に使っていました。[6][2]

JPCERT/CCとIPAの注意喚起の一覧には、2026年11月2日の時点でこの2件はありません。

管理サーバーが外から見えているか

Ciscoは、インターネットに面し、ポートが外から届くSD-WAN ManagerとControllerが侵害の危険にさらされているとしています。[1][2]

まず、自社のSD-WANの管理サーバー（Manager・Controller・Validator）がどこにあるか（自社設置か、Ciscoのクラウドか）と、どの名前・IPアドレス・ポートで外から届くかを一覧にします。保守を委託している構成も含めます。

攻撃を受けていないかの確認

修正版に上げる前に悪用されていないかを、Ciscoが示すログの点で確かめます。次の記録は通常の運用でも出ることがあるため、普段の状態と比べて判断します。[1][2][4]

1. 【CVE-2026-76504】/var/log/nms/containers/service-proxy/serviceproxy-access.log に、心当たりのないIPアドレスからの j_security_check への要求（例：POST /%6a_security_check）が無いか。%6a（j）は一例で、どの1文字を符号化しても悪用できます
2. 【CVE-2026-76504】/var/log/nms/vmanage-server.log に、心当たりのないIPアドレスからの j_security_check で、ユーザー名が viptela-reserved- で始まる記録が無いか
3. 【CVE-2026-20127】/var/log/auth.log の Accepted publickey for vmanage-admin の接続元が、管理画面の WebUI > Devices > System IP にある自社の機器のIPアドレスと一致するか
4. 【CVE-2026-20127】制御接続のピアリングの記録（特に peer-type が vmanage のもの）について、時刻が保守作業や設定変更の予定と合うか、public-ip が自社や取引先の機器か、peer-system-ip が構成どおりか、同じ送信元から繰り返されていないか

CVE-2026-20127については、米CISAが侵害の調べ方を示しています。悪用は2023年に始まった可能性が高いとして、調べる期間をそれに合わせるよう求めています。[5]

1. 【CVE-2026-20127】/var/volatile/log/vdebug・/var/log/tmplog/vdebug・/var/volatile/log/sw_script_synccdb.log に、予定に無い古い版への巻き戻しや再起動の記録が無いか[5]
2. 【CVE-2026-20127】/home/vmanage-admin/.ssh/authorized_keys に、管理者が登録していない鍵が無いか[5]
3. 【CVE-2026-20127】Cisco Talosが挙げるファイル（/tmp/system-vdaemon、/var/tmp/vdaemon.bin、/var/tmp/vdaemon.conf、/etc/sv/sshd/・/etc/sv/aaamgr/ の下の見慣れないもの、libdssl.so・rsshd・conf_sshd・aaamgrd）が無いか[6]

米CISAは、root権限のアカウントが侵害されていたときは、修正済みのイメージ（OVA・qcow2）からManager・Controller・Validatorを作り直し、拠点の機器を新しい構成へ移すよう求めています。[5]

判断に迷うときは、各管理サーバーで request admin-tech を実行して資料を集め、CiscoのTACに相談します。CVE-2026-76504で相談するときは、Severity 3で、件名にCVE番号を入れます。Ciscoは、TACの調査の結果を待たずに修正版へ上げるよう求めています。[1][2][4]

対象と修正版（系列ごと）

CVE-2026-76504の修正版は、20.9が20.9.10.1、20.12が20.12.8.2、20.15が20.15.6.1、20.18が20.18.4.1、26.1が26.1.2.1、26.2が26.2.1です。20.9より前は、修正版のある系列へ移ります。[1]

表の版は、それぞれの脆弱性が初めて直った版です。同じ系列では、CVE-2026-76504の修正版のほうが新しい版です。[1][2]

CVE-2026-76504のCVEの記録（採番：Cisco）は、修正版と同じ番号でも、名前に_LI_Imagesが付く版や末尾に.01が付く版（例：20.18.4.1.01、26.2.1_LI_Images）を影響ありに挙げています。これらの版を使っている場合は、Ciscoに確かめます。[8]

版の確かめ方と上げる手順

自社で設置したManagerは、各Managerでshow softwareを実行すると、入っている版の一覧（VERSION・ACTIVEなどの列）が出ます。クラスタで使っている場合は、すべてのManagerで確かめます。[7]Ciscoが管理するクラウドでは、管理画面のHelpで対応の状況と版を確かめられます。[1]

1. 上げる前に、すべてのManager（クラスタのすべての機器、予備の拠点のものを含む）でrequest admin-techを実行し、資料を残します。[4]
2. 上げる先は、今の系列の中の修正版（06の表）にします。Ciscoの対処の手引きは、今のメジャーリリースの中で上げるよう求めています。[4]
3. Ciscoの互換性の表（Catalyst SD-WAN Control Component Compatibility Matrix）で管理サーバー同士の組み合わせを確かめ、Cisco Catalyst SD-WAN Upgrade Matrixで上げる順番を決めます。[1]
4. 上げた後に、もう一度show softwareで版を確かめます。[7]

保守の会社に頼むときは、CVE-2026-76504とCVE-2026-20127の番号、いまの版、上げる先の版（06の表）、Manager・Controller・Validatorのどれが何台あるかを伝えます。あわせて、05の確認点でログを調べてもらい、上げる前のadmin-techの資料を残してもらいます。

すぐに上げられないとき

Ciscoは、どちらの脆弱性にも回避策は無いとしています。直す方法は修正版に上げることだけです。[1][2]

CVE-2026-76504では、修正版に上げるまでの一時的で部分的な守りとして、Live Protect shieldを出しています。これを入れると、URLの符号化を使う正規の利用者がSD-WAN Managerにログインできなくなることがあります。[1]

緩和策として、自社設置の構成では、インターネットなど安全でないネットワークからの接続を止め、外から使う必要があれば、決まった信頼できる送信元だけに絞ってファイアウォールの内側に置きます。CVE-2026-20127では、ポート22と830への通信を、決まった管理サーバーのIPアドレスなどに限るよう求めています。Ciscoのクラウドでは、これらの緩和策はCiscoが入れています。[1][2]

保守が終わった系列を使っているとき

CVE-2026-20127の表では、20.9より前、20.11、20.13、20.14、20.16はソフトウェアの保守が終わった系列です。Ciscoは、サポートされている系列へ上げるよう強く勧めています。[2]

CVE-2026-76504の表には、20.11・20.13・20.14・20.16の行がありません。これらを使っている場合は、表にある系列の修正版へ移ります。[1]

NetScalerの脆弱性で起きること

開発元のCloud Software Groupは、2026年9月28日（日本時間）にNetScaler ADCとNetScaler Gatewayの8件の脆弱性（CVE-2026-88771〜CVE-2026-88778）を公表しました。CVE-2026-88771は入力の検証の不備で、認証されていない攻撃者に任意のコマンドを実行されるおそれがあります。CVE-2026-88772はメモリの範囲外の操作で、遠隔からのコード実行かサービス停止につながります。深刻度は開発元の評価で、2件ともCVSS v4.0の9.5です。[2]

MandiantとGoogle Threat Intelligence Group（GTIG）は、CVE-2026-88772の悪用では、認証の前のDTLSのやり取りの段階でパケットを処理するエンジン（NSPPE）を異常終了させ、root権限で機器に入っていたと報告しています。[4]

残りの6件は、HTTPリクエストスマグリング（88773、9.3）、ポリシーの回避（88774、7.0）、メモリの範囲外の操作による誤動作やサービス停止（88775〜88777、8.8）、TCPの初期シーケンス番号の推測（88778、8.8）です。どれも当てはまる設定が違います。[2]

その後、同じ製品で2件が続けて公表されました。CVE-2026-88779（10月4日公表）はメモリの範囲外の操作によるサービス停止で、CVSS v4.0の8.7（開発元の評価）です。CVE-2026-107406（10月9日公表）はメモリの範囲外の操作で、遠隔からのコード実行かサービス停止につながり、CVSS v4.0の9.5（開発元の評価）です。どちらも、NetScalerをSAMLのSP（サービスプロバイダー）かIdP（認証の提供元）として設定している場合だけが対象です。[7][8]

対象になる構成（DTLS・VPN仮想サーバー）

CVE-2026-88771は、対象の版であれば初期設定を含むすべての構成が当てはまり、追加の機能を有効にしていなくても対象です。CVE-2026-88772は、DTLSが有効な構成が対象です。NetScaler GatewayのVPN仮想サーバーでは、DTLSが初期設定で有効です。[2]

DTLSが有効かは、設定（/nsconfig/ns.confなど）の行で確かめます。Citrixは次の例を挙げています。[2]

DTLSを無効にしていても、CVE-2026-88771の対象からは外れません。[2]

対象は、利用者が自分で管理しているNetScaler ADC・NetScaler Gatewayです。Citrixが管理するクラウドサービス（Gateway Serviceなど）とAdaptive Authenticationは、開発元が更新を済ませています。NetScalerを使うSecure Private Accessのハイブリッド構成は対象で、そのNetScalerを修正版に上げる必要があります。[2][3]

評価・試験用で本番には使えない15.1 Technology PreviewのVPX用ファームウェアも影響を受け、修正は追って出すとしています。[3]

続報の2件は、SAMLの設定がある機器だけが対象です。設定にadd authentication samlActionがあればSAMLのSP、add authentication samlIdPProfileがあればSAMLのIdPとして設定されています。CVE-2026-107406は、14.1-73.37〜14.1-73.41、13.1-64.23〜13.1-64.28（FIPS版も同じ範囲）ではIdPの設定がある場合だけ、それより前の版ではSPかIdPの設定がある場合が対象です。[7][8]

悪用の状況（KEV・国内の観測）

Cloud Software Groupは、修正していないNetScalerでCVE-2026-88771とCVE-2026-88772を悪用する攻撃を確認しています。[2]米CISAは2026年9月27日（米国の日付）に、2件を悪用が確認された脆弱性の一覧（KEV）に追加しました。[5]

MandiantとGTIGは、CVE-2026-88772がゼロデイとして悪用され、遅くとも9月上旬から続く攻撃で、北米と欧州の政府・金融・技術・教育・法律などの組織が影響を受けた可能性が高いと報告しています。攻撃者はPHPのWebシェル（WHIPSHOT）と、社内のネットワークへ通信を中継するPythonの道具（SLAPSHOT）を置き、社内の偵察と認証情報の窃取をしていました。[4]

JPCERT/CCは、この製品が国内で広く使われていることを確認しています。海外のセキュリティ組織の観測では、2026年9月24日以降、国内のNetScalerを対象にした攻撃の試みが見つかっています。この試みが今回の脆弱性を狙ったものかは分かっていません。[1]

続報のCVE-2026-88779は、米CISAが2026年10月4日にKEVへ追加しました。開発元の告知（CTX697174）は、悪用の有無に触れていません。CVE-2026-107406は、11月2日の時点でKEVに載っていません。[5][7][8]

攻撃コード（PoC）の公開について、一次情報に記載はありません。GTIGは、攻撃コードを持っていないとしています。[4]

外から見えているか

NetScaler GatewayをVPNの入口として使う場合、社外からの接続を受けるため、インターネットから届く場所に置かれます。CVE-2026-88772の攻撃は、UDPの443番（DTLS）で届きます。[4]

自社のどこにNetScalerがあるか（本社・拠点・クラウド上の仮想アプライアンスVPX）、どの名前とIPアドレスで外から見えているか、外からUDPの443番を受けているかを一覧にします。保守を委託している機器も含めます。Mandiantは、管理用の接続口（NSIP）をインターネットに出さないよう勧めています。[4]

侵害の確認（攻撃を受けていないか）

修正版に上げても、それまでに置かれた痕跡は消えず、攻撃を受けなかった証明にもなりません。Citrixは、侵害が疑われるか確認できたときは、更新で片付けるのではなく、修正済みの新しいNetScalerを立て直すよう勧めています。[3]

MandiantとGTIGは、確認した侵害で、攻撃者がWebサーバーの設定の変更、Webシェルの設置、/bin/shへのSUID権限の設定などで、アクセスを保とうとしていたと報告しています。調べる所は次の7つです。[1][4]

1. Webサーバーの設定ファイル/etc/httpd.confに、.deb・.sigなどをPHPとして動かす設定（AddHandler・AddType）や、/vpn/media/などを別の場所へ向けるAliasMatchが足されていないか。grep -En -i "application/x-httpd-php|php_flag|AliasMatch" /etc/httpd.conf
2. VPN関連のディレクトリ（/var/netscaler/gui/vpn/scripts/linux/など）に、PHPのコードを含む文字のファイルが作られていないか。本来は実行形式やアーカイブだけが置かれる場所です。
3. Webサーバーのログ（/var/log/httperror*・/var/log/httpaccess.log）に、.sigなど普段と違う拡張子のエラーや、/vpn/media/・/vpn/scripts/への要求で404なのに応答が数KBあるもの、記録の欠けが無いか。
4. DTLSのハンドシェイクの失敗（ClientVersion DTLSv1.0、Reason "Handshake failure-Internal Error"）と、その数分後のNSPPEの異常終了（/var/log/messagesのNOT restarting NSPPE）。
5. /tmp/.uxdport・/tmp/.uxdlockなどの不審なファイル。ls -la /tmp/.uxdport* /tmp/.uxdlock
6. /bin/shに設定された不審なSUID権限（-rwsr-xr-xでrootの所有）。ls -l /bin/sh
7. nohupで動く、/tmp/.uxdportなどを含む不審なPythonのプロセス。ps aux | grep -E "python.*(\.uxd|uxdport|uxdlock|base64)"

Citrixは、NetScaler Consoleのセキュリティアドバイザリの画面で、一般的な侵害の痕跡（IoC）を調べる機能を出しています（NetScaler Console 14.1-73.36以降、テレメトリの通信が有効なこと）。Consoleを使っていない場合は、Citrixのサポートに頼めます。Citrixは、この検査ですべての侵害が見つかるわけではないとし、経験のある調査の専門家に頼むよう勧めています。[3]

痕跡が見つかったとき、Mandiantは、機器をネットワークから外す、HAのペアは両方を別々に調べて設定の同期を止める、機器から外への通信を絞る、を挙げています。[4]

Citrixの手順（CTX694799「Steps to Take if NetScaler ADC is Suspected to be Compromised」）は、次の順です。[9]

1. 証拠を残す：VPXは調査用のスナップショットを取る。システムの時刻・時間帯・NTPの設定を記録し、外部のsyslogとNetScaler Consoleの記録も残す。サポート用の情報（Technical Support Bundle）と、パケットを処理するエンジンのコアダンプを取る（取得中に再起動する）。
2. 機器をネットワークから外す。
3. 機器に保存した認証情報（LDAPの接続用アカウント、RADIUSの共有鍵、OAuthのトークン、APIの鍵、SNMPのコミュニティ名）を、それぞれの接続先で替える。Gateway・AAAで認証した利用者のパスワードを替え、証明書と秘密鍵を失効させる。
4. NetScalerがつないでいたサーバー（認証サーバー、重要なシステム、管理用の踏み台など）を調べる。
5. MPXは消去して入れ直し、VPXは作り直す。最新のファームウェアに上げてから、侵害より前のバックアップの設定を戻す。
6. 戻した後に、ローカルのアカウントのパスワード、鍵を暗号化する鍵（KEK）、証明書を替え、少なくとも90日は不審な動きを見張る。

管理用のサービスは、インターネットに出さないようCitrixは求めています。[9]

対象と修正版（14.1・13.1・FIPS）

CVE-2026-88771・88772は、14.1系は14.1-73.37以上、13.1系は13.1-64.23以上で直ります。続報のCVE-2026-88779は14.1-73.41・13.1-64.28以上、CVE-2026-107406は14.1-73.46・13.1-64.29以上で直るため、今から上げるなら14.1-73.46・13.1-64.29以上にします。[2][7][8]

Citrixのダウンロードの一覧では、2026年11月2日の時点で、14.1が14.1-73.49、13.1が13.1-64.32、FIPS版が14.1-73.49と13.1-37.286（いずれも10月27日公開）が最新です。[11]

同時に公表されたCVE-2026-88778（TCPの初期シーケンス番号の推測）は、更新に加えてTCPの設定の変更が必要です。show ns tcpparam | grep "Enhanced ISN Generation"がDISABLEDを返し、HTTP・SSL・TCPなどの仮想サーバーがある機器が当てはまります。[2]

版の確かめ方と上げる手順

Citrixは、NetScaler Consoleのセキュリティアドバイザリ（CVEの検査）で、管理しているNetScalerが対象か確かめられるとしています。[3]機器ごとの版を表示する手順は、Citrixの手引き（docs.netscaler.com の NetScaler ADC の文書）で確かめます。更新の手順は、手引きの「Upgrade a NetScaler standalone appliance」と「Upgrade a high availability pair」にあります。[10]

1. 機器ごとに、今の版（14.1-○○.○○の形）と、FIPS・NDcPP版かどうかを確かめ、06の表の上げる先と比べます。
2. 設定でDTLSとSAMLの有無を確かめます（02）。
3. 修正版をCitrixのダウンロードから入手します。目的の版が見つからない場合、MandiantはCitrixにSeverity 1のサポートの問い合わせを開くよう勧めています。[4]
4. 管理画面で上げる場合は、「System」の「System Upgrade」で、ディスクの空き（/varに7GB、/flashに200MB）を確かめ、ファームウェアを読み込み、更新前の検査（Pre-upgrade Validation）で失敗が無いことを確かめてから「Upgrade」を押します。更新が終わると再起動します。[10]
5. CLIで上げる場合は、save configで設定を保存し、shellで/nsconfig/ns.confの写しを取って機器の外にも保存します。/var/nsinstall/<版>/build_<ビルド>にファームウェアを置いて展開し、./installns --pre_checkで事前の検査をしてから./installnsで入れ、再起動します。[10]
6. HAのペアは、副（secondary）を先に上げ、show ha nodeで状態を確かめてforce failoverで切り替えた後、もう一方を上げます。[10]
7. 上げた後に版が上げる先になったかを確かめ、05の侵害の確認をします。

保守の会社に頼むときは、機器の名前と版、FIPS版か、DTLSとSAMLの設定、外から見えているか、上げる先の版（14.1-73.46以上など）を伝え、上げた後の侵害の確認（05の7点とNetScaler ConsoleのIoCの検査）までを頼みます。

すぐに上げられないとき

Cloud Software Groupは、CVE-2026-88771とCVE-2026-88772の回避策を出していません。続報の2件の告知にも、回避策の記載はありません。[7][8]JPCERT/CCは、十分に試したうえでの速やかな修正版の適用と、侵害の有無の調査を求めています。[1]

Mandiantは、上げるまでの間の一時的な策として、必要のないDTLSを無効にする、機器より手前のファイアウォールやルーターで外からのUDPの443番を止める、接続元が決まっている場合は手前でIPアドレスを絞る、を挙げています。この策はCVE-2026-88772だけに効き、CVE-2026-88771は防げないため、修正版への更新は欠かせません。NetScaler自身のACLだけで止めると、通信が脆弱な処理に届いてから捨てられます。[4]

保守終了の系列（13.1）を使っているとき

Citrixの製品の保守期間の表では、ファームウェアの13.1はメンテナンスの終了（EOM）が2026年9月15日、サポートの終了（EOL）が2027年9月15日です。14.1はEOMが2029年8月8日、EOLが2030年8月8日です。13.1のEOLの印は、SDX 14K FIPSの機種では13.1のSVMへのセキュリティ修正を機種のEOL（2028年3月1日）まで続ける、という注記です。[6]

今回と続報の修正は13.1系にも出ています（13.1-64.23、13.1-64.29など）。[2][8]13.1を使っている場合は、EOLまでに14.1へ移る時期を保守の会社と決めておきます。

Citrixの告知が対象に挙げているのは保守中の系列で、それより古い系列についての記載はありません。古い系列は対象外と読み替えず、保守の会社と扱いを確かめます。[2]

WordPressの脆弱性CVE-2026-87902で起きること

CVE-2026-87902は、WordPress本体の get_page_template() によるページテンプレートの解決で、認証されていない攻撃者が、使っているテーマのフォルダの外にある読み取り可能な.phpファイルを選んで読み込ませられる脆弱性（CWE-98）です。サーバーとテーマの両方の条件がそろうと、リモートでコードを実行されるおそれがあります。[2]

WordPressは2026年9月22日に7.1.2を公開し、深刻度をCritical、CVSS v4の基本値を9.2としています。CVE記録には、米CISAがCVSS v3.1の基本値8.1を追記しています。[1][2][4]

コード実行に至る条件（テーマとサーバー）

コード実行に至るのは、次の2つの条件がそろうときです。[2]

1. 使っているテーマ（親テーマか子テーマ）の一番上に、名前が「page-」で始まるフォルダ（例：page-templates）がある。古い既定のテーマのTwenty Twelve・Twenty Fourteenと、Neve・Hestia・Sydneyなど一部の配布テーマが当てはまります。
2. サーバー上に、Webサーバーのアカウントで読める悪用できる.phpファイルがある。よく知られる例は、PHPの設定 register_argc_argv が On のときの pearcmd.php です。PHPの公式のDockerイメージと、PHP 8.5より前を使うcPanelの既定の設定が当てはまります。

条件の当てはまりを自分で判断するより、修正版に上げる方が確実です。修正版はすべての系列に出ています。[1][2]

悪用の状況

米CISAは2026年9月25日（米国時間）に、CVE-2026-87902をKEVへ追加し、米連邦政府機関の対応期限を9月28日としました。KEVでは、更新の前に侵害の有無を調べる対象（Forensic Triage）にも指定されています。[3]

2026年11月2日に確認した時点で、JPCERT/CCとIPAの注意喚起の一覧にこの脆弱性はありません。

攻撃を受けていないかの確認

WordPressのアドバイザリに、攻撃された場合の痕跡の記載はありません。[2]米CISAはKEVでこの脆弱性を、更新の前に侵害の有無を調べる対象に指定しています。CISAが米連邦政府機関向けに示す手順では、更新すると痕跡が失われるおそれがあるため、記録を先に集めてから更新し、次の点を調べます。[3][8]

1. 更新を入れる前に、調べるのに要る記録（サーバーのアクセスログ・エラーログ、ファイルの一覧など）を集め、何をいつ誰が集めたかを記録する
2. サイトやサーバー、管理者のアカウントへの許可のないアクセスが無いか
3. サーバーからほかの機器へ広がった形跡が無いか
4. 居座るための仕掛け（永続化）が残っていないか
5. データを集めて持ち出した形跡が無いか

対象バージョンと修正版

対象は7.1.0〜7.1.1と、4.7系列までの各系列の古い版です。修正は7.1.2に入り、4.7系列までの各系列にも移されました。[1][2]その後も7.1.3（10月6日）・7.1.4（10月28日）のセキュリティ更新が出ているため、使っている系列の最新版まで上げます。[9][5][7]

バージョンの確認方法と更新の手順

1. 管理画面（ダッシュボード）の「更新」を開き、いまの版と更新の有無を確かめます。[1]
2. 「今すぐ更新」を押して更新します。WordPress.orgから修正版を入手して入れ替えることもできます。[1]
3. 更新後にもう一度「更新」を開き、表の修正版以上になったことを確かめます。
4. 制作会社・保守の会社に頼むときは、サイトのURLと管理画面の場所、いまの版、使っているテーマ（親テーマ・子テーマ）、更新前にバックアップと記録を取ることを伝えます。

自動更新で上がっているかの確かめ方

自動のバックグラウンド更新に対応したサイトでは、この修正版への更新は自動で始まります。[1]WordPressの説明では、既存のサイトは保守・セキュリティの小さな版（マイナー版）の自動更新が既定で有効で、5.6以降で新しく入れたサイトは、バージョン管理の作業コピーで動かしている場合を除き、大きな版も既定で自動更新されます。[6]

ただし、wp-config.php で AUTOMATIC_UPDATER_DISABLED を true にしている、または WP_AUTO_UPDATE_CORE を false にしていると、自動更新は止まります。プラグインのフィルターで止めることもできます。自動更新に任せていると思っていても、管理画面の「更新」で実際の版を確かめます。[6]

レンタルサーバーで動かしている場合も、自動更新の設定と実際の版を同じように確かめます。cPanelの既定の設定でPHP 8.5より前を使っていると、コード実行の条件の1つに当てはまります。[2]

すぐに更新できないとき

WordPressのアドバイザリとリリースの告知に、回避策の記載はありません。修正版はすべての対象の系列に出ているため、更新が対策です。[1][2]

古い系列を使っているとき

修正は4.7系列まで移されていますが、WordPressは、積極的にサポートしているのは最新の版だけだとしています。[1]4.7より前の版は、WordPressのアドバイザリの表にはありません。CVE記録は7.1.2より前の版をすべて対象とし、米国の脆弱性データベース（NVD）も4.7.37より前の版を対象にしています。セキュリティの修正が移されるのは4.7系列までで、4.7より前の版の修正版はアドバイザリに記載がありません。修正版のある系列か、最新の系列へ上げます。[2][4][10][1]

SharePointの脆弱性CVE-2026-65660で起きること

CVE-2026-65660は、SharePoint Serverでコードの生成を正しく制御できていない脆弱性（コードインジェクション、CWE-94）で、悪用されるとサーバー上でコードを実行されるおそれがあります。Microsoftは2026年8月11日に公表し、深刻度を「重要」、CVSS v3.1の基本値を8.8としています。[1]

前提は、攻撃者が影響を受けるサーバーに対して低いレベルのアクセス許可を持ち、認証されていることです。そのうえで特別に細工したリクエストを送ると、サーバー上でコードを実行できる可能性があります。利用者の操作は要りません。[1]

対象になる製品（SharePoint Server とSharePoint Online）

対象は、自社で運用するSharePoint Enterprise Server 2016、SharePoint Server 2019、SharePoint Server Subscription Editionの3製品です。Microsoftのセキュリティ更新ガイドの対象製品にSharePoint Onlineは挙がっていません。[1]

SharePoint Server 2016を使っている場合も、SharePoint Enterprise Server 2016と同じ更新プログラム（同じKB番号）を入れます。[1]

悪用の状況

米CISAは2026年9月25日に、この脆弱性を悪用が確認された脆弱性の一覧（KEV）へ追加し、米連邦政府機関の対応期限を9月28日としました。KEVでは、更新の前に侵害の有無を調べる対象（Forensic Triage）にも指定されています。[2]

Microsoftは同じ9月25日（日本時間も同じ日）に更新ガイドを改訂（1.2）し、この脆弱性を悪用する攻撃を確認した信頼できる証拠があると追記しました。一方で、更新ガイドの「悪用」の欄は2026年11月2日の時点で「なし」、悪用の可能性の評価は「悪用される可能性は低い」のままで、改訂の追記と食い違っています。[1]

2026年11月2日に確認した時点で、JPCERT/CCの注意喚起（8月のマイクロソフトの月例を含む）とIPAの緊急対策情報に、この脆弱性は挙がっていません。

外から使えるSharePointがあるか

攻撃には低い権限のアカウントがあれば足りるため、アカウントを持つ人が多いほど、また社外から届くほど、狙える人が増えます。[1]まず、社内にあるSharePointのファーム（本番・検証・部署ごとのものを含む）と、社外から接続できるように公開しているものを一覧にします。社外の取引先などに発行したアカウントがあるかも確かめます。

攻撃を受けていないかの確認

Microsoftは、この脆弱性で攻撃された場合の痕跡を更新ガイドで示していません。[1]米CISAはKEVでこの脆弱性を、更新の前に侵害の有無を調べる対象に指定しています。CISAが米連邦政府機関向けに示す手順では、更新すると痕跡が失われるおそれがあるため、記録を先に集めてから更新し、次の点を調べます。[2][6]

1. 更新を入れる前に、調べるのに要る記録（メモリなど電源を切ると消える情報を先に、次にディスク上のログやファイル）を集め、何をいつ誰が集めたかを記録する
2. システム・アカウント・データへの許可のないアクセスが無いか
3. 攻撃者が入り込んでいる形跡、ほかのサーバーへ広がった形跡が無いか
4. 居座るための仕掛け（永続化）が残っていないか
5. データを集めて持ち出した形跡が無いか

対象バージョンと修正のビルド

次のビルドより前が対象で、2026年8月11日のセキュリティ更新で直ります。2016と2019は更新プログラムが2つずつあり、Microsoftは表に挙がったすべてを入れるよう求めています。[1][3]

SharePointの更新は累積で、後の更新にはそれまでの修正がすべて含まれます。Subscription Editionは9月8日（KB5002908）と10月13日（KB5002927、16.0.20326.20190）の更新が出ており、最新の更新を入れれば今回の修正も入ります。2016と2019は、11月2日の時点で8月11日の更新が一覧の最新です。[7]

バージョンの確認方法と更新の手順

ビルドは、サーバーの全体管理の［アップグレードと移行］ページで、製品と更新プログラムのインストールの状態として確かめられます。[5]

1. 更新プログラムは、Microsoft Update、Microsoft Update カタログ、Microsoft ダウンロード センターから入手できます。[4]
2. ファームのすべてのサーバーに更新プログラムを入れた後、SharePoint 製品構成ウィザード（またはPSConfig）を実行して、構成データベースとコンテンツ データベースを更新します。データベースの更新中はサイトを使えません。[5]
3. Subscription EditionでSharePoint ワークフロー マネージャーを使っている場合は、KB5002893を入れる前にKB5002799をファームに入れる必要があります。[4]
4. 保守の会社に頼むときは、対象のファームとサーバーの台数、いまのビルド、入れる更新プログラムのKB番号、更新後に構成ウィザードまで実行することを伝えます。

すぐに更新できないとき

Microsoftのセキュリティ更新ガイドに、この脆弱性の回避策・緩和策の記載はありません。セキュリティ更新を入れることが対策です。[1]

保守が終わったSharePoint Server 2016・2019を使っているとき

SharePoint Server 2016と2019の延長サポートは、2026年7月14日（米国時間）に終わっています。今回の8月11日の更新は2016・2019にも出ていますが、11月2日の時点で、9月・10月の更新は一覧にSubscription Editionの分しかありません。[8][7]

2016・2019を使っている場合は、8月の更新を入れたうえで、Subscription Editionなどサポートが続く製品への移行の時期を決めます。

VMware ESXiの脆弱性で起きること

CVE-2026-41709は、VMware ESXのログの記録が足りない脆弱性です。悪意のある管理者が、一部の操作をログに残さずに行えるおそれがあります。どの操作が記録されないかは、Broadcomの勧告には書かれていません。[1]

Broadcomの評価は深刻度が低（CVSS 3.1の基本値2.7、AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N）で、悪用には高い権限が要ります。同じ勧告VMSA-2026-0006では、ESX・vCenter・Workstation・Fusionのほかの4件の脆弱性も直されています。[1]

VMware Cloud Foundation 9.0とvSphere Foundation 9.0から、ハイパーバイザーの名前がVMware ESXiからVMware ESXに変わりました。パッチとビルドの名前には、引き続きESXiが付きます。[2]

対象になる製品と版

対象は、単体のVMware ESX 8.0と、VMware Cloud Foundation・vSphere Foundation・Telco Cloud Platformに含まれるESXです。CVEの記録では、ESX 8.0はESXi80U3j-25429389より前、9.0.x.xはESXi-9.0.2.0100-25595025より前、9.1.x.xはESXi-9.1.0.0-25370933より前、VCF 5.xは5.2.4より前が対象です。[1][5]

vCenter、Workstation、Fusionはこの脆弱性の対象ではありません。ただし同じ勧告で、vCenterの2件（CVSS 9.8）とWorkstation・Fusionの1件も直されています。[1][2]

悪用の状況（KEV追加）

米CISAは2026年10月28日（米国の日付）、悪用の証拠をもとにCVE-2026-41709をKEVへ追加しました。米国の連邦機関への対応期限は2026年11月11日で、ランサムウェアでの利用は不明としています。[3][4]

Broadcomの告知は、2026年8月19日の改訂（VMSA-2026-0006.2）が最新で、悪用の有無には触れていません。補足のFAQは「Broadcomは悪用を示す情報を持っていない」という記載のままです。どちらも11月2日の時点で、KEVへの追加を受けた更新はありません。[1][2]

誰がどう悪用したか、侵害の痕跡や確認点は、BroadcomもCISAも公表していません。攻撃コード（PoC）の公開についても、一次情報に記載はありません。[1][3]

JPCERT/CCの注意喚起の一覧には、2026年11月2日の時点でこの件はありません。

対象と修正版（系列ごと）

修正版は、ESX 8.0がESXi80U3j-25429389（8.0 U3j）、VCF・vSphere Foundationの9.0.x.xがESXi-9.0.2.0100-25595025、9.1.x.xがESXi-9.1.0.0-25370933、VCF 5.xが5.2.4です。[1]

更新は累積で、表より新しい版でも直ります。同じ勧告の緊急の脆弱性CVE-2026-47876（CVSS 9.3）は、8.0がESXi80U3k-25595708、9.1がESXi-9.1.0.0200-25557999、9.0がESXi-9.0.2.0100-25595025で直るため、上げる先はこれらの版にすると両方が直ります。[1][2]

版の確かめ方と上げる手順

ESXの版とビルド番号は、vSphere Clientのホストの「サマリー」タブで確かめられます。PowerCLIでは、Connect-VIServerで接続したあと、次のコマンドで一覧にできます。[2]

Get-VMHost | Select-Object Name,Version,Build

1. 更新はオンラインのデポに公開され、vSphere Lifecycle Managerから当てられます。新しい版が出てこないときは、定期の同期を待たずにvCenterでデポを同期します。[2]
2. 更新は累積なので、前のパッチを先に当てる必要はありません。vCenterとESXの組み合わせは、VMware Product Interoperability Matrixで確かめます。[2]
3. ESXの更新ではホストの再起動が要ります。vMotionで仮想マシンをほかのホストへ移しながら、1台ずつ再起動します。vMotionで移せない仮想マシンは、再起動の間は止めます。環境によってはLive Patchで影響を減らせるため、各版のリリースノートで確かめます。[2]
4. 上げたあと、もう一度ビルド番号を確かめ、表の修正版以上になっていることを確認します。[1][2]

保守の会社に頼むときは、CVE-2026-41709と同じ勧告のVMSA-2026-0006の番号、ホストごとのいまの版とビルド番号、上げる先の版（上の表）を伝えます。

すぐに上げられないとき

Broadcomは、CVE-2026-41709の回避策は無いとしています。補足のFAQでは、ほかの緩和策や代わりの対策を頼るかは、各組織が自分で決めるとしています。[1][2]

ESXi 7.0・6.7を使っているとき

vSphere 7は2025年10月2日に一般サポートが終わっています。Broadcomは7.0もこの勧告の対象としており、延長サポートの契約がある組織は、その手続きで修正を求めます。[2]

6.5と6.7は、Broadcomが一般サポートの終わった製品を評価しないため、対象と考えるよう求めています。Broadcomは、古い版を使っている組織にVCF 9.1への移行を強く勧めています。[2]