NetScalerの脆弱性CVE-2026-88771とは？影響ビルドの確認コマンドと侵害調査の手順

Citrix（Cloud Software Group）は2026年9月27日、NetScaler ADCとNetScaler Gatewayの脆弱性8件を公表しました。中心となるCVE-2026-88771は、認証されていない攻撃者が任意のコマンドを実行できるリモートコード実行の脆弱性で、既定の構成でも成立し、公表前から悪用されていたゼロデイです。この記事では、影響を受けるビルドと修正版の選び方、自社のNetScalerが対象かをCLIで判定するコマンド、更新前に行う侵害調査、更新後に残るTCP設定の変更までを、実装者の目線で整理します。記載内容は2026年9月30日時点の公開情報にもとづきます。

まとめ：NetScalerは修正版への更新と更新前の侵害調査を同じ日に進める

CVE-2026-88771は、14.1系なら14.1-73.37より前、13.1系なら13.1-64.23より前のNetScaler ADCとNetScaler Gatewayのすべてが対象です。特別な機能を有効にしていなくても成立するため、「うちの構成は関係ない」という切り分けは効きません。回避策も提供されていません。

やることは3つに絞れます。第一に修正版への更新、第二にその前の侵害調査と証拠の保全、第三にCVE-2026-88778向けのTCP設定変更です。更新は侵入済みの攻撃者を追い出さないので、調査を省くと「パッチは当てたが中は乗っ取られたまま」という状態を残します。

NetScaler Gatewayを社内システムへの入口にしている場合は、その先の業務システムの認証情報まで点検範囲に入れます。拠点や案件をまたいで入口機器を抱えているなら、外部の脆弱性診断で機器の棚卸しから進めると抜けが出にくくなります。

CVE-2026-88771・88772の中身とゼロデイ悪用から注意喚起までの時系列

NetScaler ADCは、負荷分散やSSL終端を担うロードバランサー（ADC）の製品で、NetScaler GatewayはそのSSL-VPNとリモートアクセスの機能です。どちらもインターネットに直接面して置かれるため、入口の脆弱性はそのまま社内への侵入経路になります。

不適切な入力検証によるRCEがデフォルト構成でも成立する条件

Citrixのセキュリティ公告CTX697096によれば、CVE-2026-88771の型はCWE-20（不適切な入力検証）で、CVSS v4.0の基本値は9.5です。前提条件の欄は「すべてのデプロイ」とされ、既定の設定のままで影響を受けます。スコアの読み方はCVSSの見方とv4.0の変更点で解説しています。

もう1件の悪用確認済みであるCVE-2026-88772は、CWE-119（メモリバッファの境界外操作）で、同じく9.5です。こちらはDTLSが有効な場合に限られますが、VPN仮想サーバーではDTLSが既定で有効です。Gatewayを使っている環境は、ほぼ両方に当たると考えてください。

CVE-2026-88773〜88778の6件と前提となる構成の一覧

同じ公告で公表された残りの6件は、悪用の確認こそ出ていないものの、構成によっては8点台後半の評価です。

実務でまず見るのは上の2行だけで足ります。残りの6件は、修正版へ更新すれば88778を除いて同時に解消するため、個別に対処を組む必要はありません。88778だけは更新後の設定変更が要るので、後の章で扱います。

9月24日の国内攻撃試行からCISA KEV登録までの時系列

公表の前から攻撃が始まっていた点が、今回の特徴です。

JPCERT/CCの注意喚起は、88771と88772について回避策が無いことと、国内を狙った攻撃試行が9月24日以降に確認されていることを明記しています。CISAのアラートも、両CVEを既知の悪用脆弱性（KEV）カタログへ加えたうえで、世界中で悪用が進んでいると述べています。

NetScalerの影響ビルドと修正版14.1-73.37・13.1-64.23の選び方

更新先は系列ごとに1つずつ決まっています。迷いやすいのは13.1系とFIPS版の扱いです。

14.1系・13.1系・FIPSとNDcPP版ごとの対象ビルドと更新先

CTX697096が示す対象と修正版は次のとおりです。

• NetScaler ADC・Gateway 14.1：14.1-73.37より前が対象。14.1-73.37以降へ更新
• NetScaler ADC・Gateway 13.1：13.1-64.23より前が対象。13.1-64.23以降へ更新
• NetScaler ADC 14.1-FIPS：14.1-73.37 FIPSより前が対象
• NetScaler ADC 13.1-FIPS・13.1-NDcPP：13.1-37.279より前が対象

FIPS・NDcPP版の13.1は、通常版と番号の体系が違います。「13.1-64.23より後の番号だから安全」と読み違えないよう、系列名とビルド番号を組にして確認します。公告には12.1系・13.0系への言及がありません。すでにサポートを終えた系列であり、修正版の提供を待つのではなく、サポート対象の系列へ移る計画を先に立てるべきです。

13.1系で報じられている再起動ループの既知問題とshow ns variable

13.1系については、13.1-64.23へ更新する途中で、特定の構成のアプライアンスが再起動を繰り返す既知問題があると、複数のセキュリティ事業者が報じています。報道によれば、CLIで show ns variable を実行して変数が1つでも表示される環境は、13.1-64.24を使うよう案内されています。

この案内は9月30日時点のCTX697096本文には記載がなく、Citrix Community側の情報として伝えられているものです。13.1系を更新する前には、公告とNetScalerのダウンロードページで最新のビルドを確認し、show ns variable の出力も記録しておくと、切り戻しの判断材料になります。

Citrix管理クラウドとSecure Private Accessハイブリッドの扱い

Citrixが運用するクラウドサービスは、Cloud Software Group側で更新すると公告に書かれています。利用者の作業は要りません。

見落としやすいのは、Secure Private Accessをハイブリッド構成で使っている場合です。公告は、NetScalerのインスタンスを使うSecure Private Accessのハイブリッド構成も影響を受けると明記しています。クラウドのサービスだからと安心せず、手元に置いたNetScalerを更新の対象に含めます。

NetScaler CLIで稼働ビルドと影響構成を確認するコマンドと結果の読み方

判定はNetScalerのCLIに入れば数分で終わります。ここでは設定を変えない表示系のコマンドだけを使います。

show ns versionとrunningConfigで対象を切り分ける手順

稼働中のビルドはCLIリファレンスのshow ns versionで、実行中の設定はshow ns runningConfigで確認できます。設定から探す文字列は、CTX697096が各CVEの前提条件として示したパターンです。

# 1. 稼働中のバージョンとビルド番号を確認する
show ns version

# 2. CVE-2026-88772：VPN仮想サーバーの有無と DTLS の設定を確認する
show ns runningConfig | grep -i "add vpn vserver"

# 3. CVE-2026-88775：Gateway と AAA（認証）仮想サーバーの有無
show ns runningConfig | grep -i "add authentication vserver"

# 4. CVE-2026-88773・88774：HTTP または SSL の LB／CS 仮想サーバー
show ns runningConfig | grep -iE "add (lb|cs) vserver .* (HTTP|SSL) "

# 5. CVE-2026-88776：Oracle 型の負荷分散仮想サーバー
show ns runningConfig | grep -iE "add lb vserver .*ORACLE"

# 6. 13.1系の更新前に、既知問題の対象かを記録する
show ns variable

1の出力が14.1-73.37・13.1-64.23（FIPS・NDcPP版は前節の番号）より前なら、構成にかかわらずCVE-2026-88771の対象です。2で add vpn vserver の行が出て、その行に -dtls OFF が無ければ、DTLSは既定の有効のままで88772にも当たります。

3〜5は、付随するCVEが自社で意味を持つかを見るためのものです。更新すれば解消するので、結果によって更新の要否は変わりません。ただし、侵害調査で見るべきログの範囲や、更新後の動作確認で試す機能を決める材料になります。

DTLSやGatewayの有無で付随CVEの優先度を読み替える基準

判定結果は、次の順で優先度に置き換えます。

1. 2でVPN仮想サーバーが出た環境：88771と88772の両方に当たる。インターネットに面したGatewayなら当日中の更新対象
2. VPNは無いが1で対象ビルドの環境：88771だけでも既定構成で成立するため、同じく当日中の更新対象
3. 3〜5で行が出た環境：更新後の動作確認で、該当する認証・負荷分散・プロトコルを通しで試す

社内ネットワークからしか届かないNetScalerでも、緊急度はわずかに下がるだけです。社内の端末が1台乗っ取られれば、そこから同じ攻撃を送れます。数日以内の計画停止で更新し、それまでは管理者が届く経路を絞る、という線引きにとどめます。

更新前に侵害を調べるNetScaler ConsoleのIoC検出と証拠保全の順序

JPCERT/CCは、修正版の適用に加えて、Citrixが提供する侵害指標（IoC）の確認を求めています。CISAはさらに踏み込み、更新の前に侵害の兆候を探すよう勧めています。

IoC検出の前提になるテレメトリ登録と5種類の判定結果の意味

NetScaler ConsoleのIoC検出のドキュメントによると、この機能を使うにはNetScalerのテレメトリプログラムへの登録が前提です。スキャンはSecurity Advisoryのページから実行し、結果は次の5種類で返ります。

• Potentially Compromised：侵害の可能性あり。直ちに保全と調査へ
• No Compromise Detected：既知の指標には該当せず
• Skipped：条件を満たさず実行されていない
• Failed to Execute：実行に失敗
• Execution in Progress：実行中

読み違えやすいのは2つ目です。同じドキュメントは、IoCの情報が攻撃者の手口をすべて網羅するものではないと断っています。「検出されず」は「侵害されていない」の証明になりません。SkippedとFailed to Executeが混ざる場合は、その機器を手作業の調査対象に回します。

更新でフォレンジックの可視性を失わないための証拠保全と作業順序

CISAのアラートは、更新によってフォレンジックの可視性が失われうるため、適用の前に証拠を保全するよう求めています。CISAは、侵害が疑われる場合のCitrixの対応手順（CTX694799）も参照先に挙げています。作業の順番は次のとおりです。

1. IoC検出を実行し、結果を記録する
2. 設定ファイルとログ、前章のコマンド出力を機器の外へ退避する
3. Potentially Compromisedなら、更新より先に保全と外部調査の手配を優先する
4. それ以外は修正版へ更新し、CLIで稼働ビルドを確認する

更新作業そのものは、NetScaler ConsoleのCVE-2026-88771修復手順に沿えば、Impacted Instancesで対象を選び、Proceed to upgrade workflowから複数台をまとめて更新できます。脆弱性スキャンは完了まで数時間かかることがあり、急ぐ場合はScan-Nowで即時に走らせます。

痕跡が1つでも見つかったら、その機器での自己調査を続けるより、ログとディスクの保全を優先します。証拠を壊さずに調べる進め方はデジタルフォレンジックの流れで、ログを長期に集めて相関を見る設計はSIEMの仕組みで整理しています。

更新後に残るCVE-2026-88778のTCP設定変更と業務システム側の後処理

修正版へ上げても、それだけでは終わらない作業が2つあります。1つはNetScaler自身の設定、もう1つはGatewayの先にある業務システムです。

Enhanced ISN Generationを有効化する設定変更と確認コマンド

CTX697096は、CVE-2026-88778の影響を受ける環境に対し、更新に加えてTCPの設定変更を適用するよう求めています。変更するのは、SYN-ACKで返す初期シーケンス番号のばらつきを大きくする設定です。CLIリファレンスのns-tcpParamでは、このパラメータの既定値はDISABLEDとされています。

# 現在の設定を確認する（CTX697096 記載のコマンド）
show ns tcpparam | grep "Enhanced ISN Generation"

# 有効化する（set ns tcpParam のパラメータ）
set ns tcpParam -enhancedISNgeneration ENABLED

# 再起動後も残るよう設定を保存する
save ns config

# 反映を確かめる
show ns tcpparam | grep "Enhanced ISN Generation"

1行目の出力がDISABLEDのままなら、修正版に上げていても88778は残っています。冗長構成では、両方の機器で最後の確認コマンドを実行してください。

NetScaler Gateway経由でつながる業務システムの認証情報を見直す範囲

ここからは、NetScalerの運用担当ではなく、Gatewayの先にある業務システムやWebシステムを作る側の話です。リモートコード実行が成立したNetScalerでは、そこを通った通信と、そこに置かれた秘密情報を漏れたものとして扱うのが安全側の判断です。

IoC検出で侵害の可能性が出た場合、または露出期間のログが残っておらず否定できない場合は、少なくとも次を入れ替えます。

• Gatewayに設定したLDAPやRADIUSの連携用アカウントの資格情報
• SAMLなどで連携する業務システム側の証明書と署名鍵
• VPN経由でログインした利用者のセッションと、管理者アカウントのパスワード

逆に、IoC検出で問題が無く、露出期間の全ログを確認して痕跡も無かった環境で、全資格情報まで入れ替えるのは過剰対応です。作業の重さと利用者への影響が、得られる安全を上回ります。

NetScalerを入口に使い続けてよい条件と見直すべき条件

NetScalerは2026年だけでも注意喚起が繰り返されています。JPCERT/CCは今回のat260029の前にも、CVE-2026-3055（境界外読み取り）やCVE-2026-8452（リモートコード実行）で注意喚起を出しました。入口機器を替えるべきかという相談が出るのは自然です。

見直しを勧めるのは、保守契約が切れている、更新を当日中に当てる体制が無い、13.1より古い系列から抜け出せていない、のいずれかに当たる場合です。この条件では、次のゼロデイでも同じ遅れが出ます。

使い続けてよいのは、保守契約があり、今回の修正版を公表から数日以内に当てられた場合です。この条件なら、移行作業のリスクのほうが大きくなります。同じ判断は他社の入口機器にも当てはまり、BIG-IPの脆弱性CVE-2026-94127の対応やFortiGateの脆弱性と仮想パッチでも、更新体制を軸に整理しました。複数の入口機器と下流のアプリをまとめて点検するなら、脆弱性診断・セキュリティ診断で外部からの到達性と構成を棚卸しすると、更新の順番を決めやすくなります。

NetScalerの脆弱性CVE-2026-88771対応でよく受ける質問と実務的な回答

CVE-2026-88771の対応を進める際に出てきやすい疑問を、公開されている一次情報の範囲で答えます。

NetScaler Gatewayを使わずADCだけの構成でも更新は必要ですか？

必要です。CVE-2026-88771の前提条件は「すべてのデプロイ」で、既定の構成でも成立します。Gatewayの機能を使っていないADC単体の構成でも、14.1-73.37・13.1-64.23より前のビルドなら対象です。Gatewayを使っていない場合に外れるのは、DTLSを前提とするCVE-2026-88772などの付随するCVEだけです。

回避策や一時的な緩和策はありますか？

JPCERT/CCの注意喚起では、CVE-2026-88771とCVE-2026-88772に回避策は提供されていないとされています。できるのは、更新までの間に管理者が届く経路を絞り、IoC検出と証拠の保全を先に済ませることです。これは侵害の発見を早める手段で、脆弱性を塞ぐものではありません。更新を後回しにする理由にはなりません。

IoC検出で「No Compromise Detected」なら侵害はないと判断してよいですか？

判断できません。NetScaler Consoleのドキュメントは、IoCの情報が攻撃者の手口をすべて網羅するものではないと明記しています。検出されなかったことは、既知の指標に当たらなかったという意味にすぎません。国内への攻撃試行は9月24日以降に確認されているため、その日以降のログを自前でも確認し、SkippedやFailed to Executeになった機器は手作業で調べます。

13.1系は13.1-64.23と13.1-64.24のどちらへ更新すべきですか？

公告が示す修正版は13.1-64.23以降です。ただし13.1-64.23には、特定の構成で更新中に再起動を繰り返す既知問題があると報じられています。更新前に show ns variable を実行し、変数が表示される環境は13.1-64.24を選ぶよう案内されているとの報道です。作業前にCitrixの公告とダウンロードページで最新ビルドを確かめてください。

サポートが終了した12.1系や13.0系を使っている場合はどうすればよいですか？

CTX697096には12.1系と13.0系への言及がなく、修正版の提供も示されていません。影響が無いと読むのではなく、評価も修正もされていないと読むべきです。インターネットに面して使っているなら、サポート対象の14.1系か13.1系へ移る作業を最優先で計画し、それまでは公開範囲を絞ったうえで侵害調査を先に行います。

関連記事

• 脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説：脆弱性が公表から修正に至る流れの基礎を確認できます。
• CVE（共通脆弱性識別子）とは？仕組み・CVSS/CWE/NVDとの違いと2026年の運営体制変化：CVE-2026-88771のような識別子とCWEの関係を整理しています。
• VMwareの脆弱性とセキュリティ対策｜悪用済みCVE一覧とVMSAの確認・パッチ手順【2026年9月】：入口機器と並んで狙われる仮想化基盤の悪用済みCVEです。
• CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説：単発の緊急対応でなく、入口機器の露出を継続的に管理する考え方です。
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説：NetScalerを含む入口機器と下流のアプリをまとめて点検する際の進め方です。