>
>
公開日
Ivantiの脆弱性対策を担当する情報システム部門向けに、2026年10月に悪用されたIvanti Connect Secureの3件の脆弱性と影響を受ける版、22.8系のサポート終了日を整理します。更新後の侵害調査、整合性検査の限界、CISAが示す初期化と認証情報の再設定、管理画面の公開制限、ZTNA移行を検討する際の注意点まで解説します。
Ivantiの脆弱性とは
2026年10月、Ivanti Connect Secureの認証回避など3件の脆弱性が組み合わせて悪用され、米CISAが注意喚起を出しました。Connect Secureの脆弱性対応では、更新と侵害調査を分けて管理します。
本記事のポイント
更新状況と侵害状況は別々に管理します。
整合性検査の結果だけで侵害を否定しません。
2026年10月に悪用された3件は、いずれもCISAのKEVカタログに追加されています。
22.8系は2027年1月31日にサポートが終了します。
対象は、企業でVPN装置を管理する情報システム部門の担当者・管理者です。Connect Secureの脆弱性では、修正の適用と、すでに侵入されていないかの調査は別の判断として扱います。「Ivanti VPNの脆弱性」として情報を探す場合も、自社の対象製品と根拠資料を対応させて読み分けます。更新作業が終わったことだけを理由に、侵害調査まで完了扱いにしない運用を判断の軸にします。
CISAは2026年10月の注意喚起で、今回の悪用ではコマンドがメモリ上で実行されるため、IvantiのIntegrity Checker Tool（ICT）が痕跡を検出できない可能性があると注意しています。整合性検査は機器の改変などを調べる検査ですが、その結果だけを安全の証明にはしません。
対応記録を作る場合は、次の項目を分けます。更新完了の証拠がそろっても、侵害調査の根拠が不足する場合は調査を未完了として残します。
更新管理には、適用した版と作業結果を記録します。
侵害管理には、調査範囲と結果、未確認事項を記録します。
脆弱性連鎖と悪用状況の確認範囲
連鎖の成立、悪用の確認、KEVへの登録は発信元と確認時期が異なるため、項目ごとに分けて記録します。
2026年10月に悪用された3件の脆弱性
脆弱性連鎖とは、複数の脆弱性を組み合わせて攻撃につなげることです。CISAは2026年10月13日公開（10月30日改訂）の注意喚起で、Ivanti Connect Secureの次の3件が悪用されていると伝えています。KEVカタログの説明では、3件は互いに組み合わせて悪用され得るとされています。
CVE | 内容 | KEV追加日 | 対応期限（米連邦機関向け） |
|---|---|---|---|
CVE-2026-104935 | なりすましによる認証回避。認証なしで遠隔から任意のコマンドを実行される（CVSS 3.1：8.6） | 2026年10月13日 | 10月16日 |
CVE-2026-111357 | 重要な機能に認証がなく、ローカルの認証済み攻撃者が権限を昇格できる | 2026年10月30日 | 11月2日 |
CVE-2026-118527 | 推測可能な識別子の生成。認証済みの攻撃者が既知の場所に任意の内容のファイルを置ける | 2026年10月30日 | 11月13日 |
CISAは、攻撃者がこれらを悪用して認証情報の窃取とデータの持ち出しを行っていると説明しています。Ivantiも、CVE-2026-104935について限定的な悪用を把握していると公表しました（Ivantiの2026年10月の月例更新）。CISAの注意喚起は、攻撃者の名称を示していません。
一次情報に残る2024年の事象
CISAとIPAの2024年資料では、過去の悪用と整合性検査の限界、公開後の時系列を確認できます。
過去の事例として、CISAは2024年のIvanti製品に関する勧告で、CVE-2023-46805、CVE-2024-21887、CVE-2024-21893の悪用を対象とした調査において、内部・外部のICT、つまり整合性検査ツールが侵害を検知できなかったと報告しています。これは2024年の調査結果です。2026年10月の注意喚起でも、CISAはCVE-2026-104935の悪用をICTで検出できない可能性を示しています。
IPAは2024年の情報セキュリティ10大脅威・組織向け解説資料で、CVE-2024-21887とCVE-2023-46805に関する経緯を次のように整理しています。
日付 | 過去の経緯 |
|---|---|
2024年1月10日（現地時間） | Ivantiが脆弱性を公開しました。 |
2024年1月11日 | IPAが日本時間で注意喚起を実施しました。 |
2024年1月15日 | 国内での悪用が確認されました。 |
2024年の事例は、2026年の3件とは別の脆弱性です。時系列を混同しないよう、年ごとに分けて記録します。
KEV登録と対応期限の区別
KEVへの登録、追加日、対応期限は別々の確認項目です。
記録を作成する場合は、次の項目を分けると、悪用の確認と登録情報の混同を防げます。
連鎖については、組み合わせる脆弱性と成立条件を記録します。
悪用については、確認した発信者と対象期間を記録します。
KEVについては、登録の有無・追加日と対応期限を別欄に記録します。
一次資料で裏付けられた欄だけを確定し、裏付けのない欄は空欄のまま残します。悪用確認日をKEV追加日や対応期限として扱わないことが、年をまたいで同社製品の脆弱性情報を整理する際の判断基準です。
自社機器の版とサポート期限の判断
CISAは2026年10月30日の改訂で、影響を受ける版を25.1.1.2以前、25.1.2.2以前、22.8R2.5以前としています。10月13日時点の修正版（25.1.1.2、22.8R2.5など）も、その後に追加された脆弱性の影響を受けるため、適用する版はIvantiのセキュリティアドバイザリの最新の記載で確認します。22.8系は2027年1月31日にサポートが終了し、Ivantiは25.x系への早期の移行を勧めています。自社機器の実測情報と公式根拠を分けて記録し、照合できた範囲で更新計画への移行を判断します。
機器情報と対応責任者の棚卸し
影響判定の前に、機器から取得した情報と、対応を担う管理者・保守窓口を同じ台帳にまとめます。
デジタル庁は、管理対象となるインベントリ情報の例に、グローバルIPアドレス、ドメイン名、VPNなどのネットワーク機器を挙げています。自社の管理台帳を作る場合は、次の記入欄を設けると照合に使えます。
製品名：機器に表示された正式名称を記入します。
稼働版：管理画面などで取得した版表記を省略せず記入します。
機器識別情報：管理番号や機器を特定できる情報を記入します。
管理者：判定と作業調整を担当する部署・担当者を記入します。
保守窓口：契約先と問い合わせ先を記入します。
公開範囲：外部から接続できるアドレスと用途を記入します。
過去の台帳と実機表示が異なる場合は、取得日時と実機表示を残して差分を整理します。製品名だけを見て、別機器の判定結果を流用しない運用にします。
影響判定と更新経路の比較
影響対象と更新経路の両方を照合できれば更新計画へ進み、照合できなければ判定を保留します。
次の表は製品の優劣ではなく、判断材料がそろう場合と不足する場合の対応を比較したものです。
判断対象 | 機器側の記録 | 公式根拠 | 根拠がそろう場合 | 根拠が不足する場合 |
|---|---|---|---|---|
影響対象 | 製品名・稼働版・機器識別情報 | 対象脆弱性の公式告知と影響範囲 | 該当・非該当を根拠とともに記録します。 | 影響なしとせず、保守窓口への照会と公開範囲の見直しを並行します。 |
修正版への更新経路 | 現在の稼働版と構成 | 修正版の案内・更新手順・適用条件 | 影響判定と合わせて更新計画を作成します。 | 更新先を推測せず、適用可能な経路を保守窓口に照会します。 |
サポート期限 | 稼働版・保守契約の対象 | 公式のライフサイクル情報・保守窓口の回答 | 期限と保守条件に合わせて更新・更改時期を決めます。 | サポート継続を前提とする復旧計画から切り離します。 |
照合できない機器を「対応済み」にしないことが判定の境界です。保守窓口へ照会する場合は、台帳の機器情報を添え、回答を該当機器の記録にひも付けます。
サポート期限が不明な場合の扱い
期限を裏付けられない機器は、障害時も継続して保守を受けられる前提の復旧計画には組み込みません。
根拠を取得できるまでは、代替手段や更改候補を含めて計画を分けます。期限と保守条件が確認できれば計画へ反映し、確認できなければ保留を維持します。版番号の大小だけでサポート継続を判断したり、全機器を特定の版へ一律に更新したりしない扱いにします。
▲ 自社機器の公式根拠がそろう場合と不足する場合における対応方針の比較
更新作業の順序と完了条件
侵害を疑う材料がある場合は通常の更新作業だけで処理せず、証拠保全と調査を含む対応へ切り替えます。
実際の更新経路は、対象製品と現在の版に適用できるIvantiの公式案内を根拠に決めます。
通常更新と事故対応の分岐
作業開始時は、侵害兆候の有無だけでなく、判断に使える情報がそろっているかで対応を分けます。
判断状況 | 対応方針 |
|---|---|
侵害を疑う材料がある場合 | 通常の変更管理だけで進めず、事故対応の責任者へ引き継ぎ、証拠保全と調査を含む作業計画に切り替えます。 |
兆候が現時点で見つからない場合 | 確認範囲と限界を記録して通常更新を計画します。ただし、兆候がないことを未侵害の証明にはしません。 |
判断材料が足りない場合 | 「異常なし」ではなく「判断保留」とし、調査担当と情報不足のまま変更するリスクを評価します。 |
CISAは2026年10月の注意喚起で、侵害の有無を確かめるにはネットワークとメモリのフォレンジック調査が必要だとしています。ICTの検査結果は調査材料の一つとし、確認できた範囲と確認できなかった範囲を分けて記録します。
更新前後の作業フェーズ
通常更新へ進む場合も、着手時・変更前・更新時・更新後に担当と判断条件を分けると、保全や承認の抜けを防ぎやすくなります。
フェーズ | 担当 | 実施内容 | 判断条件 | 残す記録 |
|---|---|---|---|---|
着手時 | 運用担当・調査担当 | 侵害兆候と情報の不足を整理します。 | 疑いがあれば事故対応へ切り替え、材料不足なら判断を保留します。 | 判断根拠、担当者、未確認事項を残します。 |
変更前 | 運用担当・承認者 | 機器情報、現在の版、取得可能なログを記録します。 | 調査が必要なら保全方法を調整し、承認条件を満たしてから変更します。 | 取得日時、保存先、取得できなかった情報、承認内容を残します。 |
更新時 | 作業担当 | 対象機器に適用できると公式に確認できた更新経路だけを使います。 | 経路が確認できなければ、未確認の方法で進めず作業を保留します。 | 参照した公式案内、適用経路、実行日時、結果を残します。 |
更新後 | 運用担当・利用部門 | 更新後の版と利用中の接続機能を確認します。 | 想定した版への更新と接続が確認できれば更新作業を完了扱いにします。 | 版、接続確認結果、不具合、残作業を残します。 |
設定を退避できる場合は、変更前の状態として取得日時と保存先を記録します。CISAが示す復旧手順は初期化前に取得した設定を復元する流れですが、復元する前に、不審な管理者アカウントや説明できない設定変更が含まれていないかを確認します。停止が業務に影響する場合は利用部門と時間帯を調整し、承認が必要な運用なら、接続確認の項目と中断条件も承認対象に含めます。
更新完了の記録
更新の完了条件は「確認された更新経路の実施記録と稼働確認」、侵害調査の完了条件は「調査結果と残る不確実性の記録」です。
管理台帳に両方の状態欄を設けるなら、「機器識別情報／更新状態と根拠／侵害調査の状態／残る不確実性／次の担当と期限」を記録項目にします。更新だけが済んだ機器は「更新完了・侵害調査未完了」として残し、全対応完了とは区別します。
▲ 作業開始時における侵害兆候と判断材料の充足度に応じた対応分岐
侵害確認と初期化・認証情報再発行の判断
CISAは2024年の勧告「AA24-060B」で、整合性検査による検知の失敗を報告しました。2026年10月の注意喚起でも、CVE-2026-104935の悪用をICTで検出できない可能性を示し、ネットワークとメモリのフォレンジック調査を勧めています。検査結果だけでは侵害を否定できません。この製品の脆弱性対応では、装置の更新、侵害が疑われる装置の復旧、装置外のシステムにも関係する認証情報の対処を別々に管理します。
Integrity Checkerの結果と限界
Integrity Checkerは装置の整合性を調べるツールですが、その結果だけを侵害判断の根拠にはしません。
調査時は、検査結果、取得可能な機器ログ、認証側の記録、管理変更の記録を別の材料として整理します。検査結果には実行日時と対象機器を添え、機器ログでは観測した動作、認証側では接続元や利用アカウント、管理変更では設定変更の日時と実施者を照合する設計にします。
例えば、検査で異常が出なくても、更新前の期間に説明できない管理者ログインや設定変更が残っていれば、その時間帯の接続元と利用アカウントを洗い出して調査を継続します。記録がないことを「異常がなかった」と読み替える運用も避けます。
調査材料の確保と判断
侵害が疑われる場合は、復旧作業の前に取得可能な証拠と不足している記録を整理し、判断の根拠を残します。
以下を調査記録のテンプレートとして使い、取得できなかった項目も空欄にせず理由を記入します。保存先にはファイルの場所だけでなく、閲覧できる担当や取得日時も併記すると、引き継ぎ時に証拠をたどれます。
記入項目 | 記入内容 |
|---|---|
機器識別情報 | 機器名、製品名、版、管理番号、IPアドレス：＿＿ |
観測した事象 | 検査結果、不審な認証、説明できない管理変更：＿＿ |
対象期間 | 調査の開始・終了日時、記録が欠けている期間：＿＿ |
証拠の保存先 | 検査結果・各種記録の保存場所、取得日時、閲覧権限：＿＿ |
確認担当 | 機器・認証基盤の担当者、対応責任者：＿＿ |
対応状況 | 更新、接続制限、復旧、認証情報対処の進捗：＿＿ |
未解決事項 | 不足する記録、判断できない範囲、次の対応期限：＿＿ |
複数の記録を照合できるなら、事象と時系列の整合を調べます。十分な記録が得られない場合は未侵害と判定せず、不確実性と未解決事項を残したまま対応責任者へ引き継ぎます。引き継ぎ後は、追加調査、接続制限の継続、復旧の要否を判断対象にします。
初期化と認証情報の扱い
侵害が疑われるなら、装置を復旧する判断と、漏えいした可能性のある認証情報を処理する判断を分けます。
CISAは注意喚起で、侵害が疑われる場合に、Ivantiの復旧手順から次の作業を行うよう勧めています。
装置設定のバックアップを取得します。
工場出荷時の状態に初期化し、最新版へアップグレードします。クラウド・仮想環境はインスタンスを作り直してアップグレードします。
1.で取得したバックアップから設定を復元します。
ドメイン・管理者・ローカルを含むすべてのアカウントのパスワードを再設定し、装置に保存された証明書を失効・再発行し、保存されたAPIキーとライセンスサーバの認証情報を再設定します。
社内では、この手順を次の流れに組み込んで管理します。
証拠の確保：取得可能な検査結果や記録を保存し、不足分も記録します。
公開範囲や接続の制限：侵害が疑われる機器について、業務影響を整理して制限範囲を決めます。
公式手順に基づく復旧：対象製品・版に対応する公式手順を判断根拠とし、初期化を含む復旧方法を選定します。
漏えい可能性に応じた認証情報の対処：調査結果と権限範囲を基に、失効・再発行の対象と管理主体を決めます。
再開判断：復旧結果、認証情報の対処状況、残る不確実性を対応責任者が整理し、再開条件を満たすか判断します。
認証情報は、パスワード、証明書、APIキー、ライセンスサーバの認証情報を対処の対象にします。台帳には、装置に保存されていたか、どのシステムへ権限が及ぶか、失効時に何が停止するか、管理主体、対処予定、完了状況を記入する設計にします。値そのものは調査台帳へ転記せず、管理先を追える形にします。
漏えいを否定できない認証情報があれば、装置更新だけで対応を終了せず、管理主体と失効・再発行の計画を共有します。失効で業務停止が見込まれる場合は、代替接続や切り替え条件も計画に含め、未処理の認証情報を残したまま復旧完了にしない運用にします。
▲ 整合性検査だけに依存せず複数の記録を突き合わせる調査構成
更新後に対応を終える失敗パターン
パッチ適用済みや整合性検査の異常なしだけを理由に、侵害調査を終了する判断は避けます。以下は、この種のVPN装置の運用で避けたい失敗パターンと、その修正方針です。
更新完了と調査完了の混同
CISAは、2024年の事案で整合性検査ツールが侵害を検知できなかったと報告し、2026年10月の悪用でもICTが痕跡を検出できない可能性を示しています。調査範囲、確認結果、未確認事項を説明できる状態になってから、侵害調査の終了を判断します。
初期化前の証拠消失
初期化を急ぐ場合でも、調査に使う記録の確保を省略しません。記録の保存前に初期化すると、侵害の有無や影響範囲を判断する材料を失うおそれがあります。「復旧できたので調査も終了」と扱うことが誤判断です。初期化を予定するなら、ログや検査結果などの保存先・取得時刻・取得担当者を記録し、調査担当者が利用できる状態を実施条件にします。確保できない記録があれば、その不足と判断への影響も残します。
認証情報と引き継ぎの漏れ
認証情報の扱いに未判断の項目があるなら、更新作業だけで対応を閉じません。漏えいの可能性を調べず既存の認証情報を継続利用すると、装置の復旧と認証情報への対処が切り離されたままになります。漏えいが疑われる場合は失効・再発行の対象と担当者を決め、判断材料が不足する場合は未完了として引き継ぎます。引き継ぎ先には実施済みの作業だけでなく、未調査の範囲と次の判断を担う担当者も明記します。
停止や認証情報の失効は業務接続に影響する一方、稼働継続には調査中の接続を残す注意点があります。実施判断には、次の条件表を使います。
把握状況 | 修正する運用 |
|---|---|
接続先と代替経路を把握できる場合 | 業務への影響を整理し、停止・失効に合わせた切り替え計画へ進みます。 |
接続先や代替経路を把握できない場合 | 担当部門と影響範囲を特定してから、実施可否と判断理由を記録します。 |
VPN装置の公開範囲とZTNA移行の検討
管理用の接続と業務用の接続を分け、必要な接続元と接続先を特定できる範囲から公開制限とアクセス設計の見直しに進みます。
IPAは『情報セキュリティ白書2026』で、警察庁の資料を基に、2025年のランサムウェアの感染経路は有効回答92件中、VPN機器が61件、66.3％だったと紹介しています。これは回答された感染経路の内訳であり、全企業の被害確率や特定ベンダー製品に固有の割合ではありません。緊急の更新対応を終えた後は、更新だけでなく、外部からどこへ接続できるかも見直します。出典：IPA『情報セキュリティ白書2026』第1章
管理画面の公開範囲と接続経路
管理画面は、業務用の接続とは別に、接続元と管理権限を整理します。
自社の見直し項目は、管理画面へ接続する拠点・端末、管理者権限の付与先、認証方法、ログの保管先、緊急時の管理経路です。担当者だけでなく、保守委託先が使う経路も台帳に記載します。特定製品の設定や機能を前提にせず、必要な接続元が特定できれば、その範囲に絞る構成を検討します。
緊急時の管理経路が未整理なら、先に代替経路と利用責任者を決めます。復旧に使う経路を確保しないまま公開制限を変更することは避けます。業務接続についても、利用者と接続先の対応を記録し、不要な接続と判断できる範囲から削減します。
ZTNAへの段階移行と注意点
ZTNAは、接続先へのアクセスを利用者や端末の条件に基づいて制御する考え方であり、置き換えだけで対策が完了するものではありません。
Connect Secureの提供元は、VPNとZTNAを単一の統合エンドポイントクライアント上で共存できると案内しています。この説明は段階移行を検討する材料ですが、自社の移行対象、費用、期間、既存接続との互換性を保証するものではありません。出典：IvantiによるVPNとZTNAの単一クライアントでの共存説明
共存期間を設ける場合は、VPN側に残す接続とZTNA側で検証する接続を分け、認証条件の変更、ログの確認、障害時の切り戻しを誰が担うかまで決めます。接続を限定しやすい一方、併用中は両経路の運用が残る点にも注意します。
接続先と利用者・端末の認証条件を記録できた範囲から、対象を限定して移行を検証し、業務接続と管理経路を分けて評価します。
情報が不足する場合は一括移行を避け、接続元、接続先、認証条件、運用責任者を記載した接続台帳の作成を先に行います。
着手項目のチェックリスト
次の項目を既存の台帳や対応記録にそろえると、公開制限と移行検証の対象を判断できます。
機器情報：製品名、稼働版、設置場所を記録します。
更新状況：適用済みの更新と残作業を整理します。
調査記録：侵害調査の結果と未解決事項を残します。
公開範囲：管理用・業務用それぞれの接続元と接続先を記載します。
担当者：設定変更、ログ確認、緊急対応の責任者を決めます。
移行の検討では、整理した接続台帳を基に、移行対象と継続する運用を分けて検討します。
まとめ
2026年10月、Ivanti Connect Secureの3件の脆弱性（CVE-2026-104935、CVE-2026-111357、CVE-2026-118527）が組み合わせて悪用され、米CISAがKEVカタログに追加しました。
稼働版を確認します。CISAは25.1.1.2以前、25.1.2.2以前、22.8R2.5以前を影響を受ける版としています。適用する修正版は、Ivantiのアドバイザリの最新の記載で確認します。
22.8系は2027年1月31日にサポートが終了するため、25.x系への移行も計画します。
更新とは別に侵害調査を行います。ICTは今回の悪用の痕跡を検出できない可能性があります。
侵害が疑われる場合は、初期化と最新版へのアップグレード、すべてのアカウントのパスワード・証明書・APIキーなどの再設定を行います。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
