Die Kurzfassung
Ciscos NX-OS-Update vom Oktober 2026 schließt kritische Lücken, über die ein Angreifer Root-Rechte auf Nexus-Rechenzentrums-Switches, MDS-Storage-Switches und UCS Fabric Interconnects erlangen kann. Der NX-API-Fehler CVE-2026-76471 ist mit CVSS 9.8 bewertet und braucht keine Zugangsdaten, wenn die API aktiviert ist. Zusätzlich hat Cisco Dutzende intern gefundene Fehler zu sechs CVEs gebündelt, zwei davon mit 9.8. Bekannte Ausnutzung gibt es nicht, Workarounds ebenfalls nicht.
Für Software-Teams liegt der Haken in der Automatisierung. NX-API ist standardmäßig aus, wird aber oft eingeschaltet, damit Pipelines das Netz als Code konfigurieren können. Wenn Ihre Cloud- und DevOps-Werkzeuge VLANs, Routen oder Fabric-Änderungen auf Nexus-Switches ausrollen, ist genau diese Schnittstelle jetzt als Erstes zu patchen.
Was hat Cisco veröffentlicht?
Am 7. Oktober 2026 hat Cisco zwei Arten von NX-OS-Advisories veröffentlicht. Die erste ist klassisch: CVE-2026-76471, ein Heap-Überlauf in der NX-API, der HTTP- und JSON-RPC-Schnittstelle, über die Skripte und Controller einen Switch verwalten. Eine einzige präparierte Anfrage an eine erreichbare NX-API kann Code als Root ausführen. Auf UCS 6300 Fabric Interconnects ist derselbe Fehler über die XML-API des UCS Manager erreichbar, allerdings nur mit gültigen Zugangsdaten niedriger Berechtigung.
Die zweite ist in ihrer Form neu. Cisco nennt sie „Software Hardening Release“: Eine interne Prüfung fand viele Schwachstellen, und statt eines Advisories pro Fehler hat Cisco sie nach Schwachstellenklasse gruppiert und jeder Klasse eine CVE gegeben. Der Score jeder CVE entspricht dem schwersten Fehler darin. Laut Cisco wurden die Probleme mit den bestehenden Testprozessen „sowie Frontier-KI-Modellen“ gefunden. BleepingComputer und SecurityWeek nennen außerdem separate kritische Lücken in den Funktionen Next Generation OAM und MPLS OAM sowie kritische Fehler im On-Premises-Lizenzmanager von Cisco.
Welche Switches und Fabrics sind betroffen?
Das Hardening-Release umfasst MDS-9000-Storage-Switches, Nexus 3000 und 7000, Nexus 9000 im Standalone- wie im ACI-Modus, UCS Fabric Interconnects 6300 bis 6600 und den UCS X-Series Direct 9108 100G – unabhängig von der Konfiguration. In der Praxis betrifft das die meisten On-Premises-Rechenzentren und Colocation-Flächen mit Cisco-Hardware, einschließlich der Fabric unter VMware-, Kubernetes- und Storage-Clustern.
Das höchste unmittelbare Risiko besteht dort, wo eine Funktion die Angriffsfläche erweitert: NX-API ist aus einem Server- oder Automatisierungsnetz erreichbar, NGOAM wird mit SRv6- oder VXLAN-Overlays genutzt, oder MPLS OAM ist aktiv. Die korrigierten Releases stehen je Plattform im Cisco-Advisory; ältere Versionszweige wie NX-OS 9.3 auf MDS und 8.3 auf Nexus 7000 erhalten keinen Fix und müssen auf ein unterstütztes Release wechseln.
Was das für Software-Teams in den USA und der EU bedeutet
Erstens: Network-as-Code hat die Management-API zu einem Teil Ihrer Angriffsfläche gemacht. Werkzeuge wie Ansible und Terraform-Provider für NX-OS sprechen die Switches über NX-API an; die API wird also flottenweit aktiviert und für CI-Runner und Jump-Hosts geöffnet. Ein Root-Fehler ohne Anmeldung in diesem Pfad bedeutet: Ein kompromittierter Build-Agent oder ein flaches Management-VLAN kann zur Kontrolle über die Rechenzentrums-Fabric führen. Beschränken Sie NX-API auf dedizierte Management-Adressen und behandeln Sie Automatisierungs-Zugangsdaten und Runner als Tier-0.
Zweitens: KI-gestützte Fehlersuche verändert den Charakter von Patch-Tagen. Eine CVE steht jetzt für eine Klasse von Fehlern, nicht für einen einzelnen Defekt. Dashboards, die CVEs zählen oder Exploit-Signaturen abgleichen, unterschätzen den Aufwand. Cisco plant ähnliche Hardening-Releases für IOS XE, IOS XR, ASA und Secure Firewall, mit Veröffentlichungen jeweils am ersten und dritten Mittwoch im Monat. Planen Sie feste Wartungsfenster entlang dieses Kalenders, statt auf jedes Bündel einzeln zu reagieren.
Drittens: Ohne Workaround braucht es echte Downtime-Planung. Upgrades von Switches und Fabric Interconnects unterbrechen den Verkehr, sofern das Design nicht redundant ist. Für EU-Finanzunternehmen unter DORA und wesentliche Einrichtungen unter NIS2 ist die Fähigkeit, kritische Infrastruktur schnell zu patchen, ein Thema, nach dem Aufsichtsbehörden fragen. Dokumentieren Sie, was verwundbar war, wann es behoben wurde und warum ein Gerät warten musste.
Was bedeutet das für Rechenzentren im DACH-Raum?
Im DACH-Raum sitzen viele Nexus-Fabrics nicht im eigenen Keller, sondern in Colocation-Flächen großer Rechenzentrumsstandorte wie Frankfurt, Berlin, Wien oder Zürich – betrieben vom Kunden, aber mit eng getakteten Wartungsfenstern beim Provider. Wer dort Switches per Ansible oder Terraform verwaltet, sollte die Freigabe des Upgrades jetzt mit dem Colocation-Partner abstimmen, statt auf das nächste Quartalsfenster zu warten. In Deutschland erweitert die nationale Umsetzung von NIS2 den Kreis der Unternehmen mit Pflichten zu Schwachstellenmanagement und Meldewegen deutlich über die klassischen KRITIS-Betreiber hinaus; Warnungen von BSI und CERT-Bund gehören deshalb in denselben Alarmkanal wie die Cisco-Advisories.
Für Banken, Versicherer und Zahlungsdienstleister unter BaFin-Aufsicht kommt DORA hinzu: Ein unauthentifizierter Root-Fehler im Rechenzentrumsnetz ist genau die Art von IKT-Risiko, deren Behandlung bei Prüfungen nachvollziehbar sein muss. Ein sauberes Änderungsprotokoll mit Versionsständen vor und nach dem Upgrade spart später Diskussionen mit Prüfern.
Was ist jetzt zu tun?
- Die Flotte inventarisieren. Jeden Nexus-, MDS- und UCS-Fabric-Interconnect mit NX-OS- bzw. UCS-Release erfassen, auch Labor-, DR- und Colocation-Geräte, die selten Aufmerksamkeit bekommen.
- NX-API, NGOAM und MPLS OAM finden. Prüfen, auf welchen Geräten diese Funktionen aktiv sind und wer sie nutzt. Alles abschalten, was keine Pipeline und kein Controller tatsächlich braucht.
- Die Angriffsfläche verkleinern. NX-API per Access-Listen auf Management-Interfaces und bestimmte Quelladressen beschränken und die Zugangsdaten der Automatisierung rotieren. Den Live-Protect-Schutz nur als Überbrückung nutzen.
- In Wellen upgraden. Mit Geräten beginnen, die NX-API exponieren, dann den Rest der Flotte. Das Ziel-Release zuerst in der Automatisierungs-Pipeline testen, denn Module und Provider können sich nach großen NX-OS-Upgrades anders verhalten.
- Nachweise sichern. Versionsstände vor und nach dem Upgrade, Change-Tickets und das Datum der Behebung je Gerät aufbewahren – für Audits und spätere Fragen der Aufsicht, etwa im Rahmen von NIS2 oder DORA.
Häufige Fragen
Was ist CVE-2026-76471?
Ein Heap-Pufferüberlauf in der NX-API-Funktion von Cisco NX-OS mit CVSS 9.8. Ein nicht authentifizierter Angreifer kann eine präparierte HTTP-Anfrage an eine aktivierte NX-API auf einem Nexus-3000- oder Nexus-9000-Switch im Standalone-Modus senden und Code als Root ausführen. Auf UCS 6300 Fabric Interconnects ist der Fehler über die XML-API des UCS Manager erreichbar, erfordert dort aber gültige Zugangsdaten niedriger Berechtigung.
Ist NX-API auf meinen Nexus-Switches aktiviert?
NX-API ist auf Nexus-3000- und 9000-Switches standardmäßig deaktiviert. Häufig wird es eingeschaltet, damit Automatisierungswerkzeuge, Controller und Skripte den Switch über HTTP oder HTTPS verwalten können. Der Befehl „show feature | include nxapi“ zeigt auf jedem Gerät, ob die Funktion aktiv ist.
Was ist das Cisco NX-OS Hardening-Release?
Ein neuer Typ von Cisco-Advisory, veröffentlicht am 7. Oktober 2026. Cisco hat NX-OS intern mit bestehenden Tests und Frontier-KI-Modellen geprüft und die gefundenen Schwachstellen nach Klasse zu sechs CVEs gebündelt. Jede CVE trägt den Score des schwersten Fehlers ihrer Klasse; CVE-2026-76455 und CVE-2026-76459 sind mit 9.8 bewertet. Es gilt für betroffene Releases unabhängig von der Gerätekonfiguration.
Werden die Cisco-NX-OS-Schwachstellen ausgenutzt?
Laut Cisco sind Stand der Advisories vom Oktober 2026 keine öffentlichen Exploits und keine böswillige Nutzung bekannt. Workarounds gibt es nicht, daher ist ein Upgrade auf ein korrigiertes Release die einzige vollständige Abhilfe. Für den NX-API-Fehler hat Cisco einen temporären Live-Protect-Schutz bereitgestellt.
Welche NX-OS-Releases beheben die Schwachstellen?
Für Nexus 3000 und Nexus 9000 im Standalone-NX-OS-Modus nennt das Hardening-Release 10.3(10), 10.4(8), 10.5(6) und 10.6(4) als erste korrigierte Versionen. MDS 9000, Nexus 7000, Nexus 9000 im ACI-Modus und UCS Fabric Interconnects haben eigene korrigierte Versionen im Cisco-Advisory, und einige ältere Versionszweige müssen auf ein unterstütztes Release migrieren.
Quellen
Cisco — Cisco NX-OS Software Security Hardening Release: October 2026
Cisco — Cisco NX-OS Software NX-API Remote Code Execution Vulnerability (CVE-2026-76471)
Cisco — Transition to a Risk-Based Vulnerability Disclosure Model
BleepingComputer — Cisco warns of critical flaws allowing Nexus switch takeover
SecurityWeek — Cisco Patches a Dozen Critical Vulnerabilities