Map the Feature Before You Patch

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.

Advisories: 7 October 2026. NX-API 1.1: only an 8 October fixed-release-table update. Exploitation can run code as root.

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 low-privileged credentials through enabled XML API and is High.

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; Software Checker controls fixed releases.

Make the maintenance plan explicit:

1. Preserve the before-state: platform, mode, branch, enabled features and the configuration evidence behind every exposure decision.
2. Separate temporary risk reduction from remediation. Give each disabled feature or shield an owner, expiry condition and rollback test.
3. Select the fixed branch for the exact platform and current release, then test configuration compatibility and recovery before the window.
4. 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.