Cisco Catalyst SD-WANにCVSS9.9が3件・回避策なし｜拠点ネットワーク機器のパッチは誰の仕事か

今回のアドバイザリで経営が押さえるべき点は3つある。深刻度が最高位であること。回避策が存在しないこと。そして現時点で悪用は確認されていないこと。この3つが同時に成り立つ状況は、実は対応しやすい。攻撃が始まる前に、計画的に直せる時間があるという意味だからだ。

Ciscoは2026年8月5日、「Cisco Catalyst SD-WAN Software Security Hardening Release: August 2026」と題するセキュリティアドバイザリを公開した。Security Impact RatingはCriticalで、対象となる脆弱性は次のとおりである。

Ciscoのアドバイザリによれば、これらは社内のセキュリティ強化レビューの過程で発見されたもので、PSIRTは公開された攻撃情報や悪用の事実を把握していないとしている。そして重要なのは、**「これらの脆弱性に対処する回避策は存在しない」**と明記されている点である。設定変更で凌ぐ選択肢はなく、修正版への更新が唯一の対応になる。

なお報道によれば、Ciscoは同時期にIOS XEを含む複数の製品について、合計12件のアドバイザリを公開している。SD-WANだけでなく、自社が使用しているCisco製品全般について確認する必要がある。

拠点や工場、店舗をネットワークでつないでいて、その機器の面倒を自社では見ていない。この状態にある会社が、誰に何を確認すればよいのか。以下はその手順である。

この記事を読むべき人

• 本社と支店・工場・店舗をWANでつないでおり、機器の型番や設定を把握していない会社
• ネットワークの構築をSIerや通信事業者に任せ、それ以降ほとんど触っていない会社
• 「ネットワークは動いているから大丈夫」という状態が数年続いている会社
• 情報システム担当が1名または兼任で、ネットワーク機器まで手が回っていない会社
• 過去にネットワーク機器を導入したが、その後の保守契約の状況を確認していない会社

「悪用されていない」を「急がなくてよい」と読まない

今回のアドバイザリでもっとも誤読されやすいのが、悪用が確認されていないという記述である。これは対応を遅らせてよい理由にはならない。理由は3つある。

第一に、**アドバイザリの公開は、攻撃者にとっての情報公開でもある。**どのバージョンのどの機能に問題があるかが公表された時点で、解析を始める者が出てくる。過去の事例では、公開から実際の攻撃観測までの期間が短縮される傾向が続いている。

第二に、**回避策がないため、対応の選択肢が更新の一手しかない。**通常であれば「パッチ適用までの間、設定で該当機能を止める」といった時間稼ぎができる。今回はそれができない。つまり、直すか、直さないかの二択である。

第三に、**SD-WANの管理機能は、ネットワーク全体を制御する位置にある。**Catalyst SD-WANの構成では、Manager、Controller、Validatorといった管理系のコンポーネントが、各拠点の機器を集中管理する。ここが侵害されると、影響は1拠点ではなく全拠点に及ぶ。個別の拠点ルータの脆弱性とは、被害の広がり方が違う。

**一方で、悪用が確認されていない段階だからこそ、計画的な更新ができる。**深夜作業の日程を調整し、拠点への影響を事前に通知し、切り戻し手順を用意したうえで実施できる。攻撃が観測されてから動くと、この余裕がなくなる。今回のタイミングは、慌てる必要はないが先送りもできない、という位置づけになる。

5件の内容を経営の言葉に置き換える

アドバイザリに並んだ5件を個別に読むと、深刻度の違いに目が行く。ただし個々の分類名は専門用語で、そのままでは判断に使えない。経営の言葉に置き換えると次のようになる。

**「パス・トラバーサル、ファイルパスの外部制御」**は、本来触らせるつもりのない場所のファイルに手が届いてしまう問題である。

**「アクセス制御の不備（認可・認証・権限のバイパス）」**は、その操作をしてよいかの確認が正しく行われない問題である。

**「ファイルアクセス前のリンク解決の不備」**は、ファイルへの近道（リンク）を細工することで、意図しない場所へ誘導できてしまう問題である。

**「機微情報の平文保存」**は、認証情報などが読める形で保存されている問題である。単体では、そもそもその場所に到達できなければ実害はない。

ここで4つ目に注目してほしい。単体では8.8で、上位3件より低い。しかし同じ管理基盤に複数の問題が同時に存在する以上、組み合わせによって影響が拡大する可能性は評価の対象になる。

ただし念のため書いておくと、**Cisco公式アドバイザリは、これらを組み合わせた具体的な攻撃連鎖を公表していない。**上の説明は、脆弱性の分類から論理的に想定される範囲であって、実証された攻撃手順ではない。深刻度の数値が個別評価であること、そして組み合わせの評価が別途必要になることを押さえておけば足りる。

この構造は、対応の判断に直結する。**「9.9の3件だけ先に直して、8.8は後回し」という部分適用は意味をなさない。**修正版へ上げれば全件が同時に解消されるため、選り分ける必要もない。逆に言えば、修正版の適用を先送りしている間は、5件すべてが同時に残り続ける。

「内部で見つけて公表した」ことをどう評価するか

今回のアドバイザリは、社内のセキュリティ強化レビューの過程で発見された脆弱性をまとめたものである。外部の研究者による指摘でも、攻撃を受けて発覚したものでもない。

この点は、ベンダーを評価する材料になる。自社製品を自ら精査し、悪用が始まる前に公表して修正版を出すという行動は、利用者にとって有利に働く。攻撃が観測されてから初めて公表されるより、対応の余裕が生まれるからだ。

一方で、利用者側にはひとつ責任が生じる。**ベンダーが先回りして情報を出しても、それを受け取る仕組みが自社側になければ、余裕は活かされない。**前述の質問7が重要なのはこのためである。アドバイザリが公開されてから自社が知るまでに数か月かかるなら、ベンダーが作った時間的余裕はそこで消える。

この観点は、次にネットワーク機器やソフトウェアを選ぶときの判断軸にもなる。価格と機能の比較に加えて、脆弱性情報をどう公表しているか、修正版の提供期間はいつまでか、通知を受け取る手段があるかを見る。導入時には見えにくいが、運用期間の長い機器ほど、この差が効いてくる。

対象かどうかは「製品名」ではなく「稼働バージョン」で決まる

Ciscoのアドバイザリは、影響を受けるリリースと、それぞれの修正版（First Fixed Release）を示している。公開されている情報では、修正版は次のとおりである。

**なお20.11、20.13、20.14、20.16はソフトウェアメンテナンス終了に達しており、Ciscoはサポート対象リリースへのアップグレードを推奨している。**表の修正版へ上げる場合も、その系統が今後もサポートされるかを合わせて確認する必要がある。

ここで実務上の問題が起きる。**多くの会社は、自社の機器が今どのバージョンで動いているかを把握していない。**導入時に決まったバージョンのまま数年動いていることも珍しくなく、その場合は表の一行目「20.9より前」に該当する。

古い系統で動いている場合、修正版へ上げるには複数段階のバージョンアップが必要になることがある。ここが今回の対応で最も時間を要する部分であり、かつ事前に分かっていれば計画を立てられる部分でもある。だからこそ、最初にやるべきは更新作業の手配ではなく、現在のバージョンの確認である。

修正版の入手には「有効なライセンス」が要る

もうひとつ、経営側が知っておくべき構造がある。**セキュリティ修正版のソフトウェアを入手するには、有効なライセンスが前提になる。**機器を買い切りで導入し、その後の保守契約を更新していない場合、脆弱性の存在は分かっても、通常のダウンロード経路を使えないという事態が起こり得る。

ただし**ここで対応を止めてはならない。**Ciscoは、有効なライセンスを持つ顧客が通常の窓口から無償の修正版を取得できない場合について、TAC（テクニカルアシスタンスセンター）へ製品のシリアル番号と該当アドバイザリのURLを提示し、無償アップグレードの権利を確認する手順を案内している。直接購入した顧客か、第三者経由で購入した顧客かによって窓口が異なるため、まずはこの確認を行う。

この確認を経てもなお修正版を入手できない場合、次のいずれかの対応になる。

1. サポート契約を再締結して修正版を入手する
2. 機器そのものを、サポート対象の新しい構成へ更新する
3. 該当機器の外部からの到達経路を遮断し、リスクを下げたうえで計画的に更新する

いずれも費用と時間が発生する。**そしてこの費用は、脆弱性が公表された今日に発生したものではなく、保守契約を更新しなかった時点から積み上がっていたものである。**ネットワーク機器の保守契約は、故障時の交換のためだけにあるのではない。セキュリティ修正を受け取り続けるための契約でもある、という理解が経営側に共有されているかどうかが、こうした場面で差になる。

保守委託先に確認する7問

自社にネットワーク機器を扱える人がいない場合、確認先はSIer、通信事業者、または機器を納入したベンダーになる。次の7問をまとめて投げると、状況が一度で把握できる。

1. 当社が使用しているCisco製品の一覧と、それぞれの現在の稼働バージョンを教えてほしい。
2. そのうち、2026年8月5日公開のCatalyst SD-WAN向けアドバイザリ、および同時期のIOS XE関連アドバイザリの対象になるものはあるか。
3. 対象がある場合、修正版へ更新する計画はいつか。実施にかかる時間と、拠点への影響（通信断の有無と時間）はどれくらいか。
4. 当社の保守契約は現在有効か。修正版のソフトウェアを入手できる状態か。
5. 当社との契約では、セキュリティ修正の適用は誰の責任範囲か。定期的な適用は契約に含まれているか、都度の依頼と個別見積になるか。
6. SD-WANの管理系コンポーネントは、インターネットから到達できる状態か。管理アクセスの制限はどうなっているか。
7. 今後、Ciscoのアドバイザリが公開された際、当社へ通知する仕組みはあるか。

**質問5と7が、今回だけで終わらせないための質問である。**5の回答が「都度の依頼」であれば、脆弱性が出るたびに自社が気づいて依頼しなければ何も起きない。7の回答が「特にない」であれば、次回も報道で知ることになる。この2点は、契約更新時の交渉項目にできる。

いつまでに直すかを、条件で決める

「早く直す」では日程が決まらない。自社の条件から期限を導く形にすると、社内でも委託先とも合意しやすい。判断の分岐は次のとおりである。

**この表の一行目に当たる会社は、更新より先にやることがある。**管理画面がインターネットから見える状態を、まず閉じることだ。これは今回の脆弱性の修正にはならないが、悪用の前提条件を減らす。そして本来、SD-WANの管理系が外部から到達できる必要があるケースは限られる。今回の確認をきっかけに、そもそもなぜ開いているのかを問い直す価値がある。

一方で、四行目の会社が陥りやすいのが、見積もりを取っている間に何もしないまま数か月が過ぎる状態である。暫定措置と恒久対策を並行させることを、依頼時に明示してほしい。「見積もりを待つ」は対応ではない。

更新作業の日までに、発注側が用意しておくもの

作業自体は委託先が行うとしても、発注側でしか用意できないものがある。ここが揃っていないと、当日に作業が止まるか、事後の確認ができない。

**影響を受ける拠点と業務の一覧。**通信が止まる時間帯に、どの拠点で何が動いているか。受発注、レジ、生産設備、電話（IP電話の場合）まで含めて確認する。委託先はネットワークの構成は知っていても、拠点の業務スケジュールは知らない。

**連絡体制。**作業中に想定外の事象が起きたとき、誰が判断するか。続行するか中止するかを決められる人が、作業時間帯に連絡の取れる状態にあるか。

**切り戻しの判断基準。**何がどうなったら中止して元に戻すのかを、事前に文章にしておく。当日に判断しようとすると、必ず「もう少し様子を見よう」に流れる。

作業後の確認項目。通信が復旧したことだけでなく、拠点間の特定の通信、外部サービスへの接続、監視の再開までを確認リストにする。「つながっているように見える」と「業務が回る」は違う。

**作業記録の受領。**実施日時、更新前後のバージョン、作業内容、確認結果を文書で受け取る。次回の対応時に、この記録が起点になる。

これらは特別なものではないが、揃えておくと当日の作業が短くなり、事後の「本当に直ったのか」という不安も残らない。

ネットワーク機器の棚卸しは、今回限りにしない

今回のアドバイザリ対応をきっかけに作っておくと、以後の脆弱性対応が大きく楽になる一覧がある。項目はこれだけでよい。

この一覧があると、次に脆弱性情報が出たときの初動が「委託先への問い合わせ」から「該当の有無の即時判定」に変わる。**判定が自社でできると、委託先への依頼が具体的になり、見積もりも早く出る。**逆に一覧がないと、毎回ゼロから調査が始まる。

一覧の作成自体は委託先に依頼できる。ただしその一覧を自社で保持しておくことに意味がある。委託先が変わっても、担当者が退職しても、情報は残る。表計算ソフト1ファイルで足り、更新は年に一度と、機器を追加したときだけでよい。作成に要する労力に対して、次の脆弱性対応で回収できる時間はそれを大きく上回る。

サーバーとネットワークで、対応の遅れ方が違う理由

最後に、構造的な話に触れておきたい。サーバーやパソコンのセキュリティ更新は、多くの会社で何らかの形で回っている。一方、ネットワーク機器の更新は止まりがちである。理由は担当者の怠慢ではなく、次のような構造にある。

**止められない。**更新中は通信が止まる。全拠点の業務に影響するため、日程調整のハードルが高い。

**触れる人がいない。**サーバーやPCと違い、設定を戻せる人が社内にいない。作業の失敗が通信断に直結するため、心理的な障壁も大きい。

**状態が見えない。**PCであれば管理ツールで一覧できるが、ネットワーク機器は個別に確認する必要があり、しかも確認する権限を委託先が持っている。

**壊れていないから、動いていると思われる。**通信ができている限り、経営からは正常に見える。脆弱性は業務に現れないため、優先順位が上がらない。

この4つは、今回のアドバイザリ対応が終わっても残る。だから対応の成果として残すべきは、更新したという事実ではなく、次に同じ情報が出たとき何日で判定できるかという体制のほうである。

よくある質問

Q. 自社はCiscoのSD-WANを使っていない。無関係と考えてよいか。 A. SD-WANを使っていなくても、Cisco製のスイッチやルータでIOS XEが動いている場合は、同時期に公開された他のアドバイザリの対象になる可能性がある。製品カテゴリではなく、自社にある機器の一覧で判定してほしい。

Q. 更新すると通信が止まる。業務への影響が大きい。 A. 影響時間は構成と機器によって異なるため、まず委託先に見積もりを求めるのが先である。冗長構成が組まれている場合、片系ずつ更新することで無停止に近い形が取れることもある。冗長構成の有無自体を把握していない場合、それも今回の確認事項に含まれる。

Q. 悪用が確認されてから対応する判断はあり得るか。 A. 選択としては存在するが、今回は回避策がないため、悪用が確認された時点で取れる手段は同じ「更新」しかない。しかもそのときは緊急作業になり、日程も費用も自社の都合では決められなくなる。同じ作業を、計画的にやるか緊急でやるかの違いになる。

Q. 拠点が全国に十数か所あり、一斉更新は現実的でない。どう進めるか。 A. 管理系のコンポーネントを先に更新し、拠点側は業務影響の小さい順に分割するのが一般的な進め方になる。ただし分割する場合、更新済みと未更新の機器が一定期間混在する。この混在状態で問題なく通信できるかを、委託先に事前確認しておく必要がある。ここを確認せずに分割を始めると、途中で通信不良が発生し、切り戻しの判断を迫られる。

Q. 保守委託先から「対象外です」とだけ回答が来た。これで十分か。 A. 不十分である。対象外という結論だけでなく、根拠となる稼働バージョンを添えてもらうこと。バージョンが分かれば、自社でもアドバイザリと照合できる。結論だけの回答は、後日誤りが判明したときに検証できない。この一手間を求めるかどうかで、委託先の管理精度も見えてくる。

Q. 機器を新しいものに入れ替えるほうがよいか。 A. 保守契約が切れており、かつ機器自体が古い場合は検討に値する。ただし今回の脆弱性への対応としては更新が最短であり、機器の入れ替えは数か月単位の計画になる。緊急対応と設備更新は分けて考えるべきである。

委託先の判断が妥当か確認したいとき

ネットワーク機器の脆弱性対応は、機器を扱える会社に依頼すれば作業自体は進む。難しいのは、その委託先の対応が妥当かどうかを、発注側が判断できないことにある。緊急だと言われれば緊急のまま受け入れ、様子見でよいと言われればそのまま止まる。

現在の構成と契約の状態を第三者の視点で確認し、優先順位と妥当な対応範囲を整理したい場合は、セキュリティ関連サービスから相談してほしい。継続的に脆弱性情報の追跡と適用判断を任せたい場合はセキュリティ保守・運用の継続支援、既に不審な通信や挙動が見えている場合はインシデント対応が該当する。

拠点ネットワークを含めたシステム全体の構成を見直す段階であれば、システム開発・DX推進の相談で、機器更新と業務システムの計画を合わせて整理できる。まず何から確認すべきかを相談したい場合は、お問い合わせから現状を知らせてほしい。

なお、機器そのものの世代交代やEoS/EoLを起点にした置換検討は、Cisco Catalyst・SD-WAN置換検討の判断手順で別途整理している。本稿は今回のアドバイザリへの対応と保守責任の所在に絞っている。

参照した情報

• Cisco Security Advisory「Cisco Catalyst SD-WAN Software Security Hardening Release: August 2026」（2026年8月5日公開、Security Impact Rating: Critical、CVE番号・CVSS値・修正版・回避策の有無）: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-hardening-sdwan-faLcR3K
• Cisco Security Advisory「Cisco Advance Notification for Publication of August 5, 2026, Security Advisories」: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-notice-L4XfJg8S
• Security NEXT「Cisco、アドバイザリ12件を公開 - 『Catalyst SD-WAN』『IOS XE』に深刻な脆弱性」（2026年8月7日）: https://www.security-next.com/188567

CVE番号、CVSS基本値、修正版、回避策の有無、悪用状況はCisco公式アドバイザリの記載に基づく。アドバイザリ12件という件数とIOS XE側の個別CVEについては上記報道に基づく二次情報であり、自社の対象判定にあたってはCisco公式アドバイザリおよび保守委託先の確認を優先してほしい。アドバイザリは追加情報の判明に応じて改訂されることがあるため、実際の更新作業の前に、その時点の版を再確認する必要がある。