>
>
公開日
VPNの脆弱性対策を担う情報システム部門向けに、2026年10月〜11月に悪用されたPAN-OS・Cisco ASA/FTD・SonicOSの脆弱性を比較表で整理します。境界機器の棚卸し、KEVを使った更新優先順位、管理画面やVPNの公開範囲、保守ベンダーへの確認事項まで、対応漏れや更新後の確認不足を防ぐ実務の進め方を解説します。
VPNの脆弱性とは
VPNの脆弱性対策では、自社機器への該当性と公開範囲を整理し、更新と暫定対応の順序を決めます。
本記事のポイント
棚卸しでは、稼働中・予備の機器と製品名・バージョン・設定を整理します。
根拠は、公式発表で確認できた情報と、まだ確認できていない情報に分けます。
公開範囲は、VPN接続口と管理画面を分けて整理します。
対応完了は、更新の実施だけでなく、設定と確認結果の記録を含めて判定します。
対象は、法人の情報システム部門の担当者・管理者です。担当者は台帳と設定の整理を担い、管理者は停止許容時間と対応責任を判断する読者として位置付けます。企業規模による区分は設けません。ここで扱うVPNの脆弱性とは、社内外の接続点となる境界機器のうち、リモートアクセスVPN（SSL-VPNを含む）の接続口と管理インターフェースにある、攻撃に悪用され得る弱点です。VPN装置の安全性を一般論で評価するのではなく、自社機器への該当判定と対応判断を扱います。接続方法の解説はVPNの基礎・接続方法の記事に分離します。
この記事の扱う範囲
個別CVE（脆弱性の識別番号）の修正版やKEV（CISAの既知悪用脆弱性カタログ）の掲載状況は、公表後も更新されます。本記事では、2026年10月〜11月に悪用が確認された主な製品の脆弱性を整理したうえで、自社機器と照合する手順を中心に扱います。
製品名だけが一致しても、該当性の判断は完了しません。対象バージョンや設定条件の根拠がそろえば対応判断に進み、そろわなければ「非該当」ではなく「未判定」として管理します。
直近の公表状況と製品別の対応比較
以下は2026年11月9日時点で、各社のセキュリティアドバイザリとCISAのKEVカタログで確認した内容です。修正版や悪用状況は更新されるため、照合するときは必ず原文を開き直してください。
CVEは個々の脆弱性を識別する番号です。
製品 | CVE | 影響条件 | 悪用の有無 | 修正版 | 回避策の有無 | 公表日・根拠 |
|---|---|---|---|---|---|---|
Palo Alto Networks PAN-OS（PA-Series・VM-Series・Panorama） | CVE-2026-0322（管理インターフェースのリモートコード実行） | 特別な設定がなくても影響を受けます。管理インターフェースに接続できる認証済みの攻撃者が、root権限でコードを実行できます。Cloud NGFWとPrisma Accessは影響を受けません。 | ベンダーが限定的な悪用を確認しています。KEV追加：2026年10月14日 | 系列ごとに異なります（例：12.2系は12.2.4以降）。hotfix版を含む一覧はアドバイザリを参照します。 | なし。管理インターフェースへの接続を信頼できる内部のIPアドレスや踏み台サーバーに限ると、リスクを下げられます。 | 2026年10月14日公表。Palo Alto Networksのアドバイザリ |
Cisco Secure Firewall ASA／FTD | CVE-2026-76418（リモートアクセスSSL VPNのサービス妨害） | SSL VPNのログイン画面に到達でき、トンネルグループ（既定のDefaultWEBVPNGroupを含む）に二次認証を設定している場合に影響を受けます。認証なしで装置を再起動させられます。 | Ciscoが2026年10月に悪用を確認しています。KEV追加：2026年10月29日 | ASA：9.16.4.104、9.18.4.96、9.20.4.50、9.22.3.200、9.23.1.48、9.24.1.27など。FTD：7.0.11、7.2.13、7.4.9、7.6.7、7.7.14、10.0.3、10.1.1 | なし。二次認証の無効化などの緩和策はありますが、修正版を適用するまでの一時的な手段です。 | 2026年10月28日公表。Ciscoのアドバイザリ |
SonicWall SonicOS（Gen7・Gen8） | CVE-2026-19868（SSLVPNのSAML認証・MFAの回避） | SSLVPNのログインでSAMLを有効にしている場合だけ影響を受けます。別の認証方式の有効な資格情報を持つ利用者が、SAML認証（SAMLで強制するMFAを含む）を回避できるおそれがあります。対象はGen7の7.3.3-7015以前、Gen8の8.2.2-8015以前です。 | SonicWallが悪用の可能性を示す報告を調査しています。KEV追加：2026年11月6日 | Gen7：7.3.4-7013以降、Gen8：8.2.3-8015以降 | なし | 2026年11月6日公表。SonicWallのアドバイザリ（SNWLID-2026-0014） |
PAN-OSのCVE-2026-0322は、VPN（GlobalProtect）ではなく管理インターフェースの脆弱性です。Palo Alto Networksは、管理インターフェースをインターネットから接続できる状態にしている場合にリスクが最も高いとしています。3件とも回避策はなく、修正版への更新が対策の中心です。
自社の機器と照合する表を作る場合は、次の区別を維持します。「未確認」は「影響なし」や「悪用なし」を意味しません。
「未確認」は、判断に必要な根拠を確認できていない状態です。表では、照合前の項目を空欄にせず「未確認」と記入します。
「公式資料に記載なし」は、対象の公式資料を閲覧し、その項目の記載がないと確認した場合の表記です。照合前の段階では使いません。
「該当なし」は、その項目が対象に当てはまらないと根拠に基づいて判断できた場合の表記です。情報不足の代用には使いません。
参考：過去の事例
IPA（独立行政法人情報処理推進機構）は「情報セキュリティ10大脅威 2025」の組織編解説資料（PDF）で、Palo Alto Networksが2024年4月12日に公表したPAN-OSのGlobalProtect機能の脆弱性を紹介しています。認証されていない遠隔の第三者がroot権限で任意のコードを実行できる脆弱性（CVE-2024-3400）で、深刻度の評価値はCVSS v3.0で最大値の10.0、ゼロデイ攻撃での悪用も確認された事例です。出典はIPA「情報セキュリティ10大脅威 2025」組織編の解説資料です。この事例は、上の表にある2026年のPAN-OSの脆弱性とは別のものです。
同じ時期にKEVへ追加されたCisco Secure Email Gatewayの脆弱性（CVE-2026-76519）は、VPN機器ではなくメールゲートウェイの脆弱性のため、上の表には含めません。2026年10月14日に公表され、ファイルレピュテーション機能が有効でContent Scanner Toolsが25.3.0.5525より前の場合に影響を受けます。回避策はなく、Ciscoが悪用を確認しています。Ciscoは侵害が疑われる仮想アプライアンスについて、更新すると調査用の記録とログが失われるとして、更新前に記録を保全するよう求めています。
自社の稼働版が影響条件に当てはまれば更新対象へ進め、根拠がそろわなければ未判定のまま管理します。
比較表を更新する際は、製品名だけで対応版を決めないため、次の順序で根拠を反映します。
公式アドバイザリで製品とCVEの対応を確認できた場合は、表に番号と出典を追加します。対応を確認できなければ、照合対象のまま保持します。
影響条件と修正版を確認できた場合は、自社環境との照合に進みます。確認できない段階では、更新先の版も対応不要の判断も保留します。
対応漏れを防ぐ境界機器の棚卸し
更新対象を決める前に、境界機器の製品・稼働版・有効機能・公開範囲を同じ台帳にまとめます。
境界機器は、社内ネットワークと外部との接続点に置く機器を指します。VPNの脆弱性情報と自社資産を結び付けるため、以下を棚卸しの運用案として使います。通常稼働中の装置に加え、予備機、仮想機器、委託先管理の機器も対象候補に含めます。
台帳の必須項目
台帳は1機器につき1行とし、製品情報と運用情報をひも付けます。既存台帳に不足がある場合は、次の項目を列として追加すると、影響判定に使う情報を同じ場所で管理できます。
項目 | 記入欄・記入内容 |
|---|---|
製品・機種 | ＿＿：製品名と機種名 |
稼働バージョン | ＿＿：実機で確認した版の表記 |
有効機能 | ＿＿：現在有効にしている機能 |
設置場所 | ＿＿：拠点、保管場所、仮想機器の配置先 |
管理責任者 | ＿＿：所属・担当者・連絡先 |
保守窓口 | ＿＿：契約先・問い合わせ先 |
外部公開の有無 | ＿＿：有・無・不明、公開先と接続元の範囲 |
業務用途 | ＿＿：利用業務、接続先、停止時の影響 |
証拠の取得日 | ＿＿：取得日と設定情報・画面記録の保存先 |
未確認の欄は空白にせず「不明」と記入します。管理用の接続口とVPN接続用の入口で公開範囲が異なる場合は、分けて記録する設計にします。証拠の保存先も残せば、後から判定の根拠をたどれます。
台帳と実機の照合
既存情報を起点に実機の状態を確かめ、契約情報まで照合して担当範囲を整理します。情報が食い違う場合は、古い記載をそのまま転記せず、差分を残します。
既存台帳から対象候補を抽出し、機器を識別できる管理番号などを付けます。
設定情報と照合し、有効機能や公開範囲の記載を補います。設定の取得日も併記します。
管理画面で製品・機種と稼働バージョンを照合し、確認した画面の記録を保存します。
保守契約と照合し、対象機器と保守窓口の対応関係を確定します。契約情報だけでは現在の稼働版を確定しません。
必要な情報がそろった機器は、脆弱性情報との該当性判定へ進めます。稼働版が不明な機器は「未判定」とし、確認担当者と期限を割り当てます。
予備機と委託機器の扱い
予備機や委託先管理の機器も、利用頻度にかかわらず棚卸しの対象に含めます。接続中の予備機がある場合は通常機と同じ台帳に載せ、保管中なら所在と接続状態を記録します。
仮想機器がある場合は、物理装置とは別の資産として識別します。委託先が管理する機器は、自社側の責任者を決め、委託先から得た稼働版や設定の証拠を台帳に反映します。回答待ちなら未判定のまま期限を管理する扱いです。
所在不明と非稼働は同義にしません。把握できない機器には、情報を補う責任者を割り当て、所在や接続状態の裏付けが取れてから状態を更新します。
製品固有の対応は、FortiGateの脆弱性対応と更新計画とIvantiの脆弱性対策の記事で扱います。台帳が整った機器から、自社条件に基づく該当性判定へ進めます。
KEV照合と自社条件による更新優先順位
KEVへの掲載状況はCVEごとに異なるため、CISAのカタログで該当CVEの掲載を確認するまでは、自社の更新順位を確定できません。VPNの脆弱性への対応順は、深刻度だけで決めず、根拠の確認状態、自社への該当性、外部からの到達可能性、業務停止への備えを分けて判断します。
該当性と外部到達性の判定
影響条件、対象機能の有効・無効、外部到達性は、それぞれ独立した判定欄で管理します。以下を運用案として使えば、情報不足を「該当なし」と取り違えずに対応計画へつなげられます。
判定項目 | 判断材料 | 記録と判断への反映 |
|---|---|---|
影響条件への該当性 | ベンダー情報と自社の製品・バージョン・構成 | 該当／非該当／未判定を根拠とともに記録し、該当なら対応対象に含めます。 |
対象機能の有効性 | 設定内容とベンダーが示す影響条件 | 有効／無効／未判定を記録します。無効という理由だけで対象外にせず、影響条件と照合します。 |
外部からの到達可能性 | 通信経路とアクセス制御の設定・確認結果 | 到達可能／到達不可／未判定を記録し、到達可能な対象は優先対応の候補にします。 |
条件が確定した対象は対応計画へ進め、非該当と判断した対象にも根拠を残します。不明な項目があれば未判定として調査担当と次回判断時点を記録し、対応済みには含めません。外部から到達できないという結果も、脆弱性そのものの解消とは分けて扱います。
KEV照合結果の反映
CISAの該当レコードとベンダー情報を追加確認できた場合は、確認済みの悪用情報を更新順位に反映する運用にします。掲載日や対応期限は、CISAの該当レコードで確認できた内容だけを判断根拠にします。
照合結果には参照先、確認日時、該当CVE、確認できた内容を残します。自社への該当性と外部到達性も確認でき、悪用情報が裏付けられた対象は、優先対応の候補として変更承認者へ提示します。一方、掲載を確認できないことは安全性の根拠にしません。未確認の情報で順位を固定せず、追加情報を得た時点で見直す設計にします。
対応フェーズと完了条件
対応は検知から更新後までを分け、各段階の担当と完了条件を決めます。次の表は役割分担の案であり、一律の対応時間やCISAの期限を自社への義務として設定するものではありません。
フェーズ | 担当 | 作業 | 判断材料 | 完了条件 |
|---|---|---|---|---|
検知時 | 情報受付担当 | 対象候補と確認状態を登録します。 | 公表情報、機器情報 | 調査担当と次回判断時点が決まっています。 |
影響判定後 | 機器管理担当 | 更新または暫定対応の計画を作成します。 | 該当性、到達性、悪用情報 | 対応対象、優先順位、その根拠を記録しています。 |
変更承認後 | 変更実施担当・業務担当 | 承認範囲で変更を実施します。 | 検証結果、停止影響、切り戻し手順 | 実施結果と残課題を記録しています。 |
更新後 | 機器管理担当・業務担当 | 適用状態と業務の動作を確認します。 | 更新結果、設定、接続試験 | 予定した対処と動作確認が完了し、残課題に担当を割り当てています。 |
更新版が確認できれば検証と変更承認へ進み、業務停止が伴う場合は停止範囲、代替手段、切り戻し条件を承認材料に含めます。更新版や回避策が未確認なら製品固有の対応は断定せず、自社側で可能な公開範囲の制限と保守窓口への照会を並行させます。その場合は暫定対応として管理し、恒久対応の完了とは区別します。
▲ 検知から更新後までの対応フェーズと各段階における完了条件の流れ。
管理画面とVPNの公開範囲を絞る運用
管理画面と業務用VPNの公開範囲は分けて判断し、利用目的に必要な接続だけを残します。更新待ちの間も、不要な外部接続を減らす利点と、管理不能・業務停止のリスクを併せて検討します。Palo Alto Networksも、PAN-OSの管理インターフェースへの接続を信頼できる内部のIPアドレスや踏み台サーバーに限ることで、リスクを下げられるとしています。
管理経路の制限
外部からの管理が不要で、内部から管理を継続できるなら、管理画面の非公開化を検討します。
遠隔管理が必要な場合は、接続元の限定や専用の管理経路への切り替えが、製品の機能と自社の体制で可能かを整理します。制限によって不要な接続を減らせても、担当者自身が締め出されては復旧作業に支障が出ます。変更前に、現地操作などの代替管理手段と担当者を確保します。代替手段が使えなければ、その制限は実施せず、実行可能な範囲へ変更案を絞ります。
業務用VPNの制限
業務用VPNは、利用者・接続元・利用時間・接続先を見直し、業務に必要な範囲を残します。
経済産業省は工場システム向けガイドライン概要で、工場の産業制御システムに外部からリモートメンテナンスなどで接続する場合の保護対策として、2要素認証や利用者ごとの接続対象機器・接続可能時間の制限などを挙げており、事務系ITのVPNへの要件ではなく制限項目を検討する際の参考例にあたります。自社で採用する項目は、利用製品が対応する機能に限ります。
利用者：継続利用が必要な担当者と、停止できるアカウントを整理します。
接続元：許可する範囲と、固定の接続元を持たない利用者への影響を記録します。
利用時間：通常業務に加え、夜間対応や緊急保守の要否を整理します。
接続先：必要なシステムを列挙し、制限すると使えなくなる業務を記録します。
制限で業務が止まる場合は、例外の対象・承認者・期限を記録するか、承認済みの代替手段へ切り替えます。
暫定措置の期限管理
暫定措置を実施するなら、責任者と解除条件を記録し、更新などの恒久対応へ引き継ぎます。
記録項目 | 記載内容 |
|---|---|
責任者 | 変更・継続・解除を判断する担当者 |
開始日・見直し期限 | 実施日と継続可否を再判断する日 |
解除条件 | 恒久対応の完了と接続確認などの条件 |
恒久対応への引継ぎ | 対応内容、担当者、予定日、残る制限 |
制限後に必要な接続とログを確認でき、支障がなければ運用を継続します。支障が出れば承認済みの代替手段へ切り替え、確認できない状態では措置を完了扱いにしません。
ベンダーが示す緩和策も、恒久対応の代わりにはなりません。たとえばCiscoは、ASA/FTDの脆弱性（CVE-2026-76418）で二次認証の無効化を緩和策として示していますが、リモートアクセスVPNのセキュリティ水準が下がること、修正版を適用するまでの一時的な手段であることを明記しています。
攻撃の再現手順は扱いません。認証設定の変更だけを、製品脆弱性の解消として扱わないよう、暫定措置と恒久対応の完了を別々に管理します。
▲ 管理経路と業務用VPNにおける公開制限の方針と運用上の着手条件の比較。
脆弱性対応で避けたい失敗パターン
未確認情報の確定扱いと、更新作業だけでの完了判定は避けます。以下は、VPNの脆弱性対応で予防したい運用上の失敗パターンです。
情報判断の失敗
情報判断では、根拠の不足によって対応を急ぎすぎたり、先送りしたりする失敗を防ぎます。
検索結果の要約だけでは、悪用の有無や修正版の適用条件まで把握できるとは限りません。公式案内と対象製品・バージョンが一致すれば対応計画へ進み、一致を確認できなければ確定情報として扱わず、調査を続けます。
異なる年のCVEを混同すると、別の脆弱性向けの修正版を選ぶおそれがあります。脆弱性を識別するCVEは番号全体で照合します。
変更作業の失敗
変更作業では、更新内容だけでなく、作業後も管理と復旧を続けられる条件を整えます。
事前検証なしの更新は、接続や設定への影響を把握しないまま本番環境を変更する進め方です。事前の設定・稼働状態を記録できれば検証へ進み、復旧手段を用意できなければ、作業時間や支援体制などの変更条件を見直します。
公開制限によって管理経路まで失う変更も避けます。たとえば、遠隔から管理画面の公開を止めた結果、現地へ行ける担当者がおらず設定を戻せなくなるケースです。拠点が遠い場合は、現地操作の担当者を先に決めておくか、制限を接続元の絞り込みにとどめる判断になります。制限後に使う管理経路を確保できることを着手条件に含めます。予備機を利用する構成なら、その更新漏れも判定対象に加え、本番機だけの更新記録で作業を閉じません。
完了判定の失敗
完了判定では、バージョン表示に加え、自社で決めた試験と記録がそろったかを判断します。
侵害の疑いがある場合は、更新できたことを理由に通常の更新案件へ戻さず、ログを保存して調査・対処の判断を別途残します。暫定措置を採用する場合も、期限と解除条件、担当者を決め、期限なしで放置しません。
失敗パターン | 防止策と残す記録 |
|---|---|
要約や別のCVEで判断する | 公式案内、CVE番号、対象条件と判断根拠を対応付けます。 |
復旧できない変更や予備機の更新漏れ | 管理経路・復旧手段と、機器ごとの作業結果を残します。 |
バージョン表示だけで完了にする | 接続試験、設定差分、ログ保存、担当者承認のうち、自社で採用した完了条件と実施結果を記録します。 |
採用した完了条件に未達項目があれば対応中として扱い、残作業の担当者と期限を引き継ぎます。
保守ベンダーへの確認事項と回答後の判断
保守ベンダーへの依頼には、対象機器の情報と、回答後に決める作業をセットで記載します。完成した台帳を添付し、台帳の管理番号で対象を指定すれば、棚卸し項目を問い合わせ本文に再掲せずに依頼できます。VPNの脆弱性対応では、該当性の判定、更新の実施可否、侵害調査の要否を分けて回答を受け取る形式にします。
以下を共通の問い合わせ欄として使い、各依頼の回答と判断記録をひも付けます。回答できない項目には、未回答の理由と回答可能日を記入してもらう形式です。
項目 | 記入欄 |
|---|---|
依頼対象 | 添付台帳名：＿＿／対象の管理番号：＿＿／対象の脆弱性：＿＿ |
回答希望日・担当者 | 回答希望日：＿＿／社内担当者：＿＿／ベンダー担当者：＿＿ |
回答・根拠 | 回答内容：＿＿／根拠資料名・該当箇所：＿＿ |
回答後の作業 | 回答がそろった場合：＿＿／不足・未回答の場合：＿＿／作業担当者：＿＿ |
次回判断日 | 判断日：＿＿／その日までに補う情報：＿＿ |
影響判定の依頼
影響判定では、対象機器への該当性と、その判断に至った根拠をセットで求めます。
依頼文には「添付台帳の対象機器について、該当・非該当の判定、影響を受ける設定や利用条件、根拠資料名と該当箇所をご提示ください」と記載します。「問題なし」という結論だけでなく、自社の条件との照合結果まで回答欄に残す形式にします。
非該当の根拠が得られた場合は、対象、判断日、回答者、根拠を判定記録に残します。該当する場合は更新計画の検討へ進みます。
回答が曖昧、または回答希望日までに返答がない場合は、未判定を維持し、不足する根拠を明示して追加照会の期限と次回判断日を決めます。
更新計画の依頼
更新計画では、修正版の有無だけでなく、作業を承認できる条件まで回答してもらいます。
質問欄 | 回答欄 |
|---|---|
対象機器に適用する修正版はどれですか。 | 版・根拠資料：＿＿ |
現在の版からの更新経路はどうなりますか。 | 中間更新の要否・手順：＿＿ |
事前検証は何を、誰が実施しますか。 | 検証項目・担当・完了条件：＿＿ |
停止による業務への影響はありますか。 | 停止範囲・見込み時間：＿＿ |
更新に失敗した場合の復旧方法は何ですか。 | 復旧手順・判断条件・担当：＿＿ |
実施条件がそろえば、回答を添えて社内の変更承認へ進みます。
条件が不足すれば、阻害要因、代替策、解消担当者、再判断日を対応計画に残します。未回答を実施可能と読み替えず、保守ベンダーに不足部分の回答期限を求めます。
侵害の疑いへの対応依頼
侵害が疑われる場合は、更新作業とは別に、記録の保存と調査の担当範囲を決めます。
依頼欄には「取得可能なログと対象期間、保存・受け渡し方法、調査窓口、通常保守と調査対応の役割分担」を設けます。ログの取得担当者と、取得前に避ける操作も回答に含めてもらいます。
疑わしい兆候がある場合は、更新だけで解決済みにせず、保存した記録と未確認事項を組織の事故対応手順へ引き継ぎます。
調査対応が通常保守の範囲外、または回答がない場合は、社内の事故対応責任者へ連絡し、別の調査窓口への依頼可否を次回判断日に決めます。
▲ 保守ベンダーへの影響判定依頼後の回答状況に基づく判断の流れ。
まとめ
2026年10月〜11月には、PAN-OS（CVE-2026-0322）、Cisco ASA/FTD（CVE-2026-76418）、SonicOS（CVE-2026-19868）の脆弱性が悪用され、CISAのKEVカタログに追加されました。いずれも回避策はなく、修正版への更新が対策の中心です。
自社の対応は、境界機器台帳の担当者を決めるところから始めます。稼働版または公開範囲が不明な機器は、台帳に未判定として記録し、安全と判断した機器に含めない運用にします。
対応開始時は、次の項目だけを埋めます。
対象台帳：対応に使う境界機器台帳
判断責任者：未判定機器の扱いを決める人
次回判断日：判明した情報を基に対応を決める日
次回判断日にも不明点が残る機器は、未判定のまま管理を続けます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
