Cisco NX-OS: improper access control lets an unauthenticated attacker fully compromise the switch

CVSS 9.8CVE-2026-76455Firmware, BMC & network fabriccurated

Impact

An unauthenticated attacker with network reach to an NX-OS device gets full confidentiality, integrity and availability impact on the switch itself (CVSS 9.8, AV:N/PR:N/UI:N). On a GPU fleet the Nexus/ACI layer is the leaf-spine and often the storage and out-of-band path, so control of a switch means control of what crosses between tenants: VLAN and VRF boundaries, port mirroring, and the routes that carry NFS or object storage traffic. Cisco found this internally in a hardening review and published no mechanism, so there is no way to scope it more narrowly than "reachable on the management or data plane". The same bulletin covers Cisco UCS Managed, which is the server-side management path for the same racks.

Who can reach it

Anyone with network reach to an affected NX-OS device - no authentication and no user interaction. In practice that is anyone on the management VLAN, plus anyone on a data-plane segment the device terminates. Cisco does not say which interface or service is affected.

What to do

Upgrade to a fixed NX-OS release per the Cisco hardening bulletin (cisco-sa-hardening-nxosw1-cWzSbtR); Cisco publishes no workaround for this class. An NX-OS upgrade reloads the switch, so for a leaf pair this is a maintenance window per switch with traffic drained to the peer, and for a single-homed segment it is an outage. Until the upgrade, keep NX-OS management interfaces off any tenant-reachable network and restrict them to a jump path.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-76455 https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-hardening-nxosw1-cWzSbtR

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.