NetScaler認証バイパスCVE-2026-19490の悪用試行が始まった。半年で三度揺れたNetScalerを入口に、オフショアBPO・外部人材のアクセス設計を「許可したIP≠許可した人」の視点から、ID・権限・業務要員・BCPまで含めて問い直す。
「Citrix NetScalerにCriticalな脆弱性」。
こう聞くと、ネットワーク機器を管理しているIT部門のニュースに見える。
しかし、NetScaler Gatewayを使ってオフショアBPOや外部人材を社内業務につないでいる企業にとっては、それだけの話ではない。
中国やフィリピン、インドなどのオフショアBPO。
国内の委託先。
在宅勤務の社員。
フリーランサーや個人事業主。
社外にいる人へ仕事を任せながら、会社のデータはできるだけ相手のPCへ置かせない。そのために発注企業側に仮想デスクトップや仮想アプリケーションを用意し、決められた経路からだけアクセスさせる。
NetScaler Gatewayは、その「安全な業務経路」を実現するために使われる製品の一つだ。
Citrix自身も、NetScaler Gatewayを組織ネットワークの境界やDMZに配置し、外部ユーザーが内部のサーバーやアプリケーションへアクセスするための安全な単一アクセスポイントとして利用する構成を説明している。
つまり今回考えたいのは、
「NetScalerに脆弱性が出た。パッチを当てよう」
だけではない。
外部の人に安全に仕事をさせるために作ったアクセス設計そのものが破られたとき、
誰が入ってきたのか分かるのか。
止められるのか。
そして止めたあとも会社は動くのか。
という問題だ。
2026年だけを見ても、NetScalerでは重大な脆弱性が繰り返し公表されている。
3月23日、CitrixはCVE-2026-3055とCVE-2026-4368を公表した。
3055は、特定のSAML IdP構成で成立するCriticalな脆弱性だった。4368はGatewayなどでユーザーセッションが混同する可能性がある問題だった。Citrixは修正版への更新を求めた。
6月30日にはCVE-2026-8452を含む6件を修正した。Citrixの当初の説明では、8452はメモリオーバーフローによる異常動作やDoSだった。
ところが8月14日、セキュリティ企業watchTowrがこの修正の差分を解析し、認証前のリモートコード実行まで到達し得ることを実証した。watchTowr自身は「CVE-2026-8452だと考えているが、確定的には紐付けられない」としているため、本稿でも「CVE-2026-8452とみられる脆弱性」としておく。この脆弱性は8月26日、米CISAの悪用済み脆弱性カタログ(KEV)に登録された。
「DoS」として説明された修正が、後から「RCEまで可能」と実証される。こういう揺れ方もある。
そして8月19日、今回のCVE-2026-19490が公表された。
CVSS v4.0は9.3のCritical。
一定の構成でNetScaler Gatewayや認証用の仮想サーバを使っている場合、本来行われるべき認証を「別の経路」から回避できる脆弱性だ。
Citrixの表現は、
Authentication bypass using an alternate path
である。
影響する14.1系は14.1-73.32以降、13.1系は13.1-63.21以降などへ更新する必要があり、Citrixは回避策を「None」としている。
9月2日にはPoCが公開され、翌9月3日にはPrevidianのセンサーがPoCに一致する悪用試行を観測した。
Previdianの観測では6回の試行、4つの送信元IP、豪州・ドイツ・米国の3か国が確認されている。ただし、これは攻撃を試したことを示す観測であって、実際の企業システムへの侵害成功を確認したものではない。
8月19日のパッチ公開から約2週間だった。
Rapid7も公表時点から、この脆弱性について緊急ベースでの更新を推奨していた。
問題は、この2週間の間に企業が何をできるかだ。
今回のCVEを専門用語なしで考えてみる。
通常、社外にいるBPO担当者がCitrixを使って仕事をするとき、いきなり会計システムや購買システムへ接続するわけではない。
まず会社が用意したリモートアクセス環境へ接続する。
そこで本人確認を受ける。
そして許可された人だけが、その先にある仮想デスクトップや業務アプリケーションへ進む。
NetScaler Gatewayを経由してリモートデスクトップへ接続するCitrixの構成でも、基本的には接続、SSL VPN確立、認証、その後にリモート環境へのアクセス、という順番になる。
今回の脆弱性は、この本人確認を別の経路から回避できる。
偽の社員証を作る、というより、
社員証を確認している受付を通らず、別の通路からその先へ進めてしまう。
その方が近い。
もちろん、そこで認証を越えただけでSAPの全データが見えるという意味ではない。
どのシステムへ到達できるか。
どんな権限を持てるか。
購買、会計、人事のどこまで触れるか。
それは企業ごとの構成による。
今回のCVEそのものに「新しい業務ユーザーを作成する機能」があるわけでもない。
しかし、侵入後さらに管理基盤やIAM、業務システムの高い権限まで取られれば、
既存IDを悪用する。
権限を追加する。
休眠アカウントを再利用する。
新しいIDを作る。
といった侵入後の活動まで考える必要が出てくる。
そしてBPOを使っている企業では、その先にあるのが、
購買、会計、人事、顧客対応
といった会社の実業務であることが少なくない。
ここを分けて考える必要がある。
今回のNetScaler脆弱性を直接狙う攻撃と、BPO担当者の端末を先に乗っ取る攻撃は別物だ。
一つ目は、
攻撃者 → インターネット → NetScaler
と直接来る。
CVE-2026-19490はネットワーク越し、認証不要で成立し得る脆弱性だ。
ただし、企業がNetScalerへの接続元をファイアウォールなどで厳しく限定し、BPO拠点の固定IPからしか到達できないようにしていれば、無関係なインターネット上のIPから直接攻撃するハードルは当然上がる。
IP制限は無意味ではない。
重要な防御層になり得る。
しかし、もう一つの攻撃経路がある。
攻撃者 → BPO担当者の端末 → 正規のBPOネットワーク → 日本企業側のNetScaler
である。
こちらは事情が違う。
たとえば従来のBPOセンターなら、
BPOオフィス → BPO会社の固定グローバルIP → 日本企業側NetScaler
という構成にできる。
日本側は、
「このBPO会社の固定IPから来た通信だけ許可する」
という制御ができる。
これは分かりやすい。
ところが、そのBPOセンター内のPC自体が乗っ取られたらどうなるか。
攻撃者がそのPCを遠隔操作して正規の接続経路を使えば、日本側から見える通信は、
いつものBPO会社の固定IP
から来る。
IPアドレスだけでは、
「大連の正規担当者が操作している」
のか、
「そのPCを乗っ取った攻撃者が操作している」
のかは判断できない。
さらにコロナ以降は、もう一段複雑になった企業もある。
たとえば、
自宅 → BPO会社のVPN → BPO会社のネットワーク → BPO会社の固定出口IP → 日本企業側NetScaler
という経路だ。
この場合、BPO担当者の端末を攻撃者が乗っ取り、その端末から正規のVPNへ接続できれば、日本企業側から見える送信元はやはり、
許可済みのBPO会社のIP
になり得る。
一方、在宅担当者がBPO側VPNを経由せず、自宅から日本企業側のNetScalerへ直接アクセスする構成なら、家庭回線のIPは一定とは限らない。
そうなると、そもそも「BPO拠点の固定IPだけ許可する」という境界自体が作りにくい。
つまり、
IP制限は重要だが、IPアドレスだけでは「その通信を本当に正規の人が操作しているか」までは証明できない。
ということだ。
もちろんCitrixにはIPアドレス以外の制御もある。
たとえばEndpoint Analysisでは、接続してくる端末が設定された条件を満たしているかを確認し、条件を満たさない端末のログオンを拒否できる。デバイス証明書などを条件に使うこともできる。
こうした端末確認、MFA、デバイス証明書、EDRなどを重ねることには意味がある。
しかし、それでも考えなければならないケースがある。
正規端末そのものが乗っ取られた場合だ。
正規のPC。
正規の証明書。
正規のVPN。
許可されたIP。
正規のID。
その組み合わせを攻撃者が利用した場合、境界部分だけを見て攻撃だと判別するのは難しくなる。
だから監視対象を、その先へ広げる必要がある。
たとえば、大連のBPOセンターで300人が働いているとする。
300人が毎日Citrixへログインする。
これは正常だ。
では301人になったらどうだろう。
新しいアカウントが一つ増えた。
名前はそれらしい。
Citrixに接続する。
VDIを開く。
SAPへ入る。
伝票を見る。
一つ一つの操作だけなら、日常業務に見えるかもしれない。
もちろん、今回のCVE-2026-19490が301人目を自動的に作ってくれるわけではない。
しかし侵入後、攻撃者がさらに管理権限まで奪えば、IDや権限を追加される可能性を考える必要がある。
そこで問題になるのが、
ITだけでは、その301人目が本当に正規要員なのか判断できない
ことだ。
BPOでは人数をかなり厳密に管理する。
300人契約。
300席。
Citrixライセンスはいくつ必要か。
同時接続数を超えていないか。
契約した要員数を超過していないか。
これは当然必要だ。
しかし、多くの場合はコスト管理や契約管理としての人数管理である。
セキュリティでは、問いを一つ変える必要がある。
「300人を超えていないか」ではなく、 「この300 IDは、本当に今そこにいる300人と一致しているのか」。
誰が今月入ったのか。
誰が辞めたのか。
誰が異動したのか。
誰が会計担当なのか。
誰が購買担当なのか。
誰が人事情報を見る必要があるのか。
昨日、新しいIDが作られた。
その人を業務責任者は知っているのか。
退職した担当者がまだCitrixへ接続していないか。
買掛金担当者に突然仕入先マスタの変更権限が付いていないか。
こうした異常は、NetScalerのログだけでは判断できない。
IT部門は、
「bpo_user_301というIDが存在する」
ことを知っている。
SOCは、
「そのIDが午前3時に接続した」
ことを知っている。
IAM担当者は、
「昨日、そのIDに新しい権限が追加された」
ことを知っている。
しかし、
その人が本当に大連の買掛金チームに存在するのか
を一番よく知っているのは、業務側だ。
逆もある。
業務部門では、
「来週から5人増員する」
ことが決まっている。
しかし、その情報がSOCやITへ届いていなければ、新しく5個のIDが作られたことが正常なのか異常なのか判断しにくい。
だからBPOを使う企業では、セキュリティ監視の対象をもっと広げる必要がある。
ネットワーク → IP → 端末 → ID → 認証 → 権限 → VDIセッション → 業務システムでの操作 → 実際の業務要員
までつなげて見る。
たとえば監視対象になるのは、
新しく作られたID。
退職者のID。
長期間使われていなかったIDの復活。
権限の追加・変更。
新しいVDIやアプリケーションの割り当て。
通常と違う場所や端末からの接続。
担当業務と関係のないシステムへのアクセス。
通常業務では考えにくい大量閲覧や大量取得。
そして、
BPOの実要員名簿とITアカウントの差分。
である。
これはSOCだけではできない。
業務部門、BPO管理、調達、人事、IAM、IT、SOCが同じ「人」を見なければならない。
では、Criticalな脆弱性が出たらCitrixを止めればいい。
セキュリティだけを考えれば、その判断は正しい。
今回のCVE-2026-19490もCitrixは速やかな更新を求め、回避策を示していない。
必要なら止めるべきだ。
しかしBPOを長年利用している企業では、その瞬間から別の問題が始まる。
止めたあと、誰が仕事をするのか。
経理BPOなら支払い処理。
購買BPOなら発注。
人事BPOなら給与や入退社処理。
それを、
「数日だけ日本側でやればいい」
と言える企業ばかりではない。
BPOを始めた直後なら、日本側に業務を知っている社員がいる。
日本側が仕事を教える。
手順書を書く。
海外側が質問する。
日本側が答える。
しかし5年、10年続くと、その関係が逆転することがある。
毎日SAPを操作しているのは大連の担当者。
どの伝票が月末にエラーになるか知っているのも大連。
この取引先だけ特殊な処理が必要だと知っているのも大連。
マニュアルに載っていない例外処理を知っているのも大連。
システム改修のたびに生まれた小さな運用ルールを知っているのも大連。
その間に日本側社員は異動する。
退職する。
そもそもBPOによって効率化したのだから、日本側の人数も減らす。
やがて、
日本の社員より、オフショアの担当者の方が、その会社の日々の実務を詳しく知っている。
という状況が生まれる。
これはBPOの失敗ではない。
むしろ長期間きちんと業務を移管してきた結果でもある。
だからこそ、元に戻すのは難しい。
Citrixを止めた。
では、日本側で処理する。
しかし人がいない。
業務知識がない。
権限がない。
操作経験がない。
マニュアルを読んでも処理できない例外がある。
では海外の担当者を日本へ呼べばよいのか。
これも緊急時には簡単ではない。
航空券。
宿泊。
作業場所。
PC。
ネットワーク。
システム権限。
人数によっては大きな費用になる。
さらに国籍や滞在期間、実際に日本で行う業務によっては、査証や在留・就労に関する確認も必要になる。
CriticalなCVEが今日出たから、明日から東京で100人働いてもらう。
という代替策にはならない。
BPOは、人を海外へ移すだけではない。 長く続ければ、業務知識そのものが海外へ移る。
そして一度移した知識を国内へ戻すのは、サーバを移設するよりはるかに難しい。
さらに、BPOを始めたときのセキュリティ前提が、そのまま残っているとは限らない。
以前なら、
管理されたBPOオフィス。
管理された端末。
固定されたネットワーク。
固定された出口IP。
そこから日本側のCitrixへ接続する。
という形だったかもしれない。
ところがコロナで在宅勤務が始まった。
自宅からBPO会社のVPNへ入り、その先から日本企業のCitrixへ接続する。
あるいは、自宅から直接リモートアクセスする。
その後、オフィス勤務が戻っても、在宅アクセスそのものは残った企業もある。
すると、
「大連センターの固定IPからしか来ない」
という最初のセキュリティ設計が、実際の働き方と一致しなくなる。
Citrixを導入した当時のネットワーク図と、2026年に人が実際に働いている経路を、一度照合した方がいい。
同じ問題はBPOだけではない。
フリーランサーや個人事業主を多数使うビジネスにも当てはまる。
外部の開発者。
デザイナー。
会計専門家。
コンサルタント。
翻訳者。
すべての企業がCitrixを使うわけではない。
しかし、
社外の人に自社システムを使わせたい。 でもデータはその人のPCへ残したくない。
という問題は同じだ。
BPO会社なら、まだ、
「大連センターに現在300人」
という組織単位の管理ができる。
フリーランサーなら、一人ずつ入って一人ずつ抜ける。
契約開始日も終了日も違う。
場所も端末も違う。
担当プロジェクトも違う。
必要な権限も違う。
すると管理すべきなのは、
「アカウントはいくつあるか」
ではなく、
「このアカウントを今日存在させる業務上の理由があるか」
になってくる。
これもITだけでは判断できない。
今回のNetScaler脆弱性を、
「Citrix担当者は早くパッチを当てましょう」
だけで終わらせるのはもったいないと思う。
NetScalerをやめれば解決する話でもない。
別のVPNへ変えても、ZTNAへ変えても、外部の人を会社の業務へ接続する以上、何らかのアクセス境界は残る。
必要なのは製品名を変えることより、設計の前提を問い直すことだ。
まず、直接攻撃への対策。
本当に世界中からNetScalerへ到達できる必要があるのか。
BPO拠点など接続元を限定できるなら、ネットワーク側で絞れないか。
次に、正規端末を奪われる前提。
許可IPから来たから安全、と判断していないか。
端末確認、MFA、デバイス証明書、EDRなどを組み合わせているか。
さらに侵入後。
新しいIDが増えたことを監視しているか。
権限変更を見ているか。
BPOの実要員とITアカウントを定期的に照合しているか。
誰がどの業務システムへアクセスする必要があるのか、業務側とIT側で一致しているか。
そしてBCP。
そのアクセス基盤を今日止めても、明日支払いはできるのか。
発注はできるのか。
給与処理はできるのか。
24時間止まった場合。
72時間止まった場合。
一週間止まった場合。
誰が代わりに仕事をするのか。
そしてもう一つ。Critical/KEV級の脆弱性が出た場合には、通常の変更承認プロセスを飛ばして緊急停止・緊急更新できる権限を、あらかじめ契約と運用手順に入れておくことだ。緊急時に「委託先に説明してから」を挟む設計のままでは、対応の速さは組織間調整の速さに律速される。
ここまで決めて初めて、
「Criticalだから今すぐ止める」
という判断が現実にできる。
BPOによって企業は業務を効率化した。
外部の専門家やフリーランサーによって、人材を柔軟に使えるようになった。
CitrixやVDIによって、データを相手のPCへ持たせずに仕事をさせることもできるようになった。
どれも合理的な進化だ。
それを否定する話ではない。
しかし、その仕組みが会社の重要業務を支えるところまで成長したなら、セキュリティ設計も次へ進めなければならない。
これまでは、
「外部の人を、どう安全につなぐか」
を考えてきた。
これからは、それに三つ加える必要がある。
「外から、そのアクセス基盤自体を破られないか。」
「正規の端末や正規の経路を奪われても気づけるか。」
そして、
「その経路を今日止めても、会社は明日動くのか。」
今回のCVE-2026-19490はCitrix担当者だけの問題ではない。
BPO、在宅勤務、フリーランサーを前提に会社を動かしている企業にとって、
ネットワーク。
ID。
端末。
権限。
業務要員。
業務システム。
そしてBCP。
それまで別々に考えていたものを、一度同じ図の上に並べるきっかけになる脆弱性だと思う。
許可したIPから来ている。 正規のCitrix経路を使っている。 IDも存在している。
それだけでは、その向こう側にいるのが本当に正規の業務要員だとは証明できない。
だから監視する対象を、通信から「人」と「業務」まで広げる。
そして、その接続自体を止めざるを得ない日が来ることまで前提にする。
BPOを使う企業に必要なのは、次のCitrixパッチを待つことではない。
外部人材を使うために作ったアクセス設計を、攻撃者にも使われる前提で見直すことではないか。
Aikido Community Japan
公開日: 2026/9/6
最終更新: 2026/9/6
セキュリティの最新情報をお届けします。