Cisco Nexus 9000 の RCE 脆弱性｜対象機種別の対処

はじめに

2026 年 9 月 2 日、Cisco は Nexus 9000 Series Switches の Silicon One 統合に存在するリモートコード実行の脆弱性 CVE-2026-20212 を公表しました。CVSS 3.1 のベーススコアは 9.8 で、認証不要のリモート攻撃者が root 権限でコードを実行できる可能性があるとされています。

データセンターで広く使われている製品シリーズであるため、社内から「うちの Nexus は大丈夫か」という問い合わせを受けた方も多いと思われます。ただし今回の対象は Nexus 9000 全般ではなく、Silicon One ASIC を搭載した特定の製品識別子（PID）に限られます。逆に、インターネットへ直接公開していないことだけを根拠に影響なしと判断することもできません。

先に結論を示します。影響対象は Nexus 9000 全般ではなく、Silicon One ASIC を搭載した 10 種類の PID です。対象機では、認証を経ずに root 権限でのコード実行や、S1HAL プロセスのクラッシュによる機器のリロードにつながる可能性があります。完全な修正は Cisco Software Checker で確認した修正版への更新であり、更新までの間は iACL または Live Protect Shield を検討できますが、N9K-C9804 と N9K-C9808 は Live Protect Shield の対象外です。

本記事の内容は 2026 年 9 月 4 日時点で確認した公式情報に基づきます。Advisory は改訂される場合があるため、対応の実施前に最新版を確認することをおすすめします。

CVE-2026-20212 の概要と影響を受ける機種

まず Advisory の基本情報を整理します。2026 年 9 月 4 日時点で公開されているのは Version 1.0 のみで、Revision History にも初版公開の 1 行だけが記載されています。

TCP 43210／43211 が default L3 VRF から到達可能

Cisco の説明によると、この脆弱性は TCP の 43210 番ポートと 43211 番ポートが default の Layer 3 VRF からアクセスできる状態になっていることに起因します。攻撃者がいずれかのポートへ接続し、細工した入力を送信すると、その内容が root 権限のコードとして実行される可能性があります。

参考: Cisco Security Advisory cisco-sa-n9k-s1-rce-EH8dEtr
“could allow an unauthenticated, remote attacker to execute code with root privileges”
（認証されていないリモートの攻撃者が root 権限でコードを実行できる可能性があります）
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-n9k-s1-rce-EH8dEtr

影響はコード実行だけではありません。Cisco は、悪用の試行によって S1HAL プロセスがクラッシュし、機器がリロードする可能性にも言及しています。冗長構成であっても、両系に対象機を配置している環境では設計上の想定を超えた同時影響を受ける余地があるため、可用性の観点でも評価対象になります。

CVSS ベクターは攻撃元区分がネットワーク、攻撃条件の複雑さが低、必要な特権レベルとユーザー関与がいずれも不要という構成です。到達性さえ確保できれば成立し得るという評価になっており、ネットワーク側での到達性制御が重要な意味を持ちます。

悪用状況と発見の経緯

Cisco PSIRT は、Advisory 公開時点でこの脆弱性に関する公開情報や悪用を把握していないとしています。発見の経緯は、Cisco TAC のサポートケース対応の過程で見つかったものと記載されています。

CVE Record に付与された CISA-ADP の SSVC 評価では、Exploitation が none、Automatable が yes、Technical Impact が total とされています。2026 年 9 月 4 日時点で確認した範囲では、CISA の Known Exploited Vulnerabilities カタログへの掲載も確認できていません。悪用が確認されていないことは、対応を先送りしてよい根拠にはなりません。自動化が可能と評価されている点を踏まえると、到達性のある構成では優先度を上げる判断が妥当です。

Silicon One を搭載する 10 機種が対象

Advisory は、公開時点で Silicon One ASIC を搭載していた Nexus 9000 Series Switches の PID として次の 10 種類を挙げています。

• N9324C-SE1U
• N9348Y2C6D-SE1U
• N9364E-SG2-O
• N9364E-SG2-Q
• N9396T12C-SE1
• N9348Y12C-SE1
• N9396Y12C-SE1
• N9336C-SE1
• N9K-C9804
• N9K-C9808

Cisco は「公開時点で Silicon One ASIC を搭載していた PID」という書き方をしています。将来的に該当機種が追加される可能性を残した表現であるため、資産台帳と突き合わせる際は Advisory の最新版で一覧を確認することをおすすめします。

Cisco が影響対象外として挙げている製品

Advisory の Products Confirmed Not Vulnerable のうち、Nexus 系の運用担当者に関係する記載は次のとおりです。

• Vulnerable Products に記載された機種以外の Nexus 9000 Series Switches
• ACI モードで動作する Nexus 9000 Series Fabric Switches
• Nexus 3000 Series Switches
• Nexus 7000 Series Switches
• MDS 9000 Series Multilayer Switches

このほか、Firepower シリーズ、Secure Firewall シリーズ、UCS の Fabric Interconnect 群についても対象外として型番が列挙されています。全体の一覧は Advisory の Products Confirmed Not Vulnerable セクションで確認できます。

Advisory には、影響を受けると判明しているのは Vulnerable Products に記載された製品だけであると明記されています。列挙されていない製品を一律に安全と読み替えず、対象 PID に含まれるかどうかで判断することをおすすめします。

自環境が影響を受けるかを 4 軸で確認する

影響判定は、運用モード、PID、NX-OS リリース、到達性の順に切り分けると整理しやすくなります。前の軸で対象外と確定した場合、後続の軸を確認する必要はありません。

switch# show module

Mod Ports                  Module-Type                            Model           Status
--- ----- ------------------------------------------------ --------------------- --------
1    36   36x40/100G QSFP28 Ethernet Module                N9336C-SE1            ok

なお、対象機のポート待ち受け状態を機器上で確認するコマンドについて、Cisco はこの Advisory と関連ドキュメントで具体的な案内をしていません。他機種のコマンド体系から類推した確認手順は、意図しない結果につながる可能性があるため本記事では扱いません。判定は PID とリリース、ネットワーク側の到達性で行うことをおすすめします。

資産台帳と実機の対応付けを進める場合は、PID とシリアル番号の読み方を整理した関連記事『Cisco シリアル番号の確認コマンド｜show inventory 出力の見方』も参考になります。

アップグレード・iACL・Live Protect の使い分け

対象と判定された場合、選べる対応は 3 つです。位置づけが異なるため、同列に並べて比較しないことが重要になります。

iACL と Live Protect Shield は、いずれもアップグレードまでの時間を確保するための暫定対応です。Cisco も、回避策と緩和策は修正版へのアップグレードが可能になるまでの一時的な解決策であると位置づけています。暫定対応を適用したことをもって対応完了とせず、修正版への更新計画を並行して進めることをおすすめします。

修正版と推奨リリースを混同しない

NX-OS のバージョン選定では、意味の異なる 2 つの情報が混同されやすくなります。

First Fixed

Cisco Software Checker が、指定した Advisory とプラットフォーム、稼働リリースに対して返す修正済みリリースです。この脆弱性の修正版を判断する根拠になります。

Recommended Releases

機種ごとの一般的な推奨リリースをまとめた文書です。安定性や機能面を踏まえた推奨であり、個別の脆弱性の修正状況を示すものではありません。Advisory がより新しいリリースを案内している場合は、Advisory の指示に従うよう Cisco が明記しています。

あわせて、Live Protect Shield が提供されている 10.6(3) と 10.6(3s) を修正版と扱わないよう注意が必要です。これらは Shield を適用できるリリースであり、脆弱性そのものが修正されたリリースであることを意味しません。Release Notes に記載された「10.6(4) 以降へアップグレードすると Shield の operational mode が N/A になる」という挙動も、Shield の適用状態に関する説明であり、修正済みかどうかを示す情報ではありません。

iACL で TCP 43210／43211 を遮断する

Advisory が示す回避策は、iACL によって対象機宛ての必要な管理・制御通信だけを許可する方法、または、ローカルに設定された IP アドレス宛てで宛先ポートが 43210 と 43211 の TCP パケットを明示的に拒否する方法です。

参考: Cisco NX-OS Software Hardening Guide
“iACLs are one of the most critical security controls that can be implemented”
（iACL は、実装できるセキュリティ制御の中でも特に重要なものの 1 つです）
https://sec.cloudapps.cisco.com/security/center/resources/securing_nx_os.html

すでに iACL を運用している環境であれば、この脆弱性に対して追加する内容は次の 2 行の考え方に集約できます。ACL を新規に作成する例ではなく、既存の iACL へ挿入する概念例として示します。

deny tcp any <local-infrastructure-prefix> eq 43210
deny tcp any <local-infrastructure-prefix> eq 43211

この 2 行は、そのまま投入できる万能な設定ではありません。宛先は自機のローカルアドレス空間に置き換える必要があり、既存 ACL のどこに挿入するかによって効果が変わります。設計時に押さえておきたい点を整理します。

• 既存 iACL の評価順序を確認します。拒否行が既存の広い許可行より後ろに入ると、意図した遮断になりません
• BGP、OSPF、SSH、SNMP、NTP、syslog、TACACS+ など、機器の運用に必要な制御・管理通信を阻害しないことを確認します
• iACL は機器自身を宛先とするトラフィックを対象とする考え方です。ネットワークを通過するトラフィックの制御は tACL の役割であり、両者を混同しないようにします
• 適用位置は、IP アドレスを構成したインターフェースの受信方向が基本になります。信頼していない範囲と接するインターフェースに漏れがないかを確認します
• 送信元を限定できる設計であれば、any ではなくネットワーク設計に合わせた範囲に絞ります
• 信頼された送信元アドレスから攻撃が行われる場合、iACL では防ぎきれないと Hardening Guide に記載されています。内部からの侵害を想定した多層防御と組み合わせる前提で扱います
• Cisco 自身が、回避策の適用可否と有効性は各環境で判断すべきであり、事前評価なしに投入しないよう案内しています。本番投入前に適用位置と影響を確認します

Hardening Guide は、iACL 全般の注意事項として、非初期フラグメントが Layer 3 情報だけで評価される点を挙げ、フラグメントを ACL の先頭で明示的に扱う構成を案内しています。これは今回の脆弱性に固有の対策ではありませんが、iACL を新規に設計する場合は併せて検討する価値があります。

vPC を構成した環境では、片系ずつ保守を進める前提でアップグレードや ACL 投入の影響範囲を検討することになります。ピア間の整合性確認や ISSU の順序制約については、関連記事『Cisco Nexus 9000 vPC 設定のベストプラクティスと VSS との違い』で整理しています。

Live Protect Shield の適用条件と確認方法

Live Protect は、NX-OS に組み込まれた Tetragon エージェントと eBPF を用いて、カーネルレベルで CVE の補償的制御を適用する機能です。NXSecure という設定ツールで有効化と管理を行い、ソフトウェアのアップグレードやリブートを伴わずに緩和策を適用できる点が特徴とされています。

参考: Release Notes for NX-OS Live Protect Shield, Release 10.6(3)
“Live Protect shield is a temporary mitigation to bridge the gap until software updates”
（Live Protect shield は、ソフトウェア更新までの間をつなぐための一時的な緩和策です）
https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/106x/release-notes/release-notes-nxos-live-protect-shield-1063.html

10.6(3) と 10.6(3s) で対象機種と Shield File が異なる

CVE-2026-20212 向けの Live Protect Shield は、リリース別に 2 つの Release Notes が公開されています。Shield ID は共通ですが、対象機種と Shield File 名が異なります。

ここで押さえておきたいのが、N9324C-SE1U と N9348Y2C6D-SE1U は両方の Release Notes に記載されており、対象機種は排他的な関係ではないという点です。この 2 機種については、稼働しているリリースが 10.6(3) か 10.6(3s) かによって、適用する Shield File が変わります。逆に、残りの 6 機種は 10.6(3) 側の Release Notes にのみ記載されています。

作業前に Shield File 名を取り違えないよう、稼働リリースを確認したうえで該当する Release Notes を参照することをおすすめします。

N9K-C9804 と N9K-C9808 は Shield 非対応

10.6(3) の Release Notes には、N9K-C9804 と N9K-C9808 も脆弱性の影響を受けるが、これらのプラットフォームでは Live Protect Shield がサポートされないと明記されています。Security Configuration Guide のプラットフォーム対応表でも、Nexus 9500 と Nexus 9800 のスイッチは Live Protect 非対応と記載されています。

この 2 機種で選べるのは、修正版へのアップグレードか、iACL による到達性の制御です。Live Protect Shield を前提とした暫定対応計画を立てると、この 2 機種だけが未対応のまま残ります。対象機のリストを作る段階で、Shield 適用可否の列を分けておくことをおすすめします。

10.6(3s) の Release Notes は、対象 2 機種を挙げたうえで、それ以外の Nexus スイッチは影響を受けないという趣旨の記載になっています。この記載は Shield の適用範囲を示すものとして読み、脆弱性の影響範囲は Advisory の対象 10 PID を基準に判断することをおすすめします。

適用前に確認する前提条件

Security Configuration Guide には、Live Protect の利用にあたって次の条件が記載されています。

• NXSecure を有効化する前に、bootflash に 2 GB 以上の空き容量が必要です
• Release 10.6(2)F 以降、Live Protect の利用には NXOS_ESSENTIALS ライセンスが必要です
• 一部の対応機種では 24 GB 以上の RAM が条件です。対象 PID と稼働リリースに対応するプラットフォーム条件を個別に確認します
• application hosting、dockerbox、configuration replace、auditD の各機能とは併用できません
• enforce モードは Release 10.6(2)F 以降でサポートされます
• Release Notes には、Shield の展開に SSH、Telnet、NXAPI のいずれかのアクセスが必要と記載されています。Cisco は Hardening Guide で Telnet ではなく SSHv2 の利用を案内しているため、既存の SSH 経路を使う運用が現実的です

monitor モードでは悪用を遮断できない

Live Protect のポリシーには monitor と enforce の 2 つのモードがあります。monitor モードはイベントを検知して記録する状態であり、CVE-2026-20212 の悪用を遮断する状態ではありません。Live Protect Shield を暫定緩和策として機能させるには、最終的に show nxsecure policy status の Current が enforce であることを確認します。

一般的な Security Configuration Guide では、ポリシーを一時的に monitor モードで観察し、通常運用でヒットが発生しないことを確認してから enforce モードへ移行する進め方が案内されています。運用影響を先に見極めたい場合には有効な進め方です。

一方で、CVE-2026-20212 向けの Shield は、Release Notes の出力例で Original と Current がともに enforce として示されています。monitor モードで様子を見る運用を選ぶ場合、その期間は緩和が有効になっていない状態が続く点に注意が必要です。観察期間を設けるのであれば、enforce へ切り替える期日をあらかじめ決めておくことをおすすめします。

適用状態とヒットイベントを確認する

NXSecure の有効化は次のコマンドで行います。

switch(config)# feature nxsecure

ポリシーパッケージの追加と削除、導入済みパッケージの確認は、EXEC モードの次のコマンドで行います。

switch# nxsecure policy add <package> mode <mode>
switch# nxsecure policy remove <package>
switch# show nxsecure packages

適用後は、Shield が enforce 状態になっているかを確認します。次は Release Notes に掲載されている出力例です。

switch# show nxsecure policy status

Id      Name             Package                        Original Override Current Hits
lp00031 lps-sone-secure  lp00031.lps-sone-secure-v1.lps enforce  none     enforce 1

Original は Shield が本来定義しているモード、Override は運用側で上書きした設定、Current は実際に適用されているモードを示します。Hits が計上されている場合は、該当する事象が検知されていることを意味します。

ヒットイベントの詳細は、Shield ID を指定して確認します。

switch# show nxsecure log lp00031

出力には Policy Severity として CRITICAL、Policy Event として CVE-2026-20212 に対するヒットである旨が表示され、直近 20 件のイベント履歴が時刻、モード、プロセス名とともに並びます。Release 10.6(3)F 以降は syslog も出力され、%APPMGR-2-NXSECURE_CRIT_THREAT のメッセージとして記録されます。syslog サーバー側でこのメッセージを検知対象に加えておくと、監視に組み込みやすくなります。

アップグレードとダウングレード時の挙動

Release Notes には、Shield 適用後にリリースを変更する場合の挙動が記載されています。

• NX-OS 10.6(4) 以降へアップグレードすると、Shield の operational mode は N/A へ遷移します
• NX-OS 10.6(2) へダウングレードする場合、Shield は自動的には削除されません。ダウングレードの前に nxsecure policy remove で削除する必要があると記載されています

前述のとおり、operational mode が N/A になることは、その機器が CVE-2026-20212 について修正済みであることを示すものではありません。移行先リリースの修正状況は、あらためて Cisco Software Checker で確認することをおすすめします。

対応後に確認する項目

暫定対策とアップグレードのいずれについても、適用したことと効いていることは別の話です。選んだ対応ごとに、確認する内容を整理します。

iACL を適用した場合

BGP や OSPF の隣接関係、SSH による管理接続、SNMP ポーリング、syslog 転送が維持されていることを確認します。ACL の適用状況は show ip access-lists で確認します。エントリーごとのヒット数を表示するには、対象 ACL に statistics per-entry が設定されている必要があり、設定していない環境では ACE 単位のヒット数を確認できません。観測を開始する前にカウンタを初期化したい場合は、clear ip access-list counters を使用します。

あわせて、適用したインターフェースの一覧を記録し、後から追加したインターフェースに適用漏れが生じないよう管理します。

Live Protect Shield を適用した場合

show nxsecure policy status で Current が enforce になっていることを確認します。monitor のままでは検知と記録にとどまるため、緩和策としては機能しません。show nxsecure log lp00031 と syslog のヒットイベントは、通常運用による検知か実際の攻撃試行かを切り分ける材料になるため、継続的に確認します。

修正版へアップグレードした場合

更新後のリリース番号で Cisco Software Checker を再度照会し、この Advisory が該当しなくなったことを確認します。show module でモジュール構成が想定どおりに認識されているかも併せて確認します。Shield を適用していた機器では、アップグレード後の Shield の状態と、暫定対応として入れた iACL の拒否行を残すか外すかを判断します。

運用面では、対象機の一覧を PID、稼働リリース、Shield 適用可否、選んだ対応、実施予定日の列で管理しておくと、進捗と残りの作業が把握しやすくなります。Advisory が改訂されて対象 PID が変わる可能性もあるため、公開情報の再確認を計画に含めておくことをおすすめします。

まとめ

CVE-2026-20212 は CVSS 9.8 の深刻な脆弱性ですが、影響を受けるのは Silicon One ASIC を搭載した 10 種類の PID に限られます。運用モード、PID、NX-OS リリース、到達性の順に切り分ければ、自環境が対象かどうかは短時間で判断できます。対象と判明した場合は、修正版への更新を軸に据えたうえで、更新までの期間をどう埋めるかを機種ごとに決めていくことになります。

• 影響対象は Silicon One を搭載した Nexus 9000 の 10 機種
• ACI モードの Fabric Switch は Cisco が対象外として明記
• PID の確認は Advisory が案内する show module が起点
• 修正版の判断は Cisco Software Checker の First Fixed
• iACL と Live Protect Shield はいずれも暫定対応
• Shield の緩和効果は Current が enforce の場合に限定
• N9K-C9804 と N9K-C9808 は更新か iACL の二択

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