NetScalerでサービス拒否を招く脆弱性
企業システムにおいて、NetScaler ADC(アプリケーションへの通信を振り分ける機器)やNetScaler Gatewayを利用する環境があります。今回の確認対象は、NetScaler ADCまたはGatewayでSAML(認証などのセキュリティ情報を交換する仕様)を使う構成です。SP(サービス提供側)またはIdP(認証情報の発行側)としての利用が対象です。[1]
たとえば、社員が社内ポータルや業務システムにサインインする入口にNetScalerを配置している運用環境を想定します。運用担当者は、入口機器が停止した場合のサインイン方法を、代替経路の有無も含めて確認します。
CVEは公表された脆弱性を識別する番号です。Citrixが公表したCVE-2026-88779は、メモリオーバーフローの脆弱性です。確保した領域を超えてデータが溢れる問題で、CWE-119(メモリ範囲の不適切な制限)に分類されます[3]。公式告知が扱っている影響はサービス不能(DoS: Denial of Service)であり、サービスの可用性を損なう事象を対象としています[3]。
脆弱性の深刻度を評価する共通脆弱性評価システム(CVSS)v4.0の基本値は8.7です[3]。この基本値は、脆弱性そのものの深刻度を評価した指標です[3]。本稿では、この値と自社の機器構成・被害想定を照合し、対応順を決める方法を提案します。
通常版と規格準拠版の4系列に応じた修正版への更新
今回の対象は、顧客管理環境でSAML SPまたはSAML IdPとして構成されたNetScalerです[1]。影響を受ける4系列のバージョン境界と推奨される更新先を以下の表にまとめます[5, 6]。
NetScalerには通常版とFIPS版・NDcPP版の系列があります。[6]
米国国立標準技術研究所(NIST)の公式説明によると、FIPS(Federal Information Processing Standards)は米国の連邦コンピュータシステム向けの規格です。
NDcPPの公式文書は、ネットワーク機器のセキュリティ機能と保証の要件を定める保護プロファイルです。
Citrixの告知では、通常版とFIPS版・NDcPP版のそれぞれについて、影響を受けるバージョンの境界と更新先となる修正版が個別に示されています[5, 6]。
| 製品および系列 | 影響を受けるバージョン | 推奨される更新先 |
|---|---|---|
| NetScaler ADC / Gateway 通常版14.1 | 14.1-73.41未満[5] | 14.1-73.41以降[5] |
| NetScaler ADC / Gateway 通常版13.1 | 13.1-64.28未満[5] | 13.1-64.28以降[5] |
| NetScaler ADC 14.1-FIPS | 14.1-73.41 FIPS未満[6] | 14.1-73.41 FIPS以降[6] |
| NetScaler ADC 13.1-FIPS / 13.1-NDcPP | 13.1-37.282未満[6] | 13.1-37.282以降[6] |
Citrixは、影響を受ける機器を同じ製品・系列の修正版以降へ速やかに更新するよう強く勧めています[2]。特に通常版13.1と13.1-FIPS/NDcPP版では指定番号が異なります。自社で稼働している製品系列と完全に一致する修正版を選択することが重要です。
SAML連携の通常機能と確認対象となる2つの役割
SAML(Security Assertion Markup Language)は、組織間やシステム間で認証などのセキュリティ情報をやり取りする標準的な仕様です[4]。Webシングルサインオン(SSO)では、一度の認証によって連携する複数のWebサービスへ円滑にアクセスできるようになります[4]。
SAMLによるWebシングルサインオン環境では、主に2つの役割が連携して動作します[4]。ひとつは利用者の認証を行い、その結果をassertion(証明情報)として伝えるidentity provider(IdP)です[4]。もうひとつはその情報を受け取り、自らのアクセス方針に照らしてサービス利用を判断するservice provider(SP)です[4]。
Citrixの公式告知によると、NetScalerがSAML SPまたはSAML IdPとして構成された環境が、今回の脆弱性の前提条件です[1]。SAML連携は業務で利用されることがあります。今回の対応で求められるのは、特定のNetScaler構成とソフトウェア版を確認し、指定された修正版へ更新することです。[1, 2]
既存の設定記述から、NetScalerがSAML SPまたはSAML IdPとして構成されているかを確認できます[4]。脆弱性の対象かどうかは、管理主体と製品系列・ソフトウェア版も合わせて照合します[8, 5, 6]。
| NetScalerの構成役割 | SAML連携における機能 | 既存構成で確認する文字列 |
|---|---|---|
| SAML SP | 認証結果の情報を受け取り、アクセス方針に照らして利用を判断[4] | add authentication samlAction[4] |
| SAML IdP | 利用者の認証に関する情報をassertionとして伝達[4] | add authentication samlIdPProfile[4] |
表に示した文字列は、稼働中の既存構成に該当する記述が存在するかを確認するためのものです[4]。運用担当者は既存構成を読み取り、表の記述の有無を確認します。
後輩SAML連携を使っている場合、どのような点を確認すればよいですか?
先輩NetScalerがSAML SPかSAML IdPのどちらかとして動いている構成と、そのソフトウェア版を確認するよ。
後輩既存構成に該当する記述があるかを確認するんですね。
先輩その通りだね。稼働中の構成を読み取り、SAMLの設定と製品系列を照合することが大切だよ。
顧客管理環境とクラウド提供元管理の責任範囲を見極める
脆弱性への対応を計画するにあたっては、自社で利用している機器の管理主体を正確に把握することが不可欠です。責任範囲の所在によって、利用企業自身が作業を行うべき対象が明確になります。
Citrixの公式告知は、顧客管理(customer-managed)のNetScaler ADCとNetScaler Gatewayを対象にしています[1, 8]。顧客管理(customer-managed)に該当するNetScaler ADC/Gatewayが、利用企業側の確認と更新の対象です[1, 8]。
Citrix管理のクラウドサービスとAdaptive Authentication環境では、Cloud Software Groupが必要な更新を実施します[1, 8]。
クラウド連携を利用しているハイブリッド環境においても、責任範囲の確認が必要です。Secure Private Access Hybridにおいて使用するNetScalerインスタンスも、今回の公式告知の対象に含まれています[1, 7]。該当するNetScalerインスタンスについては、利用企業側での更新が必要です[1, 7]。
Citrixは、該当する機器に対して修正版への速やかな更新を強く推奨しています[7]。
本稿の運用上の提案として、クラウドサービスの利用状況に加え、契約形態や運用分担を照合することを勧めます。自社が管理責任を持つNetScalerインスタンスを資産台帳と照らし合わせて漏れなく特定することが大切です。
KEV登録に基づく対応優先度の判断と侵害調査の独立した実施
ソフトウェアの更新だけでは、過去の攻撃による機器の侵害確認にはなりません[11]。また、米国の拘束的運用指令(BOD 26-04)に定められた対応期限は、米国の連邦文民行政部門を対象としています[12]。自社環境の優先度判断と調査にあたっては、以下の根拠と詳細を確認してください[10, 11]。
脆弱性への対応を進める際は、公表された日付や外部機関の登録情報を正しく位置づけることが重要です。Citrix公式告知の履歴における初版公開日は2026年10月3日(米国太平洋標準時:PST)です[9]。また、技術メディア「The Hacker News」の記事公表日は2026年10月5日です[9]。これらの日付は告知や記事の公表日です。攻撃開始日や被害発生日は、別の情報で確認してください[9]。
CISAは米国のサイバーセキュリティ機関です。KEV(Known Exploited Vulnerabilities)は悪用が確認された脆弱性のカタログです。KEVカタログの版を示すcatalogVersionが2026.10.04の記録では、CVE-2026-88779が追加日(dateAdded)2026年10月4日として登録されています[10]。
この登録は、実際に悪用が確認された脆弱性として、各組織が対応の優先度を判断するための有力な材料になります[10]。
一方で、dateAddedはカタログへ追加された日付であり、脆弱性の公表日や攻撃開始日とは異なります[10]。KEV登録は対応優先度を判断する材料です。各組織の侵害状況や被害件数は、個別の調査で確認します[10]。同じ行のランサムウェア利用欄も「Unknown」と記載されており、ランサムウェアでの悪用状況は不明です[10]。
KEVの登録行の対応期限(dueDate)は2026年10月7日で、今回の更新確認時点では経過しています[12]。この対応を求めるBOD 26-04(Binding Operational Directive 26-04)は、米国の連邦文民行政部門向けの指示です。対象は同部門の機関とシステムです[12]。
BOD 26-04の対象は米国の連邦機関です。日本企業は、自社に適用される法令や契約に基づいて対応期限を判断します[12]。
BOD 26-04の本文では、フォレンジック・トリアージ(forensic triage)を機器が侵害されているかを確かめる作業と説明しています[11]。指定された条件において、脆弱性の修正や緩和(remediation/mitigation)に加えて行うものと位置づけられています[11]。
KEVの登録行は、ベンダーの指示による対処に加え、BOD 26-04のガイダンスとForensics Triage Requirementsへの対応を求めています。forensicTriage欄は「Yes」です[11]。
脆弱な実装を修正するソフトウェア更新と、過去の攻撃の影響を確かめる侵害確認は、目的の異なる独立した作業です[11]。ソフトウェアを更新したという事実だけでは、機器が侵害されていないことの証明になりません[11]。
本稿の運用上の提案として、資産台帳で製品名、系列、稼働バージョン、SAMLの役割、管理主体を照合することを勧めます。該当機器のソフトウェア更新と、過去の侵害有無を確かめる調査を、それぞれ独立した作業として計画することが適切です。
本稿では、運用担当者が更新作業の完了後に、実際の稼働バージョンと社員の通常のサインイン動作を確認することを提案します。修正の適用とサービス利用の継続性を確かめるための助言です。作業の際は、常に最新のCitrix公式告知とCISAカタログを確認してください。
後輩修正版への更新を終えれば、過去の機器の状態も確かめられたことになりますか?
先輩更新は脆弱性を修正する作業だから、過去に影響を受けたかどうかは別の調査が必要だよ。
後輩不具合の解消と、侵入の有無を調べることは、目的が異なる個別の作業なんですね。
先輩BOD 26-04は米国連邦機関の指定条件に向けた指示だよ。本稿の運用案として、更新と過去の侵害調査を別々に計画しよう。



