CVE-2026-20212: Cisco Nexus 9000 Critical RCE (CVSS 9.8) — Detection and Remediation Guide

Cisco has released patches for CVE-2026-20212, a critical vulnerability carrying a CVSS score of 9.8 that allows an unauthenticated, remote attacker to execute arbitrary code with root privileges on affected Nexus 9000 Series switches. The flaw impacts 10 models of Silicon One-based Nexus 9000 platforms — the spine-and-leaf backbone of a significant portion of modern enterprise and cloud data centers.

Let me be blunt about why this matters: your data center fabric switches sit at the convergence point of virtually every workload you run. A root-level compromise on a Nexus spine or leaf is not a "network device issue" — it is full visibility into east-west traffic, a launchpad for lateral movement across segments that endpoint tooling never sees, and in many architectures, a path directly into management planes, storage networks, and out-of-band infrastructure. There is no EDR agent on your switches. For most organizations, network device telemetry is the blindest spot in the entire detection program.

If you operate Silicon One-based Nexus 9000 hardware, this is a patch-now event. Treat it with the same urgency you would a critical internet-facing RCE, because for any attacker who has achieved an internal foothold — or who can reach exposed management interfaces — that is exactly what it is.

Technical Analysis

What We Know

Affected Products

The vulnerability is specific to Nexus 9000 Series switches built on Cisco's Silicon One ASIC architecture. This is an important scoping detail: not every Nexus 9000 in your inventory is necessarily vulnerable. Silicon One-based models are the newer-generation platforms (commonly deployed as high-density 400G spine/leaf nodes), so your first action is inventory reconciliation — pull your chassis and ASIC identification from every Nexus 9K in the environment and cross-reference against Cisco's advisory for the definitive affected-model list.

How the Vulnerability Works — Defender's Perspective

While Cisco's advisory (disseminated through its Technical Assistance Center and security advisory channels) describes the flaw as enabling unauthenticated remote code execution with root privileges, the defensive-relevant facts are these:

1. No authentication is required. The vulnerable service or parser processes attacker-controlled input before any credential check. This class of flaw — pre-auth network-reachable code execution on infrastructure — is the highest-urgency category in network device security.
2. Code executes as root. On NX-OS, root means full control of the control plane: the ability to modify running configuration, install persistent implants, manipulate ACLs to blind security controls, mirror or redirect traffic (SPAN/ERSPAN abuse), and harvest credentials transiting management protocols.
3. Data center position amplifies impact. A compromised spine/leaf sees traffic that never touches an endpoint sensor. Attackers can stage lateral movement to management VLANs, vCenter, storage (iSCSI/NVMe-oF), and backup infrastructure.

Exploitation Status

At the time of Cisco's patch release, the vulnerability was addressed proactively through Cisco's advisory process. However, practitioners should assume the following realities:

• CVSS 9.8 unauthenticated RCEs on network infrastructure historically attract rapid reverse-engineering. Patch diffing of NX-OS images by sophisticated actors typically produces working exploits within days to weeks of disclosure.
• Network device implants are a documented nation-state and ransomware-affiliate TTP (MITRE ATT&CK T1602 — Network Boundary Bridging, T1542 — Pre-OS Boot / firmware persistence analogs on network devices).
• Monitor CISA's Known Exploited Vulnerabilities (KEV) catalog — if CVE-2026-20212 is added, federal deadlines apply and your internal SLA should compress accordingly.

Detection & Response

Network devices lack endpoint agents, so detection hinges on three telemetry sources: (1) switch syslog forwarded to your SIEM, (2) NetFlow/network metadata for management-plane traffic, and (3) configuration drift detection against a known-good baseline. The rules below target post-exploitation behavior, which is where detection fidelity is highest — an exploited switch must do something (execute commands, spawn shells, modify config, open connections), and those actions are observable.

Sigma Rules

The following rules assume NX-OS syslog is being ingested (via a syslog collector into your SIEM with Sigma-compatible field mapping). They target the highest-fidelity post-exploitation signals on network devices: unexpected interactive shell access, configuration modification from non-baseline sources, and anomalous local account activity.

---
title: NX-OS Unexpected Bash Shell or Root-Level Command Execution
id: 8f2b1c94-3a7e-4d51-bf29-6c1e5a0d8b34
status: experimental
description: Detects invocation of the underlying Linux bash shell or privileged feature enablement on Cisco Nexus switches. Post-exploitation of CVE-2026-20212 yields root context; attackers frequently drop to bash for tooling. Legitimate use of 'feature bash-shell' is rare and change-controlled in most environments.
references:
  - https://securityaffairs.com/198366/security/cisco-fixed-critical-rce-in-nexus-9000-series-switches.html
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/02/18
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  product: cisco
  service: nxos
detection:
  selection_keywords:
    Message|contains:
      - 'bash-shell'
      - 'run bash'
      - 'VSH_BIN_BASH'
      - '/bin/bash'
      - '/bin/sh'
  condition: selection_keywords
falsepositives:
  - Authorized engineering access to bash-shell during approved maintenance windows — suppress by source user and change ticket
level: high
---
title: NX-OS Configuration Change from Unapproved Source or User
id: 2c7d4e61-9b38-4f02-a815-7e3b9c1d5a62
status: experimental
description: Detects configuration commit events on Nexus switches originating from accounts or source addresses outside the approved automation/admin baseline. A root-level intruder via CVE-2026-20212 will modify configuration to persist, weaken ACLs, or enable remote access features (SNMP users, SSH keys, SPAN sessions).
references:
  - https://securityaffairs.com/198366/security/cisco-fixed-critical-rce-in-nexus-9000-series-switches.html
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/02/18
tags:
  - attack.persistence
  - attack.defense_evasion
  - attack.t1078
logsource:
  product: cisco
  service: nxos
detection:
  selection_change:
    Message|contains:
      - 'configured from'
      - 'configuration commit'
      - '%VSHD-5-VSHD_SYSLOG_CONFIG_I'
  filter_approved_users:
    User|contains:
      - 'admin'
      - 'netops_automation'
      - 'ansible_svc'
  condition: selection_change and not filter_approved_users
falsepositives:
  - Break-glass administrative access — investigate and confirm against change records
level: high
---
title: NX-OS Local Account Creation or SNMP Community Modification
id: 5a91e3f7-2d84-4c19-bb46-1f8a0c7e9d23
status: experimental
description: Detects creation of local user accounts or modification of SNMP communities on Nexus switches — a classic persistence and remote-access technique following network device compromise.
references:
  - https://attack.mitre.org/techniques/T1136/
  - https://attack.mitre.org/techniques/T1098/
author: Security Arsenal
date: 2026/02/18
tags:
  - attack.persistence
  - attack.t1136.001
logsource:
  product: cisco
  service: nxos
detection:
  selection:
    Message|contains:
      - 'username '
      - 'snmp-server community'
      - 'snmp-server user'
      - 'ssh key'
  condition: selection
falsepositives:
  - Legitimate provisioning via automation — tune by source and correlate to change management
level: medium

A note on tuning: the second and third rules depend on your environment actually logging configuration accounting (logging of VSHD events) and on you maintaining an approved-admin-user baseline. If you don't have that baseline today, building it is part of this remediation effort — it pays off far beyond this CVE.

KQL — Microsoft Sentinel / Defender

This query hunts Nexus syslog (ingested via CEF/Syslog into Sentinel) for exploitation-adjacent signals: repeated connection attempts against switch management services, shell invocations, and config changes. The anomaly component baselines connection volume per source — useful for catching pre-auth exploitation attempts that spray the vulnerable service.

// Hunt: Cisco Nexus 9000 post-exploitation & anomalous management-plane access (CVE-2026-20212)
// Requires NX-OS syslog ingestion via Syslog or CEF connector
let Lookback = 7d;
let Baseline = 30d;
// Part 1: High-fidelity post-exploitation syslog indicators
Syslog
| where TimeGenerated > ago(Lookback)
| where SyslogMessage has_any ("bash-shell", "/bin/bash", "run bash",
     "VSHD_SYSLOG_CONFIG_I", "snmp-server community", "username ")
| project TimeGenerated, Computer, HostIP, ProcessName, SeverityLevel, SyslogMessage
| sort by TimeGenerated desc;
// Part 2: Source IPs with anomalous connection volume to Nexus management/data-plane services
let NexusMgmtPorts = dynamic([22, 80, 443, 161, 830]);
let KnownSources =
    CommonSecurityLog
    | where TimeGenerated > ago(Baseline) and TimeGenerated <= ago(Lookback)
    | where DestinationPort in (NexusMgmtPorts)
    | where DeviceVendor == "Cisco" or DestinationHostName has "nexus" or DeviceName has "nexus"
    | summarize by SourceIP;
CommonSecurityLog
| where TimeGenerated > ago(Lookback)
| where DestinationPort in (NexusMgmtPorts)
| where DeviceVendor == "Cisco"
| where SourceIP !in (KnownSources)
| summarize Connections = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
    Ports = make_set(DestinationPort) by SourceIP, DestinationIP, DestinationHostName
| sort by Connections desc;

Analyst guidance: Part 1 results are investigate-immediately events. Part 2 surfaces novel source IPs touching switch services in the last 7 days that never appeared in the prior 30 — exactly the pattern you'd expect from an attacker pivoting to the fabric after an internal foothold.

Velociraptor VQL

Velociraptor does not run on NX-OS itself, but it does matter here for one reason: if the attacker reached your Nexus switches, they came from somewhere — typically a compromised jump host, Ansible/AWX controller, or admin workstation. This artifact hunts managed endpoints for evidence of interactive access to network devices from systems that shouldn't be originating it, plus dropped tooling commonly used in network-infrastructure intrusions.

-- Hunt: Endpoint-side indicators of network infrastructure intrusion (CVE-2026-20212 pivot hunt)
-- Targets admin workstations / jump hosts / automation controllers for suspicious
-- interactive sessions and tooling directed at Cisco Nexus management interfaces.

-- Part A: Processes with command lines referencing switch management access
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(nexus|nx-os|nxos)'
   OR CommandLine =~ '(?i)ssh .*(10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.|192\.168\.).*(admin|root|cisco)'
   OR Name =~ '(?i)(putty|plink|securecrt|teraterm)'

-- Part B: Live network connections from non-browser processes to common
-- network-device management ports on internal ranges
SELECT Pid, Name, Path, Status, Family, LocalAddress, LocalPort,
       RemoteAddress, RemotePort
FROM netstat()
WHERE RemotePort in (22, 23, 80, 443, 161, 830, 8300)
  AND Status =~ 'ESTAB'
  AND RemoteAddress =~ '^(10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.|192\.168\.)'
  AND Name !~ '(?i)(firefox|chrome|msedge|iexplore)'

Baseline this against your known automation controllers (Ansible, Nautobot, SolarWinds) — those will legitimately match Part B. Everything else matching Part A deserves a conversation with the account owner.

Bash — Inventory, Exposure Audit, and Verification Script

The fastest way to scope exposure is to interrogate the switches themselves. This script audits your NX-OS fleet for Silicon One platform identification (the CVE-2026-20212 affected population), current image version, and the exposure of potentially vulnerable services. Run it from a management host with SSH access and a device inventory list.

#!/bin/bash
# CVE-2026-20212 Nexus 9000 exposure audit — Security Arsenal
# Usage: ./nexus_cve_2026_20212_audit.sh inventory.txt
# inventory.txt = one switch management IP per line

INVENTORY="${1:-inventory.txt}"
SSH_USER="${NXOS_USER:-admin}"
OUT="nexus_audit_$(date +%Y%m%d_%H%M%S).csv"

echo "host,hardware_model,asic_family,nxos_version,ssh_enabled,http_enabled,snmp_exposed" > "$OUT"

while read -r HOST; do
  [ -z "$HOST" ] && continue
  echo "[*] Auditing $HOST ..."

  SHOW_VER=$(ssh -o ConnectTimeout=8 -o StrictHostKeyChecking=no \
    -o BatchMode=yes "${SSH_USER}@${HOST}" "show version" 2>/dev/null)

  if [ -z "$SHOW_VER" ]; then
    echo "$HOST,UNREACHABLE,,,," >> "$OUT"
    continue
  fi

  MODEL=$(echo "$SHOW_VER" | grep -i "cisco Nexus" | head -1 | awk '{print $3}')
  ASIC=$(echo "$SHOW_VER" | grep -iE "silicon one|Silicon One" | head -1)
  VERSION=$(echo "$SHOW_VER" | grep -i "NXOS" | head -1 | grep -oE "[0-9]+\.[0-9]+\([0-9A-Za-z]+\)" | head -1)

  RUN_CFG=$(ssh -o ConnectTimeout=8 -o BatchMode=yes "${SSH_USER}@${HOST}" \
    "show running-config" 2>/dev/null)

  SSH_STATE="disabled"; echo "$RUN_CFG" | grep -q "feature ssh" && SSH_STATE="enabled"
  HTTP_STATE="disabled"; echo "$RUN_CFG" | grep -qE "feature nxapi|ip http" && HTTP_STATE="enabled"
  SNMP_STATE="none"; echo "$RUN_CFG" | grep -q "snmp-server community" && SNMP_STATE="community-configured"

  SILICON_ONE="no"
  [ -n "$ASIC" ] && SILICON_ONE="POSSIBLE_S1_CHECK_MODEL"

  echo "$HOST,$MODEL,$SILICON_ONE,$VERSION,$SSH_STATE,$HTTP_STATE,$SNMP_STATE" >> "$OUT"
done < "$INVENTORY"

echo "[+] Audit complete: $OUT"
echo "[!] Next steps:"
echo "    1. Cross-reference MODEL column against Cisco's CVE-2026-20212 affected-model list"
echo "    2. Any 'community-configured' SNMP or 'enabled' HTTP/NX-API on affected models = restrict now"
echo "    3. Upgrade affected models to Cisco's fixed NX-OS release per the advisory"

Remediation

1. Patch — Primary Action

• Identify affected units: Only Silicon One-based Nexus 9000 models are in scope. Confirm your exact model numbers against Cisco's official security advisory (available via Cisco's Security Advisories portal at sec.cloudapps.cisco.com/security/center/publicationListing.x and referenced by Cisco TAC).
• Upgrade to the fixed NX-OS release specified in Cisco's advisory for your platform train. Cisco's advisory lists the first-fixed release per software train — do not assume your train's latest maintenance release is fixed without verifying against the advisory table.
• Validate post-upgrade: confirm image version (show version), verify boot variables point to the new image, and confirm ISSU/upgrade didn't strand the device on the old kickstart/system image pair.

2. Compensating Controls — If Patching Must Wait

There is no configuration workaround that eliminates an unauthenticated RCE, but you can compress the attack surface to near-zero for most environments:

• Strict management-plane ACLs (CoPP / control-plane policing): restrict which source addresses can reach any switch service. Your management plane should be reachable only from a dedicated, monitored jump host subnet.
• Disable unneeded services: NX-API/HTTP, Telnet (should already be off), and any non-essential listeners. Every disabled feature is one less reachable parser.
• Out-of-band management only: ensure management interfaces are on isolated OOB networks with no route from general user segments.
• SNMP hygiene: eliminate SNMPv1/v2c communities in favor of SNMPv3 with authPriv; restrict SNMP to polling station IPs via ACL.
• Segment the fabric: workload VLANs should have no L3 path to switch management addresses. Verify with a port scan from a representative user-segment host.

3. Verify Integrity — Assume Pre-Patch Exposure

If affected switches were reachable from any untrusted segment before patching, run a compromise assessment:

• Review local accounts (show user-account, show running-config | inc username) for additions you don't recognize.
• Check for unauthorized SSH keys, SNMP users, and SPAN/ERSPAN monitor sessions (show monitor session all) — traffic mirroring is a favorite post-exploitation persistence move.
• Audit syslog gaps. A missing window in centralized logging around the disclosure period is itself an indicator.
• Compare running-config against your configuration management backup (RANCID/Oxidized/Git). Any uncommitted drift gets investigated, not just reverted.

4. Telemetry — Permanent Improvement

This CVE is your forcing function to fix network-device monitoring:

• Forward NX-OS syslog at informational severity (minimum) to your SIEM — VSHD config events, login accounting, and AAA logs are where post-exploitation lives.
• Enable AAA command accounting to a TACACS+ server if you haven't.
• Deploy the Sigma/KQL detections above and alert on them.
• Add the switch fleet to your vulnerability scanner's authenticated scan scope — unauthenticated scans routinely miss NX-OS version detail.

5. Track KEV Status

Monitor the CISA Known Exploited Vulnerabilities catalog. If CVE-2026-20212 is added, CISA Binding Operational Directive timelines apply to federal agencies, and your internal remediation SLA should be treated as elapsed — move to emergency change immediately.

Closing Perspective

In 15 years of IR work, some of the most damaging intrusions I've led response on weren't prolonged by a failure on endpoints — they were prolonged by network devices nobody was watching. The attackers didn't need to evade EDR on the switch; there was nothing there to evade. CVE-2026-20212 is a 9.8, unauthenticated, root-yielding flaw on the backbone of your data center. Patch it, lock down the management plane, and use this as the catalyst to finally bring your network infrastructure into your detection program. The next one of these — and there will be a next one — will not wait for your change window.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub