NetScaler ADCとNetScaler Gatewayについて、特定の構成でリモートコード実行やサービス拒否につながる脆弱性CVE-2026-107406が公表されています。対象判定では、製品名や「SAMLを使っている」という情報だけでなく、稼働している版とSAMLでの役割を組み合わせて確認する必要があります。
本記事は2026年10月12日に確認したベンダーの公式情報をもとに、通常版14.1・13.1の確認順を整理します。FIPS・NDcPPなどの特殊な版は通常版の表へ当てはめず、公式告知の該当欄と契約サポートで確認してください。
10月8日公表の脆弱性で、何を確認するか
公式セキュリティ情報CTX697191では、本件をメモリーの範囲を越える処理に関係する脆弱性と説明し、条件を満たすとリモートコード実行またはサービス拒否につながるとしています。初回公表日は2026年10月8日です。Citrix公式セキュリティ情報
公式の関連ブログは深刻度をCritical、CVSS v4.0基本値を9.5としています。これは自社が侵害された確率や被害件数ではありません。今回の情報だけで、自社への攻撃やデータ流出が起きたと断定することはできません。NetScaler公式の対応案内
まず必要なのは、自社の実稼働版と設定を特定することです。公表日、今回の情報確認日、装置の更新適用日は別の記録として扱います。
SAMLのIdPとSPを混同しない
SAMLによるシングルサインオンでは、認証情報を提供する側をIdP、サービスを提供し認証結果を受け取る側をSPと呼びます。Microsoftの説明でも、SPからIdPへ認証要求を渡し、IdPからサービスへ応答を返す流れが示されています。MicrosoftのSAML SSO解説
この区別が重要なのは、本件の影響条件が版によって異なるためです。通常版の公式条件を整理すると次のようになります。表は記載した範囲だけを示し、記載のない版を安全と認定するものではありません。
| 通常版の系列 | SAML IdP構成が条件となる範囲 | SAML SPまたはIdP構成が条件となる範囲 | ベンダーが示す修正版 |
|---|---|---|---|
| 14.1 | 14.1-73.37〜14.1-73.41（両端を含む） | 14.1-73.37より前 | 14.1-73.46以降 |
| 13.1 | 13.1-64.23〜13.1-64.28（両端を含む） | 13.1-64.23より前 | 13.1-64.29以降の13.1 |
出典：CTX697191のAffected VersionsとWhat Customers Should Do。FIPS・NDcPPの対象条件と修正版は同ページの別記載を参照してください。
例えば、通常版14.1-73.37より古い装置をSAML SPとして使っている場合、「IdPとして動かしていない」という理由だけで対象外にはできません。逆に、対象条件の判定と、不正アクセスの痕跡があるかの調査も別です。この表は侵害の有無を判断するものではありません。
設定確認は、運用台帳と実機の差を埋めるところから
公式情報は、SAML SPの設定に対応する文字列として add authentication samlAction、IdPについて add authentication samlIdPProfile を挙げています。公式の構成確認方法
これらは本稿から実行を求める設定追加コマンドではなく、既存の設定を確認するために公式が示した識別文字列です。確認のために認証設定を追加・変更しないでください。設定の取得方法と解釈は、自社の運用手順および対象版の公式案内に従います。
以下は確認漏れを防ぐための本稿の記録例です。秘密鍵・パスワードや設定全体を広く共有する必要はありません。
| 記録する項目 | 残す内容の例 |
|---|---|
| 対象 | 管理用の装置識別子、管理担当、構成上の役割 |
| 版 | 実機で確認した版、確認日時、台帳との差 |
| SAML構成 | SP／IdP／判断未了と、参照した設定箇所 |
| 対応 | 該当する公式条件、更新先、実施担当、確認予定 |
| 完了 | 更新後の版、ログイン確認の結果、未解決事項 |
構成が把握できなければ、未確認を対象外へ置き換えず、管理担当・保守先と照合します。公式ブログは顧客管理の装置とCitrix管理のクラウドサービスの扱いも区別しているため、誰が更新を実施する環境かを併せて確認してください。
更新を「配布済み」で終わらせない
影響する装置には、ベンダーが修正版への速やかな更新を求めています。具体的な更新順、互換性、冗長構成での操作は環境ごとに確認し、この記事を製品のアップグレード手順の代わりには使わないでください。
本稿の提案として、更新作業は「対象確定」「適用」「稼働確認」を分けて記録します。例えば、更新ファイルを用意しただけの状態と、実機の版が変わり、必要な認証・接続を確認した状態を同じ完了欄にしません。複数台ある場合は一台の結果を全台の結果として扱わないようにします。
更新した事実だけから、それ以前に侵害がなかったとも判断できません。不審な挙動や痕跡がある場合は、通常の更新記録と調査記録を区別して保全し、組織のインシデント対応手順へ接続してください。攻撃方法を試して対象判定する必要はありません。
運用手順の役割分担は運用手順書の整理も参考になります。適用前には公式セキュリティ情報の改訂を確認し、版と構成に合う条件を再照合してください。基盤構成や運用分担の整理については、テクノヴァースのインフラ支援をご覧ください。