Map the Feature Before You Patch
Cisco’s October NX-OS advisories cover five vulnerabilities whose exposure depends on the device, vulnerable software and enabled features. A successful exploit can run code as root or crash a process, potentially reloading the device and denying service. Map that exposure before choosing the patch path.
Treat this as a configuration decision, not a generic patch alert. Build the device-to-feature map first, then move each exposed branch towards a tested fix.
Cisco published the advisories in its 7 October 2026 release notice. The NX-API advisory’s 8 October revision changed only the fixed-release table. It was not a new vulnerability disclosure.
Start with the active feature
Record platform, operating mode, software branch and feature state for every switch. Do not let a fleet-level label replace evidence from the device.
CVE-2026-76471: the NX-API-enabled Nexus 3000/9000 standalone path is Critical and unauthenticated; NX-API defaults off. The UCS 6300 path instead needs valid low-privileged credentials through its XML API and is High. That API is enabled by default and cannot be disabled without losing functionality.
Keep the three NGOAM paths separate
The feature name is shared, but the exposure tests are not:
- CVE-2026-76485 requires NGOAM only.
- CVE-2026-76486 needs NGOAM plus SRv6 or NV Overlay; the latter also needs a VXLAN EVPN VNI on NVE with a learned VTEP.
- CVE-2026-76501 needs NGOAM plus SRv6. Nexus 3000 lacks SRv6; only some Nexus 9000 models support it.
That difference should drive the evidence request. Capture the relevant overlay, NVE, peer and SRv6 state instead of assuming that an enabled NGOAM flag proves every path.
Check MPLS OAM independently
CVE-2026-76465: Nexus 3000/9000 standalone with MPLS OAM enabled; defaults off. Silicon One cannot enable it.
Nexus 7000 and Nexus 9000 ACI mode are excluded. Cisco reported no public announcements or malicious use on 8 October 2026. That vendor observation is not proof of absence.
Use mitigation to buy a maintenance window
These advisories offer no workarounds. Disabling unused NGOAM or MPLS OAM removes the relevant vector but may disrupt operations. Live Protect shields are temporary. Use Cisco’s Software Checker for the exact NX-OS platform and installed release, then verify the corresponding advisory’s fixed-software guidance.
Update, 31 October 2026: separate the UCS fix from the switch check
The NX-API advisory’s UCS 6300 table lists 4.3(6j) as the first fixed UCS 4.3 release. UCS 4.2 and earlier must migrate to a fixed release. Keep that product-specific table separate from the NX-OS switch check.
The Software Checker’s own scope also matters: it compares releases against published advisories and does not account for enabled or disabled features. Its result cannot replace the device-level NGOAM, overlay, SRv6 or MPLS OAM evidence described above.
Make the maintenance plan explicit:
- Preserve the before-state: platform, mode, branch, enabled features and the configuration evidence behind every exposure decision.
- Separate temporary risk reduction from remediation. Give each disabled feature or shield an owner, expiry condition and rollback test.
- Select the fixed branch for the exact platform and current release, then test configuration compatibility and recovery before the window.
- After the upgrade, repeat the feature and reachability checks. Close the incident only when the deployed state matches the exposure record.
For background on the shielding model, see BlackTree’s Live Protect explainer. The current advisories remain the authority for coverage and fixed software.
