Cisco Critical NX-OS Flaws Allow Nexus Switch Takeover: Patching and Detection Guidance for SOC Teams

Cisco has disclosed critical-severity vulnerabilities in NX-OS, the operating system running its Nexus data center switch line, that can allow an attacker to take full control of an affected switch. As reported by BleepingComputer, the flaws affect multiple Nexus platforms and, in the worst case, give an attacker the ability to execute commands with elevated privileges on the underlying device. If your fabric runs Nexus 3000, 5000, 7000, or 9000 series gear, this is a patch-now event, not a patch-cycle event.

We are deliberately not going to parrot CVSS numbers or CVE IDs here without pointing you at the source: pull the specific identifiers and fixed-release tables directly from Cisco's Security Advisory page (cisco.com/go/psirt) and the BleepingComputer write-up, because Cisco's NX-OS advisories ship with platform-by-platform fixed-version matrices that matter more than any headline score. What matters operationally is the pattern: this is the latest in a steady drumbeat of NX-OS flaws where an attacker who reaches the management plane, or who already holds low-privilege credentials, ends up owning the box. Treat that pattern as the real story, because it has a history.

Why a Nexus Takeover Is Worse Than It Sounds

Most SOC teams think about network device compromise as an availability problem. It is not. A Nexus switch in your data center core or aggregation layer is a surveillance and pivot platform:

• Traffic visibility. SPAN/ERSPAN sessions, sFlow exports, and ACL counters all run through NX-OS. An attacker with config access can mirror east-west traffic to a collector they control without touching a single endpoint.
• Authentication control. Nexus switches typically participate in TACACS+/RADIUS. Owning the switch means the ability to add local accounts, weaken AAA fallback behavior, or redirect authentication flows.
• Persistence below your EDR's line of sight. There is no CrowdStrike or Defender for Endpoint agent on a switch. Forensics on NX-OS is limited to what syslog and accounting captured before someone cleared it.
• A credible in-the-wild precedent. In 2024, Sygnia disclosed that a China-nexus threat actor they track as Velvet Ant exploited an NX-OS command injection flaw (CVE-2024-20397) using valid admin credentials to escape the CLI sandbox and execute code as root on Nexus switches, then deployed a custom implant family (VELVETSHELL). That campaign demonstrated exactly the tradecraft to watch for: credential-driven access, privilege escalation on the device, and fileless-ish persistence in a blind spot.

So when Cisco says "critical" and "takeover" in the same advisory, read it as: someone can sit on your fabric, watch your traffic, and you will not see it from your endpoints.

What to Patch and How to Prioritize

First: Confirm Exposure

Before arguing about maintenance windows, answer three questions per device:

1. Is the device running an affected NX-OS release? Cisco's advisory includes a fixed-software checker. Use it. NX-OS trains differ between Nexus 3000/9000 and the older 5000/7000 lines, and end-of-support platforms may never get a fix.
2. Is the feature that carries the vulnerability enabled? Many NX-OS CVEs only bite when a specific feature (a particular protocol, the NX-API, guest shell, a specific line card behavior) is turned on. If the vulnerable feature is disabled, your risk drops sharply and you may be able to defer to the next window.
3. Who can reach the management plane? An unauthenticated flaw is terrifying if your OOB management network is flat and reachable from user VLANs. It is much less terrifying behind a hardened jump-host architecture. Exposure drives urgency more than the score does.

Prioritization Order We Recommend

Compensating Controls While You Wait for a Window

• Restrict management-plane reachability with control-plane policing (CoPP) and infrastructure ACLs: SSH/HTTPS/NX-API only from designated jump hosts and the monitoring stack.
• Disable what you do not use: no feature telnet, no feature bash-shell, no nxapi enable if NX-API is not part of your automation, and verify guest shell is not enabled on platforms that ship it.
• Enforce TACACS+ with command authorization and disable local fallback accounts where policy allows, or at minimum audit every local account this week.
• Confirm AAA command accounting and accounting to a remote collector are actually on. This is your forensic record after the fact. aaa accounting default should be logging commands to your TACACS+ server and syslog should be streaming off-box.

What Exploitation and Post-Exploitation Look Like in Logs

You will not catch memory-corruption exploitation in syslog. What you can catch is the behavior around it: credential use, config change, defense evasion, and staging. These are the highest-signal NX-OS behaviors to alert on:

• Local account creation or privilege change. Any username ... role network-admin in config-change or accounting logs outside a change window is a near-certain incident on a mature network.
• Log tampering. clear logging, clear accounting log, no logging server, or a sudden silence from a normally chatty switch.
• Shell escape. feature bash-shell, run bash, guestshell invocation. On a switch, almost nobody has a legitimate reason to drop to the Linux shell interactively outside of vendor TAC-guided work.
• Config exfiltration. copy running-config to TFTP/SCP/FTP destinations you do not recognize, especially to external IPs.
• New feature enablement. feature telnet, feature scp-server, feature sftp-server, SNMP community changes — classic persistence and access-widening moves.
• Authentication anomalies. Local logins when TACACS+ is the standard, logins from non-jump-host sources, or the VSHD config-change message (%VSHD-5-VSHD_SYSLOG_CONFIG_I) fired by an account that should not be touching that device.

All of this presumes your NX-OS syslog actually reaches your SIEM. In our assessments, network device log coverage is the most common blind spot we find — endpoints are fully onboarded to the EDR, and the switches forwarding all that traffic log to a buffer that wraps every few hours.

Detection Content

The following content assumes NX-OS syslog and AAA accounting records are forwarded to your SIEM, and that your management jump hosts are covered by your endpoint telemetry.

Sigma Rules

Three rules targeting the highest-signal NX-OS behaviors: account manipulation, shell escape, and log tampering.

---
title: Cisco NX-OS Local Admin Account Created or Modified
id: 7c2e9b41-3f6a-4d8e-9a1c-5b7d2e8f0a11
status: experimental
description: Detects creation or modification of a local user with network-admin privileges on Cisco NX-OS switches via syslog or AAA accounting records.
references:
  - https://attack.mitre.org/techniques/T1098/
  - https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/93x/security/configuration/guide/b-cisco-nexus-9000-nx-os-security-configuration-guide-93x.html
author: Security Arsenal
date: 2026/10/08
tags:
  - attack.persistence
  - attack.t1098
logsource:
  product: cisco
  service: syslog
detection:
  selection:
    - 'username '
    - 'network-admin'
falsepositives:
  - Legitimate account provisioning during approved change windows
level: high
---
title: Cisco NX-OS Shell Escape or Guest Shell Invocation
id: 2f8a1c63-9e4b-4a7d-b3f2-6c1d9e0a5b22
status: experimental
description: Detects enablement of bash-shell feature or invocation of bash/guestshell on Cisco NX-OS, consistent with CLI sandbox escape tradecraft used in NX-OS exploitation.
references:
  - https://attack.mitre.org/techniques/T1059/
  - https://www.bleepingcomputer.com/news/security/cisco-warns-of-critical-flaws-allowing-nexus-switch-takeover/
author: Security Arsenal
date: 2026/10/08
tags:
  - attack.execution
  - attack.t1059
  - attack.privilege_escalation
logsource:
  product: cisco
  service: syslog
detection:
  selection:
    - 'feature bash-shell'
    - 'run bash'
    - 'guestshell'
    - 'run guestshell'
falsepositives:
  - Vendor TAC-guided troubleshooting
  - Network automation platforms using guestshell for on-box scripting
level: high
---
title: Cisco NX-OS Log or Accounting Data Cleared
id: 91d4e7b0-2c5f-4a8e-8d6b-3f0a1c9e7d33
status: experimental
description: Detects clearing of logging buffers or accounting logs, or disabling of remote syslog, on Cisco NX-OS switches — a common defense-evasion step after device compromise.
references:
  - https://attack.mitre.org/techniques/T1562/001/
author: Security Arsenal
date: 2026/10/08
tags:
  - attack.defense_evasion
  - attack.t1562.001
logsource:
  product: cisco
  service: syslog
detection:
  selection:
    - 'clear logging'
    - 'clear accounting log'
    - 'no logging server'
    - 'no logging console'
    - 'no logging monitor'
falsepositives:
  - Operational log rotation tasks, which should use scheduled, documented workflows
level: high

Tune these against your change-management calendar. On a well-run network, account creation and log clearing on switches are rare enough events that each alert deserves human review.

KQL Hunt (Microsoft Sentinel)

This query hunts Syslog for the same behaviors plus config exfiltration and unexpected feature enablement across your Nexus estate. It assumes NX-OS syslog is collected via a Linux syslog forwarder into the Syslog table.

let Lookback = 14d;
let SuspiciousPatterns = dynamic([
  "username", "network-admin",
  "feature bash-shell", "run bash", "guestshell",
  "clear logging", "clear accounting", "no logging server",
  "copy running-config", "feature telnet", "feature scp-server",
  "snmp-server community", "VSHD_SYSLOG_CONFIG_I"
]);
Syslog
| where TimeGenerated > ago(Lookback)
| where Facility in ("local6", "local7", "auth", "authpriv") or ProcessName has_any ("VSHD", "vshd", "AAA")
| extend SyslogMsg = tostring(SyslogMessage)
| where SyslogMsg has_any (SuspiciousPatterns)
| extend Indicator = case(
    SyslogMsg has "network-admin", "local_admin_account",
    SyslogMsg has_any ("bash-shell", "run bash", "guestshell"), "shell_escape",
    SyslogMsg has_any ("clear logging", "clear accounting", "no logging server"), "log_tampering",
    SyslogMsg has "copy running-config", "config_exfiltration",
    SyslogMsg has_any ("feature telnet", "feature scp-server", "snmp-server community"), "feature_change",
    "config_change")
| where Indicator != "config_change" or SyslogMsg has_any ("network-admin", "snmp-server", "feature ")
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), EventCount = count(),
    SampleMessages = make_set(strcat(SyslogMsg), 5)
    by Computer, Indicator
| order by FirstSeen desc

Run it as a scheduled analytics rule at low threshold for local_admin_account, shell_escape, and log_tampering indicators — those three should essentially never fire benignly outside a change window.

Velociraptor VQL (Jump Host Hunt)

The switch itself is not a Velociraptor target, but your jump hosts are. If an attacker pivots through a management workstation to reach NX-OS devices, the evidence lives there. This artifact finds live network connections from Windows jump hosts to your Nexus management subnets on management ports, plus recently dropped config or firmware files that may indicate staging.

LET NexusMgmtRanges <= "10.90.0.0/16"

LET Conns = SELECT Pid, Name, Family, Type, Status,
       Laddr.IP AS LocalIP, Laddr.Port AS LocalPort,
       Raddr.IP AS RemoteIP, Raddr.Port AS RemotePort
FROM netstat()
WHERE Status =~ "ESTAB|LISTEN"
  AND RemotePort in (22, 23, 161, 443, 8443)
  AND RemoteIP =~ "^10\\.90\\."

LET DroppedFiles = SELECT FullPath, Size,
       Mtime AS Modified, Atime AS Accessed
FROM glob(globs=[
  "C:/Users/*/Downloads/*running-config*",
  "C:/Users/*/Downloads/*.cfg",
  "C:/Users/*/Downloads/nxos*.bin",
  "C:/Users/*/Desktop/*running-config*",
  "C:/Users/*/Documents/*.cfg"
])
WHERE Modified > now() - 1209600

SELECT * FROM Conns
UNION ALL
SELECT NULL AS Pid, "FILE:" + FullPath AS Name, NULL AS Family,
       NULL AS Type, "FILE_DROP" AS Status, NULL AS LocalIP,
       NULL AS LocalPort, FullPath AS RemoteIP, Size AS RemotePort
FROM DroppedFiles

Adjust the management subnet regex and globs to your environment. A TFTP or SCP client pulling running-config off a switch leaves a destination-side artifact on the host that initiated it — that host is where your investigation starts.

Audit Script: NX-OS Posture Check

This Bash script connects to each switch over SSH from a jump host, pulls posture-relevant config, and flags the specific conditions that raise exploitability or indicate compromise. It expects SSH key auth and a read-only audit account.

#!/usr/bin/env bash
# nxos-audit.sh — posture and compromise-indicator audit for Cisco Nexus switches
# Usage: ./nxos-audit.sh switches.txt audit_user
# Requires: ssh key auth to a read-only account on each device

SWITCH_LIST="${1:-switches.txt}"
AUDIT_USER="${2:-netaudit}"
OUTDIR="nxos-audit-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$OUTDIR"

run_cmd() {
  local host="$1" cmd="$2" outfile="$3"
  ssh -o BatchMode=yes -o ConnectTimeout=10 -o StrictHostKeyChecking=accept-new \
      "${AUDIT_USER}@${host}" "$cmd" > "$outfile" 2>/dev/null
}

while read -r SW; do
  [ -z "$SW" ] && continue
  echo "[+] Auditing $SW"
  D="$OUTDIR/$SW"; mkdir -p "$D"

  run_cmd "$SW" "show version"                          "$D/version.txt"
  run_cmd "$SW" "show users"                             "$D/users.txt"
  run_cmd "$SW" "show running-config | include username" "$D/local-accounts.txt"
  run_cmd "$SW" "show feature | include enabled"         "$D/features.txt"
  run_cmd "$SW" "show logging server"                    "$D/logging.txt"
  run_cmd "$SW" "show running-config aaa"                "$D/aaa.txt"
  run_cmd "$SW" "show snmp community"                    "$D/snmp.txt"

  echo "--- Findings for $SW ---"

  grep -Eqi 'telnet' "$D/features.txt" \
    && echo "  [HIGH] Telnet server feature enabled"
  grep -Eqi 'bash-shell' "$D/features.txt" \
    && echo "  [HIGH] bash-shell feature enabled (sandbox escape surface)"
  grep -Eqi 'nxapi' "$D/features.txt" \
    && echo "  [MED ] NX-API enabled — confirm it is restricted to automation sources"
  ! grep -Eqi 'aaa accounting default' "$D/aaa.txt" \
    && echo "  [HIGH] AAA command accounting not configured — no forensic trail"
  ! grep -Eqi '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' "$D/logging.txt" \
    && echo "  [HIGH] No remote syslog server configured — logs stay on-box"
  grep -Eiq 'public|private' "$D/snmp.txt" \
    && echo "  [CRIT] Default SNMP community string present"
  ACCTS=$(grep -c 'network-admin' "$D/local-accounts.txt")
  echo "  [INFO] Local network-admin accounts: $ACCTS (review $D/local-accounts.txt)"
  echo ""
done < "$SWITCH_LIST"

echo "[+] Audit complete. Raw output in $OUTDIR"

Run it before patching to establish a baseline, and again after. If bash-shell is enabled on a switch where nobody can explain why, that switch gets an incident review, not just a config fix.

Bottom Line

1. Pull Cisco's advisory and the fixed-release matrix today. Identify affected Nexus platforms, check whether the vulnerable features are enabled on each, and sequence patching by management-plane exposure — internet/DMZ-facing first, core second.
2. Lock down the management plane in the meantime. CoPP, infrastructure ACLs, jump-host-only access, and disabling telnet, NX-API, bash-shell, and guest shell where unused.
3. Fix your telemetry gap. If NX-OS syslog and AAA command accounting are not streaming off-box to your SIEM, you are blind to exactly the post-exploitation behavior that matters. This is the single highest-value detective control for network devices.
4. Deploy the detections above. Account creation, shell escape, and log clearing on switches are low-noise, high-severity alerts on any mature network.
5. Hunt the jump hosts. The endpoint side of the pivot is where your EDR and Velociraptor can actually see attacker movement toward the fabric.
6. Review local accounts and AAA fallback. Velvet Ant's NX-OS campaign ran on valid credentials. Patching closes one door; stolen admin credentials open another.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment Threat Intelligence Blog