03.09.2026 om 17:52 Beveiligingsnieuws

Cisco Nexus 9000-kwetsbaarheid: code zonder login

Cisco heeft beveiligingspatches aangekondigd voor een kritieke Nexus 9000 kwetsbaarheid. Daarbij gaat het om een situatie waarin een aanvaller zonder authenticatie op afstand code kan laten uitvoeren met root-rechten. Volgens Cisco geldt het probleem voor specifieke Silicon One-gebaseerde Nexus 9000-switches.

Naast deze fout levert Cisco ook een IOS XR hardening release met meerdere kwetsbaarheden. In dit artikel zet ik de belangrijkste punten op een rij: wat er precies misgaat, wie het treft, en welke stappen je nu kunt nemen.

Wat is de Nexus 9000 kwetsbaarheid?

De kern van het probleem (CVE-2026-20212, CVSS 9.8) is volgens Cisco dat de software bindt aan een onbeperkt IP-adres. Daardoor blijven twee TCP-poorten (43210 en 43211) bereikbaar binnen de standaard Layer 3 VRF-instantie.

Wie de switch op één van die poorten kan benaderen, kan volgens Cisco direct verbinding maken met de getroffen service. Vervolgens kan de aanvaller zorgvuldig geconstrueerde input doorgeven, waarna de server die input als code uitvoert met root-toegang.

Daar komt nog bij dat een poging tot misbruik ook kan leiden tot een crash van het proces S1HAL en daarna een herstart van het apparaat.

Voor wie is deze fout relevant?

Cisco vermeldt dat de kwetsbaarheid zich richt op 10 Silicon One-based Nexus 9000 switches. In de advisory staan de volgende product identifiers (PIDs) die je kunt matchen via de output van show module:

N9324C-SE1U (Nexus Smart Switch)
N9348Y2C6D-SE1U (Nexus Smart Switch)
N9364E-SG2-O
N9364E-SG2-Q
N9396T12C-SE1
N9348Y12C-SE1
N9396Y12C-SE1
N9336C-SE1
N9K-C9804
N9K-C9808

Andere Nexus 9000-modellen vallen volgens Cisco niet onder de impact. Ook Nexus 3000 en 7000-lijnen en Nexus 9000 fabric switches die in ACI-modus draaien, worden als niet getroffen beschreven.

Geen workaround: Cisco geeft mitigaties

Belangrijk: Cisco meldt dat er voor geen enkele IOS XR-versie een workaround is. Voor de Nexus 9000 kant (NX-OS) zijn er wél stopgaps totdat je een vaste versie hebt.

Cisco geeft aan dat het op het moment van openbaarmaking (2 september) geen aanwijzingen heeft voor kwaadaardig misbruik. Wel publiceert Cisco geen vaste releasetabel in de publicatie zelf en stuurt het klanten naar de Software Checker.

Stopgap 1: iACL om poorten te blokkeren

Als tussenstap adviseert Cisco een infrastructure access control list (iACL) waarmee je de twee problematische poorten (43210 en 43211) blokkeert. Ook noemt Cisco de optie om alleen benodigde management- en control-plane verkeer toe te staan, en TCP-pakketten naar een lokaal geconfigureerd IP-adres op die poorten expliciet te weigeren.

Stopgap 2: Live Protect shield

Daarnaast is er een Live Protect shield (lp00031) die Cisco als tijdelijke mitigatie omschrijft. De ondersteuning is niet overal gelijk: het shield werkt alleen op NX-OS 10.6(3), en via een tweede shieldpakket ook op 10.6(3s) voor de twee Smart Switches.

Voor de Nexus 9804 en 9808 is het shield niet ondersteund. Bovendien vereist het shield toegang via SSH, Telnet of NX-API.

Wat moet je doen voor de echte fix?

Voor de definitieve oplossing moet je volgens Cisco upgraden naar de release die uit de Software Checker volgt. Cisco stelt daarbij ook dat de shield-release notes aangeven dat het operationele modusgedrag verandert bij upgrade naar NX-OS 10.6(4) of hoger.

Wie ISO XR gebruikt, krijgt een apart advies: upgrade naar een versie met software maintenance updates (SMU’s) en pas die vervolgens toe.

IOS XR hardening release: meerdere CVE’s, ook zeer hoge scores

Naast NX-OS pakt Cisco ook een grote bundel IOS XR hardening fixes aan. Cisco beschrijft dat de IOS XR hardening release kwetsbaarheden bij elkaar zet in één advisory, waarbij elk CVE gekoppeld wordt aan een CWE-bucket (Common Weakness Enumeration). De score wordt volgens Cisco bepaald op basis van het meest ernstige defect binnen die bucket.

Twee CVE’s krijgen daarbij de hoogste scorehoogte: zowel CVE-2026-20274 als CVE-2026-20279 hebben een plafond van 9.8. De eerste CVE richt zich op memory-safety en resource-lifetime issues. De tweede gaat over toeganggerelateerde problemen, zoals ontbrekende authenticatie voor kritieke functies en onjuiste certificate validation.

De overige vijf CVE’s (CVE-2026-20275 t/m CVE-2026-20278 en CVE-2026-20280) scoren lager, met plafonds tussen 8.2 en 8.8. Cisco zegt dat de kwetsbaarheden gelden voor alle IOS XR releases, ongeacht configuratie.

SMU’s: niet elke release krijgt hetzelfde pad

Voor IOS XR is de praktische aanpak complexer dan “updaten naar één nieuwe versie”. Cisco legt uit dat er in elke release mogelijk meerdere SMU’s beschikbaar zijn. Ook meldt Cisco dat toekomstige releases (zoals 26.2.2 en 26.3.1) de eerste fixed releases zouden zijn waarbij je geen SMU’s meer nodig hebt.

Voor klanten geldt: draai je een versie die buiten de tabel valt, dan adviseert Cisco om een Technical Assistance Center (TAC) case te openen.

De hardening advisory geeft daarnaast per functioneel gebied SMU-identifiers. Een belangrijk detail: voor alle XR7 (LNT) platforms is er een dedicated SMU die op alle releases van toepassing is (Cisco noemt hier CSCwv19790). Voor andere gebieden zoals BGP, crypto-ike, gRPC, IP-SLA, IS-IS en OSPF, MPLS/TE, multicast, OSPF/IS-IS en segment routing gelden specifieke SMU’s.

Tot slot: de Hacker News cross-check (op 3 september) stelt dat Cisco voor 111 IOS XR releases aangeeft dat deze mogelijk geraakt zijn, maar dat er voor sommige releases al SMU’s beschikbaar zijn, andere wachten op SMU’s en het merendeel eerst een upgrade nodig heeft alvorens je fixes kunt toepassen.

Gerelateerde context: waarom dit type issues urgent blijft

Deze release laat opnieuw zien hoe snel netwerkapparatuur onderdeel wordt van exploit-cycli: wanneer poorten ongefilterd openstaan, kan een kwetsbaarheid op afstand al toegang geven tot de kernprocessen. Wil je breder weten hoe misconfiguraties en kwetsbaarheden in infrastructuur ketens kunnen verergeren, dan is het nuttig om ook te kijken naar andere berichtgeving rond het beperken van exploit-oppervlak en misbruik van platformdiensten. Bijvoorbeeld:

Door zulke patronen te herkennen, kun je patchmanagement combineren met netwerkbeperking (zoals iACL’s) en het risico van onbedoelde exposure verkleinen.

Praktische checklist voor beheerders

Gebruik deze punten om snel te handelen:

Identificeer modellen en PIDs met show module en vergelijk met de door Cisco genoemde Nexus 9000 PIDs.
Check je NX-OS versie via de Cisco Software Checker voor de juiste upgrade-route.
Implementeer iACL als tijdelijke maatregel om 43210 en 43211 te blokkeren.
Beoordeel Live Protect alleen als je omgeving aan de vereisten voldoet (en ondersteuning voor jouw model klopt).
Voor IOS XR: upgrade naar releases met software maintenance updates en pas SMU’s toe waar nodig.
Documenteer je actie en zet een hercheck in je changekalender zodra Cisco fixed releases bevestigt voor jouw scenario.

Conclusie

De Nexus 9000 kwetsbaarheid die Cisco adresseert (CVE-2026-20212) is ernstig omdat een aanvaller zonder authenticatie via open poorten code als root kan laten uitvoeren. Voor getroffen Nexus 9000 switches is snel patchen de belangrijkste stap, terwijl Cisco ondertussen iACL-blokkades en (onder voorwaarden) een Live Protect shield als tijdelijke mitigaties aanbiedt.

Daarnaast is er voor IOS XR een brede hardening release met meerdere CVE’s, waaronder issues met een plafonds van 9.8. Door je huidige platformstatus te vergelijken met de advisories en de Software Checker/SMU-ondersteuning te volgen, verlaag je de kans op misbruik aanzienlijk.

Bron: https://thehackernews.com/2026/09/critical-cisco-nexus-9000-flaw-lets.html