Ivanti Connect Secureに追加修正：10月13日に更新したVPNも、版と侵害の再確認を

在宅勤務や拠点間の業務をつなぐVPN装置は、社内ネットワークの入口です。今回の対象はIvanti Connect Secure（ICS）。名前の似た別製品や、利用者のPC上のVPNクライアントの更新だけで同じ対処になるわけではありません。Ivantiの公式告知は、3件の脆弱性を組み合わせた悪用を、一部顧客で確認したと説明しています。被害企業名や件数は公表されていません。

新しい動きは、10月29日の追加修正と、翌30日のCISA KEVへの2件追加です。この記事は11月1日朝JSTの確認に基づきます。最初の公表を今日の新発見とせず、「10月13日に更新した装置にも追加確認が必要」という差分を整理します。実機の攻撃再現や本番設定変更は行っていません。

10月13日の更新が無意味だった、ということではありません。Ivantiは、CVE-2026-104935を修正して主要な侵入経路を塞ぐ更新を、後から判明した権限昇格の修正を待たずに提供したと説明しています。追加2件が残っていることと、13日の修正版に同じ認証不要の攻撃連鎖がそのまま通ることは別です。その区別を保ったうえで、残る問題への追加修正を進めます。

Ivantiの告知は作成日10月13日、最終更新日10月29日を表示しています。KEVの取得版は2026.10.30、フィード公開時刻は10月30日17:02:45 UTCです。KEV登録日は日付のみであり、修正版の公開時刻や攻撃を受けた時刻とは一致しません。

平たくいうと、入口の確認をすり抜ける問題、ファイルの置き場所を攻撃側が予測できる問題、装置内で強い権限へ進める問題がつながります。rootは装置の管理に使われる強い権限です。「ローカル攻撃」「認証済み」と書かれた1件だけを見て、外部公開VPNでは関係ないと判断すると、前段の侵入との組み合わせを見落とします。一方で、追加2件がそれぞれ単独で認証不要の遠隔実行を起こす、と書くのも正確ではありません。

Mediumの4.3だから後回し、という判断も適切ではありません。CVSSは技術的な深刻度を一定の条件で示す指標で、すでに悪用されているか、自社の入口に置かれているか、他の問題と連鎖するかは別に判断します。KEVへの登録は、単なる可能性の説明より対応優先度を上げる根拠になります。

評価元にも差があります。MITREのCVE-2026-111357記録は、確認時点でCVSS 3.1の7.0を掲載していました。Ivantiの8.8とは攻撃の複雑さやスコープの評価が異なります。本記事の表はベンダー評価と明記し、どちらかを無断で「公式統一値」にしていません。この差だけを理由に、悪用確認済みの装置の確認を延期しないでください。

次の表はIvanti公式告知のAffected VersionsとSolutionを合わせて整理したものです。数値の大小だけで違う系統や機種へ更新できるわけではありません。装置の機種、物理・仮想・クラウドの区分、現在の系統を先に確認します。

22.8系も2027年1月31日にEOL（サポート終了）を迎えると告知されています。直近の修正と、中期的な移行計画を分けて用意してください。また25.1.3.0への移行では、新しい物理機種や、対応テンプレートで構築した仮想・クラウド装置が必要と説明されています。「最も大きい版番号を選んで上書きする」という手順にはできません。

修正版の入手先は公式告知から案内されるIvanti License System（ILS）です。契約・機種に合う配布物を使い、公式の更新・移行互換性ガイドと照合します。本記事ではILSへログインして配布ファイルを取得する試験は行っていません。OS一般のパッケージ版やPC側クライアントの版から、ICS装置の修正状況を推定しないでください。

調査を行ったVolexityの報告では、攻撃者によるログの削除やメモリー上の変更が説明されています。ディスク上の変更を調べるIntegrity Checker Toolで異常が見つからなくても、この事例では侵害を否定できません。報告には認証情報の窃取や社内への展開につながる活動も含まれます。これは調査対象の事例であり、すべてのICS利用企業で同じ被害が発生したという意味ではありません。

IvantiはIntegrity Checker Toolの定期実行と、利用可能な侵害指標の確認を案内しています。「チェックを実行する」と「正常結果だけで調査を終わらせない」は両立します。侵害の疑いがある場合は、装置だけでなく、周辺の認証基盤・ネットワークの記録も含め、担当者やベンダーと調査範囲を決めます。

以下は編集上の運用提案です。担当者を決めたうえで、証拠保全と封じ込めを並行して判断してください。再起動や初期化を先に行うと揮発性の証拠を失う可能性があります。かといって、証拠収集のために攻撃が続く装置を放置するのも避ける必要があります。実際の順序はインシデント対応責任者と調整し、IvantiのRecovery Stepsを参照します。

1. 1装置を特定する。台帳と管理画面で、製品名・機種・稼働版・ビルド・系統・冗長構成を確認する。台帳の予定版を実際の稼働版と取り違えない。
2. 2露出を確認する。VPN利用口と管理口を区別し、許可された構成資料からインターネット公開や接続制限を確認する。記事を読んだだけで第三者の装置へ探索を行わない。
3. 3対応版を決める。公式告知と移行ガイドで機種に合う修正版を選ぶ。冗長構成の全ノード、復旧用装置、バックアップから復元した場合も対象にする。
4. 4侵害の疑いを別枠で扱う。装置・認証基盤・周辺通信の記録を保全し、異常の有無と調査の限界を残す。更新済みというだけで過去の侵害なしとしない。
5. 5変更計画に沿って更新する。停止影響、代替の接続手段、作業担当、確認担当を決める。侵害が疑われる設定やイメージを無条件に復元しない。
6. 6更新後を確認する。稼働版、全ノードの状態、正規利用者の認証・接続、必要な業務通信、ログ転送を確認する。疑われる認証情報の失効・交換は、封じ込めと復旧の計画の中で調整する。

この作業はVPN装置の運用担当者向けです。一般の利用者は、会社から案内された接続先と公式クライアントを使い、接続障害や不審な再認証の要求を窓口へ伝えてください。報道やメールをきっかけに、出所不明の「緊急修正ツール」を自分で導入する必要はありません。

公開範囲の縮小や許可された接続元への制限は、露出を減らすための候補です。ただし、管理画面だけを閉じてもVPN利用口の問題を直したことにはなりません。MFAはアカウント保護に有用ですが、装置の認証回避そのものを修正する代わりにはなりません。機能停止や切り離しが必要かは、業務継続と現在の侵害リスクを踏まえて判断します。本記事は、未確認の設定を「完全な回避策」として提示しません。

取得したKEVでは、111357の期限が11月2日、118527は11月13日です。これは米国連邦民間行政機関向けの対応枠組みにおける期限で、日本企業に一律に課された期限ではありません。また111357のforensicTriageはYes、118527はNoです。後者のNoを、連鎖した攻撃や自社装置について調査不要という意味に読み替えないでください。ランサムウェア利用欄は両件ともUnknownで、利用なしと確認されたわけではありません。

LLMへ装置の管理権限や生ログを渡す前に、機密を除いた台帳で棚卸しを始められます。版の比較で不明な点を勝手に補わせず、「修正済み」「侵害なし」「業務復旧」を別々に確認するための指示にします。次は運用支援用の教材で、LLMによる安全性の保証や、実機で検証済みの自動診断ではありません。

ICS更新・侵害確認シートに、装置・対応版・調査・接続確認を別々に記録できます。空欄は未確認です。承認待ちと作業済みも分け、担当者と期限を記入してください。

確認日：2026年11月1日朝JST。対象資料：Ivanti告知000109571（10月29日更新）、CISA KEV 2026.10.30、MITREの111357記録、Volexityの報告。公式告知は検索取得で制限があり、ブラウザーで本文と版表を確認しました。CVE-2026-118527のCVE APIは取得時404でしたが、ベンダー告知とCISA KEVで内容を照合しています。製品の実機試験、侵害調査、更新作業は実施していません。