Cisco IOS XE ハードニングリリース｜CVSS 9.8 の影響と対処

はじめに

2026 年 8 月 5 日、Cisco は IOS XE ソフトウェアのセキュリティハードニングリリースに関するアドバイザリ（cisco-sa-hardening-iosxe-V8NMuMZJ）を公開しました。Security Impact Rating は Critical、CVSS ベーススコアは 9.8 です。

このアドバイザリの扱いにくさは、スコアの高さそのものではありません。対象が「autonomous モードまたは controller モードで動作する IOS XE」であり、デバイスの設定内容に関係なく影響を受けるとされている点、そして回避策が提供されていない点にあります。特定の機能を無効化して急場をしのぐという、これまで多くの Cisco 脆弱性で採ってきた手段が使えません。

さらに、7 本の CVE が個別の脆弱性ではなく CWE カテゴリ単位でまとめられているため、従来と同じ読み方をすると影響範囲を見誤ります。これは Cisco が 2026 年 7 月から移行した新しい脆弱性開示モデルの適用結果であり、脆弱性管理の運用そのものに影響します。

結論を先に述べます。恒久対策は修正版リリース（17.9.10 / 17.12.8 / 17.15.6 / 17.18.4 または 17.18.4a / 26.1.2）へのアップグレードのみで、回避策は提供されていません。公開時点で悪用は確認されていないため、緊急の即時適用というより、計画的な停止枠の確保とアップグレード先の選定を優先する対応が現実的です。ただし CVSS 9.8 という数値は CWE カテゴリ内の最大値であり、個々の不具合の深刻度を示すものではないため、スコアをそのまま優先度に流し込む運用は見直しが必要になります。

2026 年 8 月 IOS XE ハードニングリリースの概要

本アドバイザリは、Cisco の IOS XE ソフトウェアエンジニアリングチームが実施した内部セキュリティレビューの結果として公開されたものです。外部からの報告や実際の攻撃を受けての公開ではなく、内部で発見した複数の不具合をまとめて修正した「ハードニングリリース」の告知という性格を持ちます。

7 本のアンブレラ CVE と CWE 分類の対応

アドバイザリでは、修正対象の脆弱性クラスが CWE 単位で 7 つに整理され、それぞれに 1 本の CVE ID が割り当てられています。

ここで押さえておきたいのは、この 7 本は「7 個の脆弱性」ではないという点です。各 CVE はカテゴリの傘（アンブレラ）であり、その配下に何件の不具合が含まれるかはアドバイザリに記載されていません。CVE 件数から修正規模を推し量ることはできない構造になっています。

なお、発見経緯として、既存のテストプロセスに加えてフロンティア AI モデルを用いた内部セキュリティテストによるものと明記されています。この「AI による発見の加速」が、今回のような大量まとめ型の開示につながっている背景です。この点は後述のセクションで詳しく扱います。

CVSS 9.8（CVE-2026-20272）が示す範囲と示さない範囲

アドバイザリのヘッダーに掲げられた CVSS 9.8 は、CVE-2026-20272（CWE-74）に対応する値です。ベクトル文字列は以下のとおりです。

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

未認証・リモート・ユーザー関与なしで CIA すべてに高影響という、最も警戒すべき組み合わせです。

ただし、この数値の読み方には注意が必要です。アドバイザリは、各 CVE に付与されたスコアが、そのカテゴリ配下で最も影響の大きい 1 件に基づく値であることを明示しています。

参考: Cisco Security Advisory（cisco-sa-hardening-iosxe-V8NMuMZJ）
“the maximum potential severity of the single most impactful underlying bug”
（配下で最も影響の大きい単一の不具合における、想定される最大の深刻度）
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-hardening-iosxe-V8NMuMZJ

つまり 9.8 は「CWE-74 カテゴリの中で最悪の 1 件がこの水準」という意味であり、同カテゴリに含まれる他の不具合も同じ深刻度であることを示すものではありません。同様に、8.6 が並ぶ他の CVE についても、配下の不具合すべてが 8.6 相当というわけではありません。

このスコアから読み取れないことも整理しておきます。

どの機能・プロトコルが攻撃面になるのか

従来のアドバイザリにあった「この機能が有効な場合のみ影響を受ける」という条件が示されていません。設定内容に関係なく影響を受けるとされているため、機能の有効・無効による絞り込みができません。

個々の不具合ごとの CVSS ベクトル

公開されているのはカテゴリ単位の最高値のみで、不具合単位の内訳は提供されていません。

緩和策の手がかり

攻撃面が特定できないため、ACL やインターフェース制限といった局所的な緩和策を設計する材料がありません。回避策なしと明記されているのは、この構造に由来します。

結果として、実務上の判断材料は「稼働バージョンが修正版に到達しているか」の一点に集約されます。従来の「該当機能を使っていないので影響なし」という判定プロセスが機能しない点が、今回のアドバイザリの最も大きな変化です。

なお、Cisco PSIRT は公開時点で、本アドバイザリに記載された脆弱性の公表事例や悪用を確認していないとしています。これは対応を先送りする根拠にはなりませんが、緊急のメンテナンス枠を無理に確保するより、次回の計画停止に合わせた適用を検討する余地があることを示しています。

影響を受ける製品と自機器の該当判定

本アドバイザリの該当判定は、機能の有効・無効ではなく稼働バージョンのみで決まります。ここでは対象範囲の読み方と、実機での確認手順を整理します。

評価対象となった 5 つのリリーストレイン

アドバイザリの記載によれば、今回の内部セキュリティレビューは IOS XE の 17.9、17.12、17.15、17.18、26.1 の 5 つのリリースを対象として実施されています。修正版リリースの一覧も、この 5 つのトレインに対応する形で提示されています。

ここで注意したい点が 2 つあります。

1 つ目は、上記 5 つ以外のトレインについて、アドバイザリは「影響がない」とは述べていないことです。記載されているのは、あくまで今回のレビューがこれらのリリースに焦点を当てて実施されたという事実です。17.3 や 17.6 といった旧トレインを運用している環境では、「一覧に載っていないから対象外」と読むのではなく、サポート状況を含めた別途の確認が必要になります。

2 つ目は、動作モードによる除外ができない点です。対象は autonomous モードまたは controller モードで動作する IOS XE とされており、設定内容にも依存しません。Catalyst 8000 シリーズや Catalyst 8000V などのプラットフォームでは、従来型の IOS XE 機能を使う autonomous モードと、Catalyst SD-WAN 環境で動作する controller モードを切り替えて運用しますが、今回はそのどちらであっても対象に含まれます。

なお、Catalyst SD-WAN 側にも同日付で別のハードニングリリース（cisco-sa-hardening-sdwan-faLcR3K）が公開されています。controller モードで運用している環境では、IOS XE 側と Catalyst SD-WAN 側の両方のアドバイザリを確認することをおすすめします。

Catalyst 3650 / 3850 が評価対象外である理由

アドバイザリには、Catalyst 3650 シリーズおよび Catalyst 3850 シリーズスイッチについて、これらのリリースを実行しないため今回のレビューの対象に含めなかった旨の注記があります。

読み違えを避けたいのは、これが「影響を受けないことが確認された」ではなく「評価していない」という意味である点です。実際、アドバイザリでは、これらの機種への影響が今後確認された場合は、Security Vulnerability Policy に沿って将来のリリースで修正するとされています。

Catalyst 3650 / 3850 が残存している環境では、本アドバイザリの対象外という理由で棚卸しの対象から外すのではなく、後続のアドバイザリを追跡する対象として扱うことを推奨します。

稼働バージョンの確認手順

実機での確認は、特権 EXEC モードの show version で行います。

Router# show version

参考: Release Notes for Cisco Catalyst 9300 Series Switches, Cisco IOS XE Dublin 17.12.x
“You can use the show version privileged EXEC command to see the software version”
（特権 EXEC の show version コマンドで、稼働中のソフトウェアバージョンを確認できます）
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-12/release_notes/ol-17-12-9300/upgrading_the_switch_software.html

動作モードもあわせて確認する場合は、以下のコマンドが利用できます。Catalyst SD-WAN Getting Started Guide に出力例が掲載されています。

Router# show version | include operating
Router operating mode: Autonomous

Router# show platform software device-mode
Operating device-mode: Autonomous

参考: Cisco Catalyst SD-WAN Getting Started Guide
https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/sdwan-xe-gs-book/install-upgrade-17-2-later.html

台数が多い環境では、構成管理ツールや NMS が保持しているバージョン情報を起点に、修正版に到達していない機器を抽出する方法が現実的です。今回のアドバイザリでは、機能設定による絞り込みが使えない分、バージョン情報の網羅性がそのまま棚卸しの精度になります。資産管理台帳と実機のバージョンに乖離がある環境では、この機会に突合しておくと以降のハードニングリリースへの対応が楽になります。

リスクベース開示モデルへの移行と脆弱性管理への影響

今回のアドバイザリの形式は、Cisco が 2026 年 7 月から適用しているリスクベース脆弱性開示モデルに基づくものです。この変更は、単なる表記の違いではなく、脆弱性管理プロセスの前提そのものに影響します。

CVE 単位のリスク評価が成立しなくなる理由

Cisco の公式ページでは、共通の CWE を持つ脆弱性を「アンブレラ」CVE ID に統合し、そのカテゴリ内で最も深刻なものに基づいて CVSS スコアを付与すると説明されています。ハードニングリリースは主要な NOS プラットフォーム（IOS XE、IOS XR、NX-OS、Secure Firewall、ASA）単位でまとめられ、修正ソフトウェアが提供可能になった後にアドバイザリを公開する方針も示されています。

従来の CVE 単位の運用では、次のような流れが成立していました。

1. CVE のベクトルと説明から攻撃面を特定する
2. 自環境で該当機能が有効かを確認し、影響の有無を判定する
3. 有効な場合は緩和策を設計し、恒久対策までの時間を稼ぐ
4. CVSS スコアと悪用状況から優先度を決める

アンブレラ CVE では、このうち 1 から 3 が機能しません。CVE が指すのは個別の脆弱性ではなく脆弱性クラスであり、配下の件数も攻撃面も公開されないためです。前述のとおり、CVSS スコアもカテゴリ内の最大値であり、そのまま優先度の入力値として扱うと実態から乖離します。

もっとも、CVSS ベーススコア単独でのトリアージに限界があること自体は、以前から指摘されてきた論点です。スコアが 4.3 の古い脆弱性が実際に悪用され KEV カタログに追加された事例については、関連記事『18 年前の Cisco IOS 脆弱性が KEV に追加された経緯と対処』で扱っています。スコアの高低にかかわらず、悪用状況や資産の露出度を組み合わせて判断する運用が、今回の変更でいっそう重要になります。

もう 1 つ押さえておきたいのは、低リスクの発見については個別のアドバイザリが発行されなくなるという方針です。Cisco は、低リスクの指摘を個別アドバイザリではなく、より簡素な開示で扱うとしています。「アドバイザリが出ていない＝修正すべき問題がない」とは読めなくなるため、定期的なハードニングリリースへの追随そのものが、脆弱性対応の基本動作になります。

社内の脆弱性管理プロセスで見直しが必要になる箇所

新しいモデルの下では、以下の 4 点が実務上の検討課題になります。

1. 対応期限ルールとの整合

「Critical は公開から 14 日以内」といった深刻度起点の SLA を運用している場合、四半期ごとのハードニングリリースと衝突する可能性があります。アンブレラ CVE のスコアは最悪ケースを示す値であるため、そのまま適用すると常に最短期限が発動し、計画的なメンテナンス枠の確保が難しくなります。深刻度ではなくリリースサイクルを軸にした期限設計への切り替えを検討する余地があります。

2. 脆弱性スキャナー・CMDB との突合

CVE 単位で消し込みを行う運用では、1 本の CVE が複数の不具合を束ねている状態を正しく表現できません。検出結果を「修正版バージョンに到達しているか」というバージョン基準の判定へ寄せることで、突合のずれを抑えられます。

3. 変更管理の前倒し

Cisco は、対象技術とプラットフォームを含む事前通知を、公開予定日の 7 日前に提供する方針を示しています。加えて、ハードニングリリースのアドバイザリは毎月第 1・第 3 水曜日の 16:00 UTC に公開される計画です。この予告を起点に、メンテナンスウィンドウ、検証環境での確認、承認プロセスを先に押さえておく運用へ移行できる点は、実務上の利点といえます。PSIRT の通知購読を有効にしていない場合は、この機会に設定を確認しておくとよいでしょう。

4. アップグレード方針の明確化

Cisco 自身のガイダンスは明確です。

参考: Cisco’s Transition to a Risk-Based Vulnerability Disclosure Model
“Customers are advised to upgrade immediately.”
（速やかなアップグレードが推奨されます）
https://sec.cloudapps.cisco.com/security/center/resources/risk-based-disclosure

ただし、実際の適用時期は自組織のリスク許容度、機器の露出度、停止可能な時間帯によって判断が分かれる部分です。今回のアドバイザリについては悪用が確認されていないため、無理な緊急対応よりも、直近の計画停止に合わせた確実な適用のほうが総合的なリスクは低いという判断も成り立ちます。

AI による脆弱性発見の加速という背景

この開示モデルの変更を促した要因として、Cisco は AI による脆弱性発見の急速な進展を挙げています。発見の量と速度が増した結果、従来のアドホックなパッチ運用では対応しきれなくなったという説明です。今回の IOS XE アドバイザリでも、発見手段として既存のテストプロセスに加えてフロンティア AI モデルを用いた旨が明記されています。

注目したいのは、この動きが防御側の道具立てにも及んでいる点です。Cisco の Foundation AI チームは、脆弱性特定（vulnerability localization）に特化した軽量モデル群を公開しており、ローカル環境で動作させられる小規模言語モデルとして提供されています。ベンダー自身が製品の脆弱性発見に AI を用いる一方で、その成果物を利用者側の脆弱性運用にも展開しようとする構図です。この取り組みの詳細は、関連記事『脆弱性特定に特化した Cisco の軽量 AI モデルの解説』で整理しています。

一方で、Cisco は攻撃側も AI を用いて exploit 開発を加速させるとの見方を示しており、ハードニングリリース以前のバージョンを使い続けるリスクは時間とともに拡大するとしています。

この主張の当否は今後の観測を待つ必要がありますが、実務上は「悪用が確認されていないので後回しにする」という判断の根拠が、以前より弱くなっている点は意識しておきたいところです。

修正版リリースへのアップグレード計画

回避策が提供されていないため、対応は修正版リリースへのアップグレードに一本化されます。ここでは適用先の特定方法と、計画立案で押さえておきたい点を整理します。

First Fixed リリースの確認と 17.18 系の表記

アドバイザリに記載された修正版は、前述の 5 つのトレインに対応する形で提示されています。このうち 17.18 については、17.18.4 と 17.18.4a の 2 つが First Fixed として併記されています。

一般に、IOS XE のリリース番号末尾に付く英字はリビルドリリースを示しますが、今回のアドバイザリには両者の使い分けに関する記載がありません。プラットフォームによって提供されるリリースが異なる可能性があるため、実際にどちらを適用するかは、Cisco Software Download Center で対象機種向けに提供されているリリースを確認したうえで判断することをおすすめします。この点について、本記事執筆時点では一次情報で明確な区別を確認できていないため、断定は避けます。

また、アドバイザリは公開後に改訂されることがあります。適用作業の直前に、最新版で影響製品や修正版の情報が変わっていないかを確認する運用を推奨します。

参考: Cisco Security Vulnerability Policy
“Cisco Security Advisories are point-in-time documents.”
（Cisco Security Advisory は、ある時点の情報を記載した文書です）
https://sec.cloudapps.cisco.com/security/center/resources/security_vulnerability_policy.html

Cisco Software Checker による確認

稼働バージョンが複数のトレインにまたがる環境では、アドバイザリの表を目視で突き合わせるより、Cisco Software Checker を使うほうが確実です。

参考: Cisco Software Checker
https://sec.cloudapps.cisco.com/security/center/softwarechecker.x

このツールでは、リリース番号を入力することで、そのバージョンに影響するアドバイザリと First Fixed リリースを確認できます。検索範囲は、特定のアドバイザリのみ、Critical と High の SIR を持つアドバイザリのみ、すべてのアドバイザリ、といった単位で切り替えられます。

実務上とくに有用なのが Combined First Fixed です。これは、該当したすべてのアドバイザリの脆弱性をまとめて解消する最も早いリリースを示す値です。今回のように同日に複数のアドバイザリが公開され、しかも今後は月 2 回のペースで公開が続く前提を踏まえると、個別のアドバイザリごとに適用先を決めるより、Combined First Fixed を基準にアップグレード先を 1 つに定めるほうが、作業回数を抑えられます。

なお、Software Checker は IOS XR ソフトウェアおよび中間ビルドを対象としていません。IOS XR を併用している環境では、別途アドバイザリの確認が必要になります。

回避策がない前提での停止枠の確保

対処がアップグレードに限られる以上、計画立案の質がそのまま対応完了までのリードタイムを左右します。

Cisco 製品のアップグレードにおける事前準備の考え方（バックアップの取得、リリースノートの既知不具合の確認、HA 構成のヘルスチェック、ロールバック時間を含めた作業時間の見積もり）は、関連記事『回避策が提供されない Cisco 製品でのアップグレード計画の立て方』で整理しています。製品は異なりますが、「回避策なし・恒久対策はアップグレードのみ」という構図は共通しており、そのまま応用できます。

IOS XE 固有の確認項目としては、以下が挙げられます。

リソースの事前確認

Cisco 自身も、アップグレード対象機器に十分なメモリがあること、現在のハードウェア・ソフトウェア構成が新しいリリースで引き続きサポートされることの確認を推奨しています。ブートフラッシュの空き容量は、イメージの追加時に不足しやすい項目です。

インストールモードの把握

install モードと bundle モードでは手順が異なります。事前にどちらで動作しているかを把握しておくと、作業手順書の分岐を減らせます。

冗長構成での適用順序

スタック構成や冗長スーパーバイザー構成では、切り替わりに伴う通信断の見積もりが必要です。所要時間は構成と機種に依存するため、検証環境での実測を推奨します。

アップグレードパスの確認

現行リリースから修正版へ直接アップグレードできるかは、機種とリリースの組み合わせによります。多段アップグレードが必要な場合、停止時間の見積もりが変わります。

アップグレード後の確認

適用後に show version でバージョンが修正版に到達していることを確認し、資産管理台帳へ反映します。前述のとおり、今回のアドバイザリではバージョン情報が唯一の判定材料になるため、台帳への反映漏れはそのまま次回の棚卸し精度に影響します。

前述の 7 日前の事前通知を活用すると、これらの準備を公開日より前に着手できます。ハードニングリリースが定期的に続く前提に立てば、四半期ごとの定例メンテナンス枠をあらかじめ確保しておく運用のほうが、都度の緊急調整より負荷が小さくなります。

同日公開の XMCP サービス妨害の脆弱性（CVE-2026-20301）

2026 年 8 月 5 日には、IOS XE のハードニングリリースと同時に、Cisco IOS ソフトウェアおよび IOS XE ソフトウェアの XMCP に関するサービス妨害の脆弱性も公開されています（cisco-sa-ios-xmcp-thbAr34t）。CVSS ベーススコアは 8.6、Security Impact Rating は High です。

ハードニングリリースとは異なり、こちらは影響条件が明確で、該当判定と緩和策の両方が可能です。同じ IOS XE を対象とするため、あわせて確認しておくと棚卸しを 1 回で済ませられます。

XMCP とは何か、有効になっている環境

XMCP（Extensible Messaging Client Protocol）は、Cisco SAF（Service Advertisement Framework）において External Client protocol とも呼ばれるプロトコルです。ルーターを XMCP サーバーとして構成し、SAF フォワーダーの外部にあるクライアントがネットワーク経由で接続するために使われます。

参考: Service Advertisement Framework Configuration Guide, Cisco IOS XE
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/saf/configuration/xe-16-7/saf-xe-16-7-book/saf-xmcp.html

公式の設定ガイドでは、XMCP クライアントの例として Cisco Unified Communications Manager が挙げられています。つまり、この機能が有効になっている環境は、SAF を利用した音声系の連携構成などに限られます。一般的なルーティング・スイッチング用途で有効化されているケースは多くないと考えられます。

なお、IOS XR ソフトウェアと NX-OS ソフトウェアは本脆弱性の影響を受けないことが確認されています。

該当判定

XMCP サーバー機能が有効かどうかは、以下のコマンドで確認できます。出力に service-routing xmcp listen が含まれる場合、機能が有効です。

Router# show running-config | include service-routing xmcp listen
service-routing xmcp listen
Router#

出力に何も表示されなければ、本脆弱性の影響は受けません。該当判定がこの 1 コマンドで完結する点が、ハードニングリリースとの大きな違いです。

この脆弱性は、細工された XMCP パケットの処理不備に起因し、未認証のリモート攻撃者が対象機器を予期せず再起動させられる可能性があります。アドバイザリでは、攻撃の成立に XMCP クライアントのユーザー名が不要である点が明記されています。

参考: Cisco Security Advisory（cisco-sa-ios-xmcp-thbAr34t）
“The attacker does not need the XMCP client username to exploit this vulnerability.”
（攻撃者がこの脆弱性を悪用するにあたり、XMCP クライアントのユーザー名は不要です）
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ios-xmcp-thbAr34t

認証情報を持たない攻撃者でも、XMCP のリッスンポートへ到達できれば攻撃が成立し得ることになります。到達経路の見直しが緩和策の中心になるのは、この性質によります。

allow-list による緩和策

本脆弱性にも回避策は提供されていませんが、接続元を制限する緩和策がアドバイザリに提示されています。XMCP の allow-list 機能で、指定した ACL に一致するクライアントのみ接続を許可し、それ以外を拒否する構成です。

アドバイザリに掲載されている設定例は以下のとおりです（ホスト 192.168.1.1 のみ接続を許可する例）。

service-routing xmcp listen
 allow-list ipv4 XMCPClientListIPv4
 client username test_xmcp password 
!
ip access-list extended XMCPClientListIPv4
 permit tcp host 192.168.1.1 any

適用にあたっては、以下の点に留意が必要です。

接続中のクライアントへの影響

XMCP のクライアント設定を変更すると、その設定を使用して接続しているクライアントが切断され、再接続が必要になる場合があります。SAF 連携を行っている環境では、影響範囲を事前に確認することを推奨します。

自環境での検証

Cisco は、この緩和策がテスト環境で有効性を確認したものであるとしたうえで、実際の環境における適用可否と効果は利用者側で判断すべきものとしています。導入前の評価をおすすめします。

恒久対策はアップグレード

緩和策はあくまで暫定措置です。修正版リリースは Cisco Software Checker で確認できます。

XMCP を利用していない環境では、allow-list による制限よりも、機能そのものを無効化しておくほうが攻撃面を確実に減らせます。使用していない管理系・制御系サービスを標準構成の段階で無効化しておく設計は、この種の脆弱性が公開されるたびの個別対応を減らすことにつながります。

まとめ

2026 年 8 月の IOS XE ハードニングリリースは、CWE 単位で束ねられた 7 本の CVE により、広範な IOS XE リリースを対象とする内容です。回避策は提供されず、機能設定による除外もできないため、判断材料は稼働バージョンのみに絞られます。個別 CVE への対処というより、Cisco のリスクベース開示モデルを前提に脆弱性管理の運用そのものを見直す契機として捉えるのが実務的です。

• 7 本の CVE は CWE カテゴリ単位のアンブレラ型
• CVSS 9.8 はカテゴリ内の最大値という位置づけ
• 対象は 17.9 / 17.12 / 17.15 / 17.18 / 26.1 の 5 トレイン
• 回避策なしで恒久対策は修正版へのアップグレードのみ
• 該当判定は機能設定ではなく稼働バージョンで実施
• 事前通知と定期公開を前提とした定例メンテナンス枠の確保
• XMCP の脆弱性は 1 コマンドで該当判定が可能

以上、最後までお読みいただきありがとうございました。