Ivanti VPNの脆弱性CVE-2026-111357ほか｜Connect Secureで悪用確認、対象と修正版

Ivantiは2026年10月13日にCVE-2026-104935を公表し、10月29日に、連鎖して悪用されたCVE-2026-111357とCVE-2026-118527の修正版を出しました。3件を連鎖させた悪用を、公表の時点で限られた数の顧客で確認しています。[1]

CVE-2026-111357は単独ではローカルで認証済みの攻撃者が前提ですが、連鎖させると前提が無くなります。Volexityの調査では、連鎖は認証の回避、wu.cgiでのファイルの書き込み、dsinvokedでの権限の昇格の3段で、認証なしでroot権限のコード実行に至りました。[1][4][5]

攻撃者は、機器に保存されたLDAPのドメインの認証情報を抜き出し、Active Directoryの情報、LAPSのローカル管理者のパスワード、BitLockerの回復キーを探していました。[4]

対象はIvanti Connect Secure（ICS）です。CVE-2026-104935は22.7R2.14以前には影響しません。Ivantiは、22.7.Xとそれより前の版にはこの脆弱性が無いとしています。[1]

25.1.3.0（2026年7月公開、ISA4500・ISA6500・ISA8500で動く版）以降にも、この脆弱性は無いとしています。Ivantiは25.1.3.0で一部をすでに直しており、ほかの系列へ移す作業の途中で悪用が起きました。[1]

Ivantiの告知は、設定による条件を挙げていません。[1]

Ivantiは、限られた数の顧客での悪用を確認しています。米CISAは、CVE-2026-104935を2026年10月13日に、CVE-2026-111357とCVE-2026-118527を10月30日にKEVへ追加しました。CISAは、攻撃者がこれらを悪用して認証情報の窃取とデータの持ち出しをしていると述べています。[1][2][3][6]

Volexityは、2026年10月の第1週に、当時の最新版だった22.8R2.4のICSが、未知の攻撃者（UTA0576）に未公表の脆弱性の連鎖で侵害されたのを見つけました。悪用は10月3日から繰り返されていました。機器にWebシェルや裏口は置かれず、コマンドは攻撃の要求のたびに送られていました。[4]

JPCERT/CC・IPAの注意喚起は出ていません（2026-11-02確認）。

ICSはSSL-VPNの装置で、社外からの接続を受けるため、インターネットから届く場所に置かれます。連鎖の最初の段は、ログイン画面を出す公開のCGI（/dana-na/auth/url_default/welcome.cgi）への要求から始まります。[4]

自社のICS（ハードウェアのISA、仮想、クラウド）がどこにあり、どの名前とIPアドレスで外から見えているかを、版と機種を含めて一覧にします。保守を委託している機器も含めます。

米CISAは、侵害を受けたかの判断にはネットワークとメモリのフォレンジックが要るとしています。Ivantiの整合性チェックツール（ICT）は、攻撃者のコマンドがメモリ上で動くため、CVE-2026-104935の悪用を見つけられないことがあります。[3]Volexityの調査でも、攻撃者はメモリ上のライブラリを書き換えて元に戻しており、ICTは何も見つけませんでした。[4]

Ivantiは、Volexityのブログの痕跡を確かめ、ICTを定期的に動かすよう求めています。[1]Volexityが挙げる確認点は次のとおりです。[4]

1. /dana-na/auth/url_default/welcome.cgiへの大量の要求と、X-DSCGI-PATHヘッダーで別のスクリプト（/home/webserver/htdocs/dana/fb/smb/wu.cgiや/home/runtime/tmp/<ファイル名のMD5>）を指すもの。URLとX-DSCGI-PATHの食い違い。
2. /tmp/に残る攻撃後の作業の跡（ml.py・rq5.py・mk.py・rr.py・pu.txt・sp_out.txt・spray_hits.jsonなど）。
3. 隠しディレクトリ/data/.icscap/と、その中のパケットの記録（cap0など）やh.py、tcpdumpの名前を変えたdsstatmondのプロセス。
4. /home/runtime/dlogs/debuglogと/var/log/audit/audit.logで、ある時間帯の記録だけが抜けていないか。
5. ICSから社内へ広がろうとする通信（Active DirectoryへのLDAPの問い合わせ、パスワードスプレー、Kerberosの試行）。
6. Volexityが観測した攻撃元108.165.147[.]64との通信。

侵害が疑われるとき、CISAはIvantiの復旧手順に沿って、次の順で進めるよう勧めています。[3]

1. 機器の設定をバックアップする。
2. 工場出荷時の状態に戻し、最新版に上げる。クラウドと仮想の機器は作り直して最新版に上げる。
3. 1のバックアップから設定を戻す。
4. ドメイン・管理者・ローカルのすべてのアカウントのパスワードを替える。保存された証明書を取り消して出し直し、APIキーとライセンスサーバーの認証情報を替える。

Ivantiの告知では、CVE-2026-111357とCVE-2026-118527は25.1.1.2以前と22.8R2.5以前が対象で、25.1.1.3と22.8R2.6で直ります。CVE-2026-104935は25.1.1.1以前、25.1.2.2以前、22.8R2.4以前が対象で、25.1.1.2、25.1.3.0・25.1.3.1、22.8R2.5で直ります。[1]

CVE-2026-111357のCVEの記録（採番：MITRE）は、影響を受ける版として22.8R2.4だけを挙げており、Ivantiの告知の範囲（25.1.1.2以前・22.8R2.5以前）より狭くなっています。対象かどうかは、提供元のIvantiの告知の範囲で判断します。[5]

25.1.2系について、Ivantiの表はCVE-2026-111357・118527の行を設けていません。米CISAは、3件の対象として25.1.2.2以前も挙げています。[1][3]

Ivantiは、22.8系では25.1.1.3以降への更新を勧めています。すぐに25.1へ移れない場合は、22.8R2.6で今回の全件が直るとしています。25.1.1.1（ISA6000・ISA8000）は25.1.1.3に上げると全件が直ります。[1]

1. 機器ごとに、今の版と機種（ISA6000・ISA8000、ISA4500・ISA6500・ISA8500、仮想・クラウド）を確かめます。
2. 06の表で上げる先を決めます。
3. 修正版は、Ivantiのダウンロード（ILS）から入手できます。[1]
4. 25.1.3.0に移るには、新しい機種（ISA4500・ISA6500・ISA8500）が必要です。ハードウェアは新しい機器を用意し、仮想・クラウドは25.1.3.0のテンプレートで作り直します。手順はIvantiの「Ivanti Connect Secure 25.x Upgrade and Migration Compatibility Guide」にあり、CISAも参照を勧めています。[1][3]
5. 上げた後に版が上げる先になったかを確かめます。

保守の会社に頼むときは、機種と版、上げる先（25.1.1.3、22.8R2.6など）を伝え、上げる前に侵害の調査（05）をするか、侵害が疑われる場合は工場出荷時に戻してから上げる手順で進めるかを決めます。上げた後のパスワードと証明書の入れ替えまでを頼みます。

Ivantiの告知に、回避策の記載はありません。Ivantiは、修正版への更新で直すとしています。[1]

Ivantiは、22.7と22.8のサポートが2027年1月31日に終わるとしています。22.8は22.7から25.1へ移るまでの一時的な橋渡しの系列で、25.1には重要なセキュリティの機能があるとして、期日までに25.1への移行を終えるよう求めています。米CISAも、22.8のサポートの終了日を示しています。[1][3]

25.1.3.0以降は新しい機種が要るため、ハードウェアで使っている場合は、機器の入れ替えの時期と予算を早めに決めます。[1]