Cisco Nexus 9000に未認証RCE、該当は10型番

シスコは2026年9月2日（現地時間）、データセンター向けスイッチ「Cisco Nexus 9000シリーズ」の一部モデルに、深刻度「Critical」（CVSS基本値9.8）の脆弱性 CVE-2026-20212 を公表しました。認証を必要とせず、リモートからroot権限で任意コードを実行される可能性があります。

ただし影響を受けるのはNexus 9000のうち「Silicon One」ASICを搭載した10型番だけで、同シリーズでも他のモデルは対象外です。シリーズ名しか記録していない資産台帳では該当判定ができないため、まず自社機器の型番を確認することが最初の作業になります。

この記事でわかること

  • Nexus 9000とSilicon Oneが何であり、どこで動いているのか
  • CVE-2026-20212で何が起きるのか（未認証RCEと装置再起動）
  • 自社が該当するかを型番で判定する手順と、対象10型番の一覧
  • 「管理VRFはACLで守っている」が今回は効かない理由

Nexus 9000とSilicon Oneとは何か

Cisco Nexus 9000シリーズとは、データセンター内のサーバ間通信を担うシスコのスイッチ製品群です。サーバラック直上のToR（Top of Rack）スイッチや、それらを束ねるスパインスイッチとして使われ、業務システムが載る基盤そのものを支えています。運用はネットワーク担当が持つことが多く、情シスの台帳には「コアスイッチ」「DCスイッチ」としか書かれていないこともあります。一方のSilicon Oneは、シスコが自社開発したネットワーク処理用ASIC（専用チップ）で、同シリーズでも比較的新しい世代のモデルに搭載されています。

今回の脆弱性はNX-OS全体ではなく、このSilicon Oneをソフトウェアから扱う統合部分（S1HAL＝Silicon One Hardware Abstraction Layer周辺）にあります。したがって「Nexus 9000だから該当」でも「Nexus 9000だから非該当」でもなく、搭載チップ＝型番で該当かどうかが分かれます。慌てる前にも読み飛ばす前にも、まず型番を見るのが正解です。

何が起きたのか

シスコのアドバイザリによると、Silicon One統合においてTCPの43210番・43211番ポートがデフォルトのレイヤ3 VRFからアクセス可能な状態になっていました。このポートに到達できる攻撃者が細工した入力を送ると、認証を経ずにroot権限でコードが実行される可能性があります。

脆弱性の種別はCWE-1327「制限されないIPアドレスへのバインド」に分類されています。内部向けのはずのサービスが、結果的に外部から到達できるアドレスで待ち受けてしまっていた、という型の問題です。

もう一点、見落としやすいのが可用性への影響です。シスコは、悪用の試行によってS1HALプロセスがクラッシュし、装置全体が再起動する可能性があるとしています。コードを実行されなくても、攻撃を受けただけでスイッチが落ちる恐れがあるということです。データセンターのスパイン／ToRでこれが起きれば、通信断の影響は配下のシステム全体に及びます。

なお公表時点で、シスコPSIRTは本脆弱性に関する公開情報や悪用の報告を認識していないとしています。現時点では実際の攻撃が確認されたわけではありませんが、CVSS9.8かつ未認証という条件から、対応の優先度は高く置くべきです。

自社が該当するかをどう判定するか

シスコが影響を受けるとして挙げているのは、以下の10型番（PID）です。

分類 製品ID（PID）
固定構成スイッチ N9324C-SE1U / N9348Y2C6D-SE1U / N9336C-SE1
固定構成スイッチ（SE1系） N9396T12C-SE1 / N9348Y12C-SE1 / N9396Y12C-SE1
SG2系 N9364E-SG2-O / N9364E-SG2-Q
モジュラーシャーシ N9K-C9804 / N9K-C9808

判定は装置上で show module を実行し、表示されたPIDを上記と突き合わせます。一覧にないNexus 9000は影響を受けないとシスコは明言しており、ACIモードで動作するNexus 9000ファブリックスイッチも対象外です。Nexus 3000／7000、MDS 9000、Firepower／Secure Firewall各シリーズ、UCSも影響を受けないと整理されています。

修正版については、シスコは単一の「修正済みバージョン表」を出しておらず、Cisco Software Checkerで自機のリリースを個別に確認する案内になっています。台帳のバージョン情報が古いと空振りするため、実機から現行バージョンを取り直すのが確実です。

すぐに更新できない場合の暫定策として、シスコはiACL（インフラストラクチャACL）で宛先ポートTCP 43210・43211へのパケットを明示的に拒否する方法と、Live Protectのシールド適用を挙げています。いずれも恒久対策ではなく、更新までの時間稼ぎと位置づけてください。

「管理VRFはACLで守っている」が今回は効かない理由

ネットワーク機器の運用では、管理用インターフェース（mgmt0）を管理VRFに分離し、アクセスを踏み台サーバや管理セグメントに限る構成が定着しています。「機器の管理面は守れている」という安心の根拠がこれです。

しかし今回問題になっているのは管理VRFではなくデフォルトのレイヤ3 VRFで、これは通常フロントパネル側のL3インターフェース＝業務トラフィックが流れる側の経路に紐づきます。管理面を厳格に絞っていても、データ側から43210・43211番に到達できれば防御は成立しません。「管理セグメントを分けているから大丈夫」は今回に限っては誤った安心です。

現場目線の課題

正直なところ、この手のアドバイザリで一番つらいのは技術的な難しさではなく、「自社が該当するか」を確定させるまでの段取りです。

台帳には「Nexus 9000」までしか書かれていない。型番を確かめるには実機で show module を叩く必要がある。ところが対象はデータセンターのコアスイッチで、作業には申請と立ち会いが要る——という流れに見覚えのある方は多いはずです。判定作業そのものが社内手続きの都合で数日止まります。

43210・43211という高位ポートも厄介です。この番号を監視・遮断の対象として意識している組織はまず多くなく、「使っていないポートは塞いでいる」つもりでも広めのレンジが暗黙に通っていることがよくあります。加えて装置が再起動しうる以上、「コアスイッチが1台落ちたとき、どの業務が何分止まるのか」を経営層・利用部門に説明できるかも問われます。ここを即答できる組織は、実感としてそう多くありません。

情シスはどうすべきか

個別の手順を自前で並べるより、公的機関の指針に沿うほうが確実です。今回の性質では次の2つが役立ちます。

そのうえで、実務としては「対象10型番の保有有無を確定させる → 保有していればCisco Software Checkerで修正リリースを特定し更新計画を立てる → 更新までの間はiACLで43210・43211を遮断する」という順で進めるのが素直です。保有していないことが確認できたなら、その判定結果自体を台帳に記録しておくと、次に同種のアドバイザリが出たときに作業が繰り返しになりません。

ネットワーク機器の未認証RCEは近年繰り返し起きており、NVIDIAスイッチOSの脆弱性3件やUNIVERGE IX-Rの未認証RCEも構図は同じです。シスコ製品の対応履歴は8月19日公開分を、悪用に転じる流れはCISA KEV追加9件を参照してください。

まとめ

  • CVE-2026-20212はCVSS9.8の未認証RCE。デフォルトL3 VRFでTCP 43210・43211が待ち受けており、rootでのコード実行に加え、S1HALのクラッシュによる装置再起動の恐れもある。
  • 該当はSilicon One搭載の10型番のみ。「Nexus 9000だから該当／非該当」ではなく、show module でPIDを確認して判定する。ACIモードのファブリックスイッチは対象外。
  • 管理VRFの分離では防げない。問題はデータ側のデフォルトVRFにあるため、更新までの暫定策としてiACLで該当ポートを遮断する。修正版はCisco Software Checkerで個別に確認する。

出典

タイトルとURLをコピーしました