Zscaler Client Connectorに脆弱性5件、未認証RCEも

ゼロトラスト製品「Zscaler Client Connector」に、深刻度クリティカルを含む脆弱性5件が公表されました。最も深刻なものは認証不要のリモートコード実行(CVE-2026-59568、CVSS 9.1)です。ただし修正版はすでに配布済みで、Windows版の修正ブランチのひとつ「4.8.0.232」は2026年6月1日にリリースされています。

つまり情シスがいま取るべき行動は「緊急パッチの適用」ではなく、「全社の端末が本当に修正済みバージョンで動いているかの棚卸し」です。エージェントは自動更新される前提で運用されがちですが、更新が止まっている端末は静かに残ります。

この記事でわかること

  • Zscaler Client Connectorとは何をするもので、どの端末に入っているのか
  • 公表された脆弱性5件の内容と深刻度(CVE番号・CVSS)
  • OS別の「影響を受けるバージョン」と、branch(系統)ごとに修正版が違うという落とし穴
  • すでに修正済みの脆弱性で、情シスが今なお確認すべきこと

Zscaler Client Connectorとは何か

Zscaler Client Connector(ZCC)とは、利用者の端末に常駐し、通信をZscalerのクラウド(Zero Trust Exchange)へ転送する軽量エージェントです。インターネット通信の検査(ZIA)、社内アプリへのゼロトラストアクセス(ZPA)、端末の体感品質の可視化(ZDX)を1本で担い、対応OSはWindows / macOS / Linux / ChromeOS / iOS / Androidに及びます。

ここで注意したいのが、「うちはZscalerを使っていない」と即断できないケースがあることです。ZCCは次のような形で入り込んでいることがあります。

  • VPNの置き換え(ZTNA導入)としてネットワーク部門が主導し、全社端末にMDM/Intune経由で一括配布された。セキュリティ担当が資産台帳ベースで把握していないことがある。
  • SASE/SSE基盤の一部として導入された。契約上の主役はクラウド側のサービスで、端末エージェントは「付属物」として意識されにくい。
  • 常時起動の常駐サービスとして動いている。Windowsでは ZSAService.exe(サービス本体)と ZSATray.exe(タスクトレイのGUI)が該当します。前者は特権コンテキストで動作するため、権限昇格の脆弱性が刺さると影響が大きくなります。

関連する基礎知識は ZTNAとは?VPNとの違い・仕組みを情シス向けに解説SASEとは?構成要素とSSEとの違いを解説 にまとめています。

何が起きたのか:脆弱性5件の内容

2026年8月24日(現地時間)、Zscaler Client Connectorに関する5件のCVEがNVDに公開されました。深刻度はいずれもベンダー(Zscaler, Inc.)が算出したCVSS v3.1のベーススコアです。

CVE 内容 CVSS v3.1 主な攻撃元
CVE-2026-59568 未認証・非特権のユーザーがZCCのコンテキストで任意コードを実行できるリモートコード実行 9.1(Critical) ネットワーク(AV:N / PR:N / UI:N)
CVE-2026-59564 ZCCとZCCポータル間の通信における認証バイパス 9.1(Critical) ネットワーク(AV:N / PR:N / UI:N)
CVE-2026-59567 非特権ユーザーが特権コンテキストで任意コードを実行できるローカル権限昇格 8.8(High) ローカル(AV:L / PR:L / S:C)
CVE-2026-59565 リモートから悪用可能なバッファオーバーフロー(Windows版)。ローカルおよびカーネルレベルのサービス拒否を引き起こしうる 8.8(High) ネットワーク(AV:N / PR:L)
CVE-2026-59566 ローカルで悪用可能なバッファオーバーフロー(Android / ChromeOS版)によるサービス拒否 8.4(High) ローカル(AV:L / PR:N)

特に重いのは上位2件です。CVE-2026-59568は認証も利用者操作も不要で、ネットワーク経由で成立します。CVE-2026-59564は端末エージェントと管理ポータルの間の認証を回避するもので、「管理側との通信を信頼する」という設計の前提そのものを崩しかねない位置にあります。

なお、これらが実際に悪用されたという報告は、本記事執筆時点(2026年8月25日)では確認できていません。CISAのKEV(悪用が確認された脆弱性カタログ)への登録も確認できていません。今後の情報更新には注意が必要です。

影響を受けるバージョン:ブランチごとに修正版が違う

ここが実務上いちばん間違えやすいところです。修正は系統(ブランチ)ごとに別々のバージョンで提供されているため、「バージョン番号が大きければ安全」とは限りません。NVDに記載された影響範囲は次のとおりです。

OS 影響を受けるバージョン(=これ未満は対象)
Windows 4.6.0.457 / 4.7.0.317 / 4.8.0.232 / 4.9.0.372 の各未満
macOS 4.5.2.312 / 4.7.0.292 / 4.8.0.191 の各未満
Linux 3.7.2.64 / 4.2.1.64 の各未満
iOS 4.5.1 未満
Android / ChromeOS 4.2 未満

たとえばWindowsで「4.9系だから最新のはず」と考えても、4.9.0.372より前であれば対象です。逆に4.8系でも4.8.0.232以上なら修正済みです。棚卸しの際は「メジャー番号」ではなく4桁目まで含めた完全なバージョン文字列で突き合わせてください。

すでに修正済みなのに、なぜ確認が必要なのか?

修正版のリリースとCVEの公表に、数か月のずれがあるからです。Windows版の4.8.0.232は2026年6月1日にリリースされており、CVEの公開は8月24日です。この間に更新が回っていた組織は実質的に対応済みですが、更新が止まっていた端末は「知らないまま3か月弱、脆弱な状態で動き続けていた」ことになります。

更新が止まる理由は現場にいくらでもあります。長期休暇で電源を切っていた端末、社内ネットワークに戻ってこない持ち出し端末、検証のため意図的に旧バージョンで固定した端末、退職者の未回収端末——いずれも「自動更新だから大丈夫」の外側にいます。

想定されるリスク

  • エンドポイントの完全な掌握:CVE-2026-59568が成立すればZCCのコンテキストで任意コードが実行され、CVE-2026-59567の権限昇格と組み合わされれば特権奪取に至りうる。
  • セキュリティ機能そのものの停止:DoS系(CVE-2026-59565 / 59566)が悪用されると、通信を検査するエージェントが落ちる。「守りの要が真っ先に無効化される」形になる。
  • 信頼関係の悪用:認証バイパス(CVE-2026-59564)は端末と管理ポータルの通信に関わる。ゼロトラストを支えるコンポーネント自体が信頼の抜け道になりうる点で、影響の質が通常のアプリ脆弱性とは異なる。

現場目線の課題

率直に言って、この手の「エージェント自身の脆弱性」はいちばん気の重いテーマです。エンドポイントを守るために全端末へ配ったソフトが、そのまま全端末に共通する攻撃面になるからです。しかも配布規模が大きいほど、旧バージョンが残るリスクも上がるという構造になっています。

加えて厄介なのが、ZTNA/SASEのエージェントはセキュリティ部門ではなくネットワーク部門やインフラ部門が管理していることが多い点です。「あれはネットワーク側の管轄なので」と互いに思っている間に、バージョン管理が誰の責任でもなくなる。脆弱性情報が流れてきて初めて「そもそも今どのバージョンが何台動いているのか」を誰も即答できない、という場面は珍しくありません。

情シスはどうすべきか

今回のケースで具体的にやることは、多くありません。

  1. バージョンの実態を数える:MDM/資産管理ツールのインストール済みソフトウェア一覧、またはZscaler Client Connectorポータルの端末一覧から、OS別・バージョン別の台数を出す。上表の閾値未満の端末を洗い出す。
  2. 更新が届いていない端末を特定する:一定期間チェックインしていない端末は、バージョン以前に管理から外れている可能性がある。台帳と突き合わせる。
  3. 意図的に固定しているバージョンがないか確認する:検証や互換性の都合で旧バージョンに留めている運用があれば、閾値を満たしているか個別に判定する。
  4. 今後の情報を追う:現時点で悪用報告はないが、Critical 2件を含むため、KEV登録やPoC公開の有無は継続確認する。

脆弱性が出たときに回すプロセスの型は 脆弱性管理とは?プロセスと情シスの進め方を解説 に、組織全体の底上げはIPAの中小企業の情報セキュリティ対策ガイドラインにまとまっています。更新の徹底は利用者の協力なしには成立しないため、IPA「対策のしおり」のような啓発資料を併用し、「更新を先延ばしにしない」文化を地道に育てることも有効です。

中長期の視点:エージェントを資産として管理する

ゼロトラストへ移行するほど、認証・通信制御・可視化は端末側エージェントに集約されます。その裏返しとして、エージェントは「守ってくれるもの」であると同時に「守るべき対象」でもあるという前提を運用に組み込む必要があります。ZTNAクライアント、EDR、資産管理エージェントについても、業務アプリと同様に「導入バージョンの一覧が常に出せる状態」を保つ。バージョン分布が見えていれば、今回のような公表があった日に判断まで数分で済みます。考え方の整理は ゼロトラストとは?境界防御との違いと導入の勘所 を参照してください。

まとめ

  1. Zscaler Client Connectorに脆弱性5件が公表された。最も深刻なのは未認証リモートコード実行(CVE-2026-59568)と認証バイパス(CVE-2026-59564)で、いずれもCVSS 9.1のCritical。
  2. 修正版はすでに配布済み(Windows 4.8.0.232は2026年6月1日リリース)。緊急パッチ適用ではなく、全端末が閾値以上のバージョンで動いているかの棚卸しが本題。
  3. 修正はブランチごとに別バージョンで提供されるため、「番号が大きい=安全」ではない。4桁目まで含めた完全なバージョン文字列で判定する。

出典

タイトルとURLをコピーしました