Ivanti Connect Secure 脆弱性 3 件｜更新判断と侵害調査

はじめに

2026 年 10 月 13 日、Ivanti は Ivanti Connect Secure（以下、ICS）の脆弱性 CVE-2026-104935 を公表し、同日に CISA が KEV（Known Exploited Vulnerabilities）カタログへ追加しました。Volexity は、脅威アクター UTA0576 がこの脆弱性を含む 3 件のゼロデイを連鎖させ、当時最新の 22.8R2.4 で稼働していた ICS で、認証なしに root 権限のコマンド実行へ至った事例を報告しています。

ただし、10 月 13 日に提供された修正版（22.8R2.5、25.1.1.2 など）が対処したのは CVE-2026-104935 のみです。root 権限への昇格に使われた CVE-2026-111357 と、CVE-2026-118527 の修正は 10 月 29 日に 22.8R2.6 / 25.1.1.3 として追加され、CISA は 10 月 30 日にこの 2 件を KEV へ追加しました。さらに攻撃者は、VPN 装置に保存された LDAP 用の資格情報を使って Active Directory（以下、AD）から LAPS パスワードや BitLocker 回復情報を探索していました。本記事は 2026 年 11 月 2 日時点の公開情報に基づいています。

結論として、22.8R2.5 / 25.1.1.2 へ更新済みでも、3 件すべての修正は含まれていません。22.8R2.x 系列は 22.8R2.6、25.1.1.x 系列は 25.1.1.3 が 3 件の修正を含む版で、ISA6500 / ISA8500 などで使われる 25.1.2 以降の系列は Ivanti の最新アドバイザリで更新先を確認します。あわせて、更新は今後の悪用を防ぐ対策であり、10 月上旬以降に対象版を外部公開していた装置では、Integrity Checker の結果にかかわらず VPN 装置と AD の両方で侵害調査を行うことを推奨します。

Ivanti Connect Secure の脆弱性 3 件と攻撃チェーン

3 件は深刻度も成立条件も異なり、単独で認証不要のコマンド実行が成立するのは CVE-2026-104935 だけです。Ivanti は、3 件を連鎖させた悪用を一部の顧客環境で確認したとしています。

CVE ごとの役割と単独での成立条件

CVE	種類	単独での攻撃条件	CVSS v3.1（Ivanti）	KEV 追加日
CVE-2026-104935	なりすましによる認証回避（CWE-290）。認証なしで任意のコマンド実行に至る	リモート、認証不要	8.6	2026 年 10 月 13 日
CVE-2026-111357	重要な機能に対する認証の欠如。権限昇格	ローカル、認証済み	8.8（CVE レコードでは 7.0）	2026 年 10 月 30 日
CVE-2026-118527	予測可能な数値・識別子の生成。攻撃者が用意した内容のファイルを、ディスク上の既知の場所へアップロードできる	リモート、認証済み	4.3	2026 年 10 月 30 日

脆弱性の名称と KEV 追加日は CISA、攻撃条件は CISA の KEV 登録時の説明に基づきます。CVE-2026-111357 と CVE-2026-118527 は単独では認証を前提とするため、CVSS だけを見ると優先度が下がって見えます。しかし、CVE-2026-104935 と連鎖させると認証の前提が外れ、実際に悪用されて KEV に登録されています。優先度は CVSS ではなく、悪用実績と連鎖したときの影響で判断することを推奨します。

認証回避から root 権限取得まで（Volexity の観測）

Volexity が 22.8R2.4（Build 19097）の ICS で再構成した攻撃の流れは、次の 3 段階です。

1. 認証回避: 公開されたログインページ /dana-na/auth/url_default/welcome.cgi へのリクエストで、X-DSCGI-PATH ヘッダーに別の CGI を指定します。許可判定には URL が、転送先にはヘッダーが使われる不整合により、認証が必要な CGI へ到達します。
2. コード実行: wu.cgi のアップロード処理がファイルを書き込んでから削除するまでの短い間に、同じ手法でそのファイルを実行させ、cgi-server ユーザーの権限でコードを実行します。
3. root 権限への昇格: root で動作する dsinvoked が、共有設定ストアの DSCache を信頼する点を悪用します。メモリ上で設定を書き換えて root でスクリプトを実行させ、実行後に設定とライブラリを元の状態へ戻します。

Volexity は 1 と 2 を CVE-2026-104935 として扱い、3 の権限昇格については 10 月 29 日の追記で CVE-2026-111357 として修正されたと説明しています。なお、Volexity の本文は 10 月 13 日時点の内容のまま更新されておらず、本文中の「権限昇格は未修正」「更新対象のバージョン」といった記述は追記前の情報です。

攻撃者は Web シェルやバックドアを設置せず、コマンドを 1 つ実行するたびにこのチェーン全体を再実行し、結果を HTTP 応答で受け取っていました。装置のディスク上に残る変更が少ないことが、後述する検出の難しさにつながっています。

CVE-2026-118527 について確認できない範囲

CVE-2026-118527 は、CISA の説明から「認証済みの攻撃者が、攻撃者の用意した内容のファイルをディスク上の既知の場所へアップロードできる」という概要までが確認できます。Volexity の解析では、wu.cgi がファイル名の MD5 値から決まる場所へファイルを書き込むため、書き込み先が予測できる点が攻撃の前提になっていました。第三者の解説の中には、この点を CVE-2026-118527 に対応付けるものもあります。

ただし、Volexity の本文と追記は CVE-2026-118527 に言及しておらず、本記事の執筆時点では Ivanti のアドバイザリ本文を直接確認できていません。そのため、Volexity が説明した各段階と CVE-2026-118527 の厳密な対応関係は未確認として扱います。実務上の対応判断は変わらず、CVE-2026-118527 の修正は CVE-2026-111357 と同じ 22.8R2.6 / 25.1.1.3 に含まれています。

報告された侵害後の行動と AD への影響

Volexity によると、UTA0576 の活動の中心は VPN 装置そのものではなく、装置を足場にした資格情報の窃取と AD の偵察でした。確認された主な行動は次のとおりです。

• ICS に保存されていた、LDAP 連携用のドメイン資格情報の抽出
• ICS の AD サービスアカウントでドメインコントローラーへ LDAP 認証し、LAPS パスワード、BitLocker 回復情報、userPassword / unixUserPassword 属性を検索
• 限定的な AD メタデータの取得と外部への送信
• Kerberoast 機能を持つ独自の Kerberos ツールの配置と、資格情報の有効性確認（Kerberoast 機能自体の使用は確認されていません）
• AD アカウントに対するパスワードスプレー
• 装置上のパケットキャプチャから TCP 389 の LDAP 通信を抽出し、平文で送られた LDAP の資格情報や NTLM のチャレンジレスポンスを収集しようとする動き
• ICS の設定と認証ログの収集（認証方式や有効なユーザー名の把握）

Volexity は、これらの行動を横展開とより広い侵害の準備と高い確度で評価しています。一方、活動は検知・遮断されたため、最終的な目的は判明していません。VPN 装置の侵害は、装置の再構築だけで完結する問題ではなく、AD のサービスアカウント、LAPS、BitLocker 回復情報まで影響範囲に含めて考える必要があります。

影響バージョンと修正版｜22.8R2.5 / 25.1.1.2 で終わらない理由

修正は 2 回に分けて提供されたため、「10 月中に更新した」という記録だけでは対応状況を判断できません。稼働中の系列とビルド番号まで含めたバージョンで照合します。

10 月 13 日と 10 月 29 日の修正の時系列

日付	出来事
2026 年 7 月	25.1.3.0 を公開。Ivanti は、CVE-2026-104935 の一部を自社で発見し、このリリースで修正したと説明しています
2026 年 10 月 3 日	UTA0576 による 22.8R2.4 の侵害が始まる（Volexity の観測）
2026 年 10 月 13 日	Ivanti が CVE-2026-104935 を公表し、22.8R2.5 / 25.1.1.2 / 25.1.3.0・25.1.3.1 を修正版として案内。CISA が KEV に追加
2026 年 10 月 29 日	Ivanti がアドバイザリを更新し、CVE-2026-111357 / CVE-2026-118527 を追加。22.8R2.6 / 25.1.1.3 で修正
2026 年 10 月 30 日	CISA が 2 件を KEV に追加し、アラートの影響バージョンを 25.1.1.2 以前、25.1.2.2 以前、22.8R2.5 以前に更新（3 件をまとめた記載）
2027 年 1 月 31 日	ICS 22.8 の EOL（CISA のアラートと Ivanti の案内による）

系列・機種別の影響と更新先

ICS は系列（コードライン）ごとに対応するハードウェアと修正版が異なります。次の表は、CVE ごとの修正版を系列別に整理したものです。修正版の番号は同じ系列の中でのみ比較し、ほかの系列の番号と大小を比べないでください。

系列	主な稼働環境	CVE-2026-104935 の修正版	CVE-2026-111357 / 118527 の修正版
22.8R2.x	ISA6000 / ISA8000、仮想アプライアンス	22.8R2.5（22.8R2.4 以前が対象）	22.8R2.6（22.8R2.5 以前が対象）
25.1.1.x	ISA6000 / ISA8000、ISA-V（VMware、Azure、Hyper-V、OpenStack KVM）	25.1.1.2（25.1.1.1 以前が対象）	25.1.1.3（25.1.1.2 以前が対象）
25.1.2.x / 25.1.3.x	ISA6500 / ISA8500 など	25.1.3.0 / 25.1.3.1（25.1.2.2 以前が対象）	本記事では確認できず（後述）
22.7R2.x	22.7R2.14 以前	対象外（Ivanti の CVE レコードによる）	本記事では確認できず

修正版は報道で引用された Ivanti のアドバイザリと、Ivanti のリリースノート（22.8R2.6、25.1.1.3）で照合しています。稼働環境はリリースノートの対応プラットフォームに基づきます。

ISA6500 / ISA8500 などで使われる 25.1.2.x / 25.1.3.x 系列は、CVE-2026-111357 / 118527 の扱いを公開情報だけでは確定できません。CISA のアラートは 3 件をまとめた影響バージョンに「25.1.2.2 以前」を含めていますが、CVE ごとの内訳は示していません。カナダ サイバーセキュリティセンター（CCCS）も、CVE を区別せずに「25.1.3.1 より前」を影響対象としています。いずれも、各 CVE の個別の影響範囲と同じ意味とは限りません。一方、25.1.3.1 と 25.1.4.0 のリリースノートは 10 月 29 日より前の更新で、今回の 2 件の修正を含むかは記載から読み取れません。この系列の装置は、Ivanti の最新アドバイザリまたはサポートで、2 件の修正を含む版を確認してから更新先を決めることを推奨します。

22.7R2.x 系列は CVE-2026-104935 の対象外とされていますが、残る 2 件の扱いは本記事では確認できていません。22.x 系列は 2027 年 1 月 31 日に EOL を迎えるため、Ivanti は 25.x への移行を推奨しています。

22.8R2.4 / 25.1.1.1 からの段階的な更新経路

Ivanti のリリースノートは、稼働中の装置へ直接適用する更新と、設定を移す移行を分けて記載しています。

Upgrade Installation

稼働中の装置に新しいソフトウェアを適用する更新です。更新元のバージョンと、対応プラットフォームの両方が条件になります。

Configuration Migration

旧バージョンの設定を、新しいバージョンで用意した装置へ移す方法です。移行元として検証されたバージョンが別に定められています。

更新先	Upgrade Installation の更新元	Configuration Migration の移行元
22.8R2.6（Build 19359）	22.8R2.5（仮想・ハードウェア）、22.7R2.14（ハードウェアのみ）	22.8R2.5、22.7R2.14
25.1.1.3（Build 26869）	25.1.1.2、22.8R2.5 / 22.8R2.6（ISA6000 / ISA8000 と VMware のみ）	25.1.1.2、22.8R2.6、22.8R2.5、22.7R2.14（ハードウェア・仮想とも）

出典は Ivanti のリリースノート（22.8R2.6 の Upgrade and Migration、25.1.1.3 の Upgrade and Migration）です。この表には、Volexity の事例と同じ 22.8R2.4 から 22.8R2.6 / 25.1.1.3 へ直接更新する経路は記載されていません。リリースノートの対応表で確認できる段階的な経路の例は次のとおりです。

• 22.8R2.4 → 22.8R2.5 → 22.8R2.6（ISA6000 / ISA8000、VMware）
• 25.1.1.1 → 25.1.1.2 → 25.1.1.3（ISA6000 / ISA8000）

これより古いバージョンや、上記以外のプラットフォームで稼働している場合は、更新先ごとのリリースノートにある対応表で、Upgrade Installation と Configuration Migration の経路を個別に確認してください。経由する版ごとに対応する更新元とプラットフォームが異なるため、上記の例をそのまま当てはめないことを推奨します。

提供形態にも注意が必要です。22.8R2.6 の Upgrade Installation は ISA6000 / ISA8000 / VMware に限られます。25.1.1.3 は Azure、Hyper-V、OpenStack KVM の仮想アプライアンスにも対応していますが、Upgrade Installation の対象として明記されているのは ISA6000 / ISA8000（22.8R2.x からの更新では VMware も）です。これらのクラウド・仮想環境で既存インスタンスを直接更新できるかはリリースノートから読み取れないため、新規展開と設定移行が必要になる可能性を含めて Ivanti に確認することをおすすめします。また、Ivanti は装置の外部インターフェースから更新作業を開始しないよう案内しています。

HA / クラスター構成の更新経路

クラスター構成では、22.8Rx から 25.x へ系列をまたぐ更新に制約があります。

参考: Ivanti Connect Secure Release Notes 25.1.1.3（Upgrade and Migration）
“cluster upgrade is not supported from 22.8Rx to 25.x”
（22.8Rx から 25.x へのクラスターアップグレードはサポートされていません）
https://docs.ivanti.com/ps/help/en_us/ics/25_1_1_3/rn/upgrade-and-migration

Ivanti の『Cluster Migration from 22.8Rx to 25.x』では、各ノードをクラスターから外すか無効化して個別に更新する前提で、次の 2 つの方式が示されています。Active / Passive と Active / Active のどちらも対象で、ISA ハードウェアと ISA-V の両方に適用されます。

クラスターを削除して再作成する方式

クラスターを削除し、各ノードをプラットフォームごとの標準手順で 25.x へ更新してから、クラスターを再作成します。

ノードを 1 台ずつ無効化して更新する方式

ノードを無効化して更新し、残りのノードも同様に更新した後で各ノードを有効化します。ガイドでは、最初のノードを更新する間は両ノードがオフラインになり、サービスが停止すると説明されています。

どちらの方式でも、ガイドは計画的な停止時間が必要としています。22.8R2.x のクラスターを 25.1.1.3 へ移す場合は、事前のバックアップ、停止時間の確保、関係者への周知、更新後のクラスター動作とフェイルオーバーの確認までを作業計画に含めてください。具体的な操作は、ガイドと稼働中のプラットフォームの手順に従います。

急ぎの対処として同じ系列内の 22.8R2.6 を選ぶ判断もありますが、22.8 は 2027 年 1 月 31 日に EOL を迎えます。その場合でも、25.x への移行計画をあわせて立てておくことを推奨します。22.8R2.x 系列内でのクラスター更新手順は今回のリリースノートに記載がないため、本記事では手順を扱いません。

自社の Ivanti Connect Secure の影響確認手順

影響確認は、装置の洗い出しから侵害調査の要否判断までを順番に進めます。管理画面の具体的な操作はバージョンによって異なるため、稼働中のバージョンに対応する Ivanti の管理者ガイドを参照してください。

VPN 装置と AD の侵害兆候を確認する

今回の攻撃は、単一の痕跡だけで侵害を判断できません。時刻、送信元、通信内容、AD 側のイベントを組み合わせて評価します。

welcome.cgi と X-DSCGI-PATH の通信を確認する

Volexity は、/dana-na/auth/url_default/welcome.cgi への大量のリクエストを監視するよう推奨しています。悪意のあるリクエストでは、X-DSCGI-PATH: /home/webserver/htdocs/dana/fb/smb/wu.cgi や、/home/runtime/tmp/ 配下のファイルを指す X-DSCGI-PATH ヘッダーが使われていました。Volexity は別のパスが悪用される可能性も指摘しており、URL のパスと X-DSCGI-PATH の値が一致しないリクエストを監視するよう勧めています。

welcome.cgi はログインページを提供するため、アクセス数だけでは判断できません。次の点を組み合わせて確認します。

• 同一の送信元から、短時間に並列・反復して送られたリクエスト（コード実行の段階では、削除前のファイルを狙って複数のリクエストが送られます）
• X-DSCGI-PATH ヘッダーの有無と、URL との不一致
• 2026 年 10 月上旬以降の時期と、通常のユーザーとは異なる送信元
• Volexity が公開した IoC との一致

IP アドレスなどの IoC は本記事に転載せず、最新版を Volexity の GitHub で確認してください。また、HTTPS 通信は通常 ICS で復号されるため、HTTP ヘッダーまで記録できるのは、TLS を終端・復号している前段の WAF やリバースプロキシなどに限られる場合があります。ICS 自体のログは後述のとおり改ざんされた可能性があるため、外部の SIEM やログサーバーへ転送済みの記録を優先して確認することを推奨します。

AD / LDAP 側で確認する項目

攻撃者の目的が AD の資格情報と秘密情報にあったため、VPN 装置の調査だけでは影響範囲を判断できません。AD 側では次の観点を確認します。

ICS のサービスアカウントの利用状況

ICS 以外の送信元からの利用、通常と異なる時間帯の利用、VPN 認証では行わない広範囲の検索がないかを確認します。

LAPS パスワードと BitLocker 回復情報の参照

属性の読み取りは、事前に監査を設定していなければ記録されないことがあります。まず監査設定の状況と、ICS のサービスアカウントにこれらの属性を読む権限があったかを確認します。権限があり記録がない場合は、参照された可能性を前提に対応を検討します。

認証試行とパスワードスプレー

多数のアカウントに対する少数のパスワードでの認証失敗、ICS を起点とした Kerberos や LDAP の認証試行、その中で成功したアカウントを確認します。

ICS からドメインコントローラーへの通信

ファイアウォールやフローの記録で、ICS からドメインコントローラーへの LDAP、Kerberos、DNS の通信量や時間帯の変化を確認します。Volexity の事例では、内部ドメインの名前解決も行われていました。

AD の権限や設定の変更

Volexity の事例では観測されていませんが、横展開の準備段階と評価されているため、特権グループや権限設定に想定外の変更がないかもあわせて確認することを推奨します。

Volexity は、装置上のキャプチャから TCP 389 の LDAP 通信を抽出し、平文の資格情報を収集しようとする動きも報告しています。ただし、TCP 389 でも StartTLS や SASL の暗号化（sealing）で通信が保護されている場合があり、ポート番号だけで露出の有無は判断できません。Microsoft は、TCP 389 で保護なしのシンプルバインドを使う場合、資格情報が平文で送られると説明しています（Microsoft Learn: LDAP channel binding）。ICS と AD の間で平文のシンプルバインドを使っていた場合は、その通信に含まれていたバインド用の資格情報も露出した可能性を考慮してください。

ログ改ざんと Integrity Checker の検出限界

Volexity によると、攻撃者は ICS のデバッグログ（/home/runtime/dlogs/debuglog）と Linux の監査ログ（/var/log/audit/audit.log）から、攻撃に関係する期間の記録を選んで削除していました。さらに、権限昇格ではライブラリをメモリ上でのみ書き換え、実行後に設定ストアとあわせて元の状態へ戻していました。

参考: Volexity「A Series of Unauthenticated Events: Chained Exploitation of Ivanti Connect Secure Zero-Days」
“The Ivanti Integrity Checker may not be able to identify device compromise.”
（Ivanti Integrity Checker では、装置の侵害を特定できない可能性があります）
https://www.volexity.com/blog/2026/10/13/a-series-of-unauthenticated-events-chained-exploitation-of-ivanti-connect-secure-zero-days/

CISA も、攻撃者のコマンドがメモリ上で実行されるため、Integrity Checker Tool（ICT）が悪用の痕跡を検出できない可能性があると注意喚起しています。ICT はディスク上の想定外のファイル変更を検出するツールであり、ディスクを改変する攻撃に対しては引き続き有効な確認手段です。今回の手法はディスク上の変更を残さないため、その検出範囲から外れています。

したがって、ICT の正常判定や、ログ上で痕跡が見つからないことだけでは、侵害を否定できません。Volexity と CISA は、侵害の有無を判断するためにネットワークとメモリのフォレンジックが必要としています。Volexity は /tmp/ の確認も挙げていますが、通常の管理画面から装置内部のファイルを直接参照する手段は本記事では確認できていないため、Ivanti のサポートやフォレンジック事業者と連携して進めることを推奨します。検査で陰性でも侵害を否定できない考え方は、『FortiGate の侵害痕跡を確認する手順｜symlink 検査ツールの使い方』でも整理しています。

侵害が疑われる場合の対応と更新後の確認

修正版の適用は脆弱性をふさぐ作業であり、すでに起きた侵害からの復旧とは別の作業です。侵害が疑われる場合は、証拠の保全と封じ込めを先に行います。

初動の優先順位と証拠保全

Ivanti の復旧手順に沿った再構築

CISA は、侵害が疑われる場合に Ivanti の Recovery Procedures に沿った対応を求めています。CISA が挙げている主な内容は、装置設定のバックアップ、工場出荷状態への初期化と最新版への更新、ドメイン・管理者・ローカルを含む全アカウントのパスワード再設定、装置に保存された証明書の失効と再発行、API キーとライセンスサーバーの資格情報の再設定です。

参考: CISA「CISA Urges Patching Newly Exploited Vulnerabilities in Ivanti Connect Secure」
“Conduct a factory reset and upgrade the appliance to the latest version.”
（工場出荷状態への初期化を行い、装置を最新版へ更新してください）
https://www.cisa.gov/news-events/alerts/2026/10/13/cisa-urges-patching-newly-exploited-vulnerability-ivanti-connect-secure

仮想アプライアンスやクラウド環境での再構築方法は、Ivanti の最新の Recovery Procedures で確認してください。初期化後のバージョンから修正版へ進む際にも、前のセクションで整理した段階的な更新経路が必要になる場合があります。

資格情報を変更する順序

攻撃者は ICS に保存された資格情報を抽出していました。侵害の可能性がある装置に新しい資格情報を設定すると、装置から再び取得されるおそれがあります。一方で、漏えいした可能性がある資格情報を再構築の完了まで使い続けると、AD への不正アクセスが続くおそれもあります。装置の封じ込めと、漏えいした可能性がある資格情報の速やかな無効化・変更を、状況に応じて組み合わせることを推奨します。

1. ICS の外部公開や内部ネットワークへの通信を制限し、攻撃者が装置を再利用しにくい状態にします。
2. LDAP バインド用のサービスアカウントなど、漏えいした可能性がある資格情報は、再構築の完了を待たずに AD 側で無効化またはパスワード変更を検討します。ICS の AD 認証が止まるため、業務影響と代替手段を踏まえて時期を決めます。変更後の値は、侵害の疑いが残る装置には設定しません。
3. 修正版で再構築した装置に、新しいサービスアカウントの資格情報を設定します。あわせて、VPN 認証に不要な属性を読める権限がないかを見直します。
4. 装置の管理者とローカルアカウント、保存されていた証明書、API キー、ライセンスサーバーの資格情報を再設定します。
5. 参照された可能性がある端末の LAPS パスワードと BitLocker 回復情報を更新します。
6. パスワードスプレーで成功した可能性のあるアカウントや、平文の通信で露出した可能性のある資格情報を再設定します。CISA はドメインを含む全アカウントのパスワード再設定を挙げているため、範囲は調査結果を踏まえて判断します。

LAPS と BitLocker 回復情報の更新方法は、管理方式によって異なります。LAPS は Windows LAPS か従来の Microsoft LAPS か、パスワードの保存先が AD か Microsoft Entra ID かによって手順が変わります。BitLocker 回復情報は、新しい回復情報を生成したら、AD DS や Intune などの管理基盤に保存されたことを確認してから、旧情報の無効化や削除を進めてください。確認前に旧情報を削除すると、保存に失敗した場合に回復手段を失うおそれがあります。具体的な操作は、利用している管理方式の公式手順に従います。

修正後の確認と監視の継続

更新や再構築の後は、クラスターの全ノードと待機系を含めて、稼働中のバージョンとビルドが更新先と一致していることを確認し、台帳に記録します。あわせて VPN 認証と主要な業務通信を確認します。

監視では、変更前のサービスアカウントの資格情報を使った認証試行に注意します。無効化した資格情報が使われていれば、窃取された資格情報が使われている兆候として扱えます。ICS と AD の間で保護のない LDAP 通信を使っていた場合は、LDAPS や StartTLS など、通信を暗号化する方式への切り替えを、ICS が対応する方式の中から検討することをおすすめします。SSL-VPN 装置で修正と侵害調査を分けて扱った例として、『SonicWall SMA1000 のゼロデイ2件｜対処と侵害調査の手順』も参考にしてください。

まとめ

Ivanti Connect Secure の今回の脆弱性は、10 月 13 日と 10 月 29 日の 2 回に分けて修正されました。22.8R2.5 / 25.1.1.2 では 3 件の修正がそろわないため、系列と機種に合った修正版への更新が必要です。あわせて、VPN 装置と AD の両方で侵害の有無を確認することが対応の要点です。

• 単独で認証不要の攻撃が成立するのは CVE-2026-104935 のみ
• 10 月 13 日の修正版は CVE-2026-104935 だけに対応している。
• 22.8R2.x は 22.8R2.6、25.1.1.x は 25.1.1.3 が 3 件の修正を含む。
• 22.8R2.4 などからは対応表に沿った段階的な更新が必要になる。
• 25.1.2 以降の系列は最新のアドバイザリで更新先を確認する。
• Integrity Checker の正常判定だけでは侵害を否定できない。
• サービスアカウント、LAPS、BitLocker 回復情報も調査対象とする。

以上、最後までお読みいただきありがとうございました。