Cisco Discloses Five Critical NX-OS Vulnerabilities: Unauthenticated Remote Flaws Can Lead to Full Root Takeover on Nexus Switches
Cisco has issued security advisories detailing five critical vulnerabilities in its NX-OS operating system. According to a BleepingComputer report, successful exploitation allows an attacker to execute arbitrary code with root privileges on Nexus switches. For network teams whose data centre backbones run on leaf-spine, VXLAN, or ACI architectures, this is a top-priority event rather than routine patching.
Three Remote, Two Local: Remediation Sequencing Matters
The BleepingComputer report describes the five flaws as falling into two categories: three can be triggered remotely without authentication, and two require an authenticated local session.
Unauthenticated remote flaws require no credentials to trigger — effectively exposing a root shell to any reachable host on the network. Once a public proof-of-concept surfaces or mass scanning picks the flaw up, compromise often happens within hours; these should be folded into a patch plan the same day and completed as quickly as possible. The authenticated local flaws carry comparatively lower risk but should still be addressed in the next maintenance window to avoid becoming a lateral-movement stepping stone in a larger attack chain.
One caveat worth flagging: the source report does not enumerate the CVE identifiers, CVSS scores, or the affected versions across NX-OS release trains. Because affected and fixed version ranges can differ per release train, administrators must cross-check Cisco's official advisory portal against the actual versions running on their hardware before scheduling.
Why This Is a "Risk Multiplier," Not an Ordinary Bug
Nexus switches serve as the trust root of the data centre fabric. A full root takeover lets an attacker intercept or rewrite north-south and east-west traffic, plant persistent backdoors, and move laterally across the fabric. Redundancy adds its own edge case: topologies such as vPC, stacking, or Fabric Interconnect mean a single-node compromise can cascade to the entire fabric rather than remaining an isolated incident.
This is a recurring pattern in the NX-OS codebase. The CDPwn vulnerability series, publicly disclosed in 2020, demonstrated that flaws in the Cisco Discovery Protocol layer alone could yield remote code execution on multiple Nexus switch models — spanning more than ten CVEs and affecting devices across multiple vendors. Today's advisory is the continuation of that class of risk, not an isolated event.
Management-Plane ACLs Are Not a Mitigation
The common practice of "tighten management-plane access first, defer patching" may not help here. If any of these five flaws can be triggered from the data plane or via neighbour-discovery protocols, restricting SSH or HTTP management access does not neutralise the risk. Management-plane ACLs are compensating controls only and do not substitute for patching. Any decision to defer must be documented as a formal risk-acceptance record with an assigned owner and a hard deadline.
Recommended Remediation Sequence (Editorial Guidance — Actual Timing Should Follow Each Organisation's Risk Assessment)
- Inventory: List every Nexus device and its running NX-OS version; cross-reference against the Cisco advisory.
- Prioritise by exposure: Address devices reachable from untrusted networks first, followed by Fabric Interconnect and spine nodes, then leaf switches.
- Plan the reboot: Control-plane restarts belong in a maintenance window; confirm redundant nodes can carry traffic during the window.
- Verify: After patching, confirm versions, check for configuration drift, and review for unexpected accounts.
- Harden: Narrow the management-plane exposure footprint and rotate relevant credentials.
Follow-Up Tracking
Environments running dual-site (production plus disaster-recovery) fabrics should verify that both sites run the same NX-OS release train — mismatched release trains can leave the DR site carrying the same unpatched flaws, so the maintenance window should cover both.
The source report does not mention any active exploitation (which is not to say updates will not appear later). Once CVE identifiers become available, register them for ongoing monitoring against the CISA Known Exploited Vulnerabilities (KEV) catalog and EPSS scoring; inclusion on KEV should be treated as the trigger for an emergency patching timeline.
Source: BleepingComputer, "Cisco warns of critical flaws allowing Nexus switch takeover" (published October 8).
Cisco 披露五個 NX-OS 重大漏洞：未經認證遠端缺陷可致 Nexus 交換器 root 權限全面接管
Cisco 已發布資安公告，詳細披露 NX-OS 作業系統中五個重大（critical）漏洞。根據 BleepingComputer 的報導，攻擊者一旦成功利用這些缺陷，即可在 Nexus 交換器上以 root 權限執行任意程式碼。對以 leaf-spine、VXLAN 或 ACI 架構搭建數據中心骨幹的網絡團隊而言，這屬於最高優先級事件，而非例行修補項目。
三個遠端、兩個本機：處置次序應有分別
BleepingComputer 的報導將五個漏洞描述為兩類：其中三個可在未經認證的情況下遠端觸發，另外兩個則需經認證的本機會話才能利用。
未經認證的遠端漏洞不需要任何憑證即可觸發——等於把 root shell 開放給網絡上任何可達的主機。一旦出現公開的 proof-of-concept（PoC），或被大規模掃描系統捕獲，系統失陷往往在數小時內發生；這類漏洞應即日納入修補計劃並盡快完成。需認證的本機漏洞風險相對可控，但仍應在下一個維護窗口處理，避免成為更大攻擊鏈中的橫向移動跳板。
有一點需要提醒：來源報導並未逐一列出五個漏洞的 CVE 識別碼、CVSS 評分，以及各 NX-OS release train 的受影響版本範圍。由於不同 release train 的受影響版本與修補版本範圍可能並不一致，管理員在排程前必須先到 Cisco 官方 advisory portal 核對公告，並確認硬件上實際運行的版本。
為什麼這是「風險倍增器」而非普通漏洞
Nexus 交換器是數據中心 Fabric 的信任根節點。一旦 root 權限被全面接管，攻擊者可以攔截或改寫南北向與東西向流量、植入持久性後門，並沿 Fabric 橫向移動。冗餘部署本身亦帶來額外風險：vPC、堆疊或 Fabric Interconnect 等拓撲結構，意味著單一節點失陷往往足以波及整個 Fabric，而非停留於孤立事件。
這是 NX-OS 代碼庫中的反覆出現的問題。2020 年公開披露的「CDPwn」漏洞系列已證明，僅憑 Cisco Discovery Protocol（CDP）協定層的缺陷，便足以在多款 Nexus 交換器上取得遠端代碼執行——該系列涵蓋十多個 CVE，影響範圍跨越多個廠商的網絡設備。今天的公告是同一類風險的延續，而非孤立事件。
管理面 ACL 不等於緩解措施
常見的「先收緊管理面存取、修補再押後」策略對這五個漏洞未必有效。若其中任何一個可經資料平面或鄰近發現協定觸發，限制 SSH 或 HTTP 管理入口並不能中和風險。管理面 ACL 只能視為補償性控制，不能取代修補本身。任何押後修補的決定，都應以正式的風險接受紀錄形式存檔，並指定負責人與明確死線。
建議處置順序（編輯建議，實際時限應按各單位風險評估調整）
- 盤點：列出所有 Nexus 設備及其運行的 NX-OS 版本，與 Cisco advisory 逐一核對。
- 按暴露度排序：優先處理對不受信任網絡可達的設備，其次是 Fabric Interconnect 與 spine 節點，再來是 leaf 交換器。
- 規劃重啟：控制平面重啟應安排在維護窗口內，並確認冗餘節點在窗口期間可承載流量。
- 驗證：修補後核對版本、檢查設定漂移，並覆核有無異常帳號。
- 加固：收窄管理面暴露範圍並輪替相關憑證。
後續追蹤
採用雙站點（生產站＋災備站）Fabric 架構的環境，應確認兩站點運行相同的 NX-OS release train——若 release train 不一致，災備站點可能仍帶有未修補的相同漏洞，維護窗口應涵蓋兩處。
來源報導未提及是否有針對這五個漏洞的活躍利用（不排除日後出現更新）。一旦取得 CVE 識別碼，建議將其納入持續監控，比對 CISA Known Exploited Vulnerabilities（KEV）目錄與 EPSS 評分；一旦被列入 KEV，即應視為觸發緊急修補時限的信號。
資料來源：BleepingComputer，〈Cisco warns of critical flaws allowing Nexus switch takeover〉（10 月 8 日刊出）。