Für die Nexus-Lücke hat Cisco keine Tabelle mit korrigierten Versionen veröffentlicht, sondern verweist Kunden auf den hauseigenen Software Checker. Als Übergangsmaßnahmen nennt der Hersteller eine Infrastruktur-Zugriffsliste (iACL), die die beiden Ports blockiert, sowie einen zeitlich befristeten Live-Protect-Schutz.
Betroffene Produkte lassen sich anhand der im Advisory gelisteten Produkt-IDs gegen die Ausgabe des Befehls show module abgleichen. Andere Nexus-9000-Modelle, Nexus-9000-Fabric-Switches im ACI-Modus sowie die Baureihen Nexus 3000 und 7000 sind nicht betroffen. The Hacker News bestätigte am 3. September anhand des Eintrags im CVE-Programm, dass Cisco 45 NX-OS-Releases von 10.3(1) bis 10.6(3s) als verwundbar führt — eine Angabe, die das Advisory selbst dem Software Checker überlässt.
Die IOS-XR-Veröffentlichung folgt Ciscos risikobasiertem Offenlegungsmodell: Jeder CWE-Kategorie behobener Fehler wird eine CVE zugewiesen, bewertet nach dem schwerwiegendsten Defekt in dieser Kategorie. CVE-2026-20274 deckt Speichersicherheits- und Ressourcenlebensdauer-Fehler ab, CVE-2026-20279 Zugriffskontrollprobleme einschließlich fehlender Authentifizierung kritischer Funktionen und mangelhafter Zertifikatsprüfung; beide erreichen im jeweiligen Eintrag den Höchstwert 9.8. Die übrigen fünf — CVE-2026-20275 bis 20278 sowie CVE-2026-20280 — liegen zwischen 8.2 und 8.8.
Kunden sollen zunächst auf ein Release wechseln, das Software Maintenance Updates (SMUs) enthält, und diese anschließend einspielen; das gilt ausdrücklich auch für IOS XR7 (LNT). Für die XR7-Plattformen — Cisco 8000 Series, NCS 1010, NCS 540L und NCS 5700 Series — gibt es ein dediziertes SMU, das über alle Releases hinweg greift. Laut Cisco stehen “etwa 16 SMUs pro Release” bereit; die künftigen Versionen 26.2.2 und 26.3.1 sollen die ersten Releases sein, die ohne SMUs auskommen. Wer ein Release außerhalb der Tabelle betreibt, soll einen TAC-Fall eröffnen. CSCwv19171 gilt laut Cisco sowohl für IS-IS als auch für OSPF.
Ein Abgleich der sieben CVE-Einträge mit dem Advisory durch The Hacker News am 3. September ergab: Von 111 als betroffen gelisteten IOS-XR-Releases haben 14 bereits SMUs, vier warten darauf, und 93 müssen zunächst aktualisiert werden, bevor ein Fix greifen kann. SMUs als künftige Releases sind für 24.1.2, 24.3.2, 25.1.2 und 25.2.2 vermerkt.
“Zugleich hat sich das Zeitfenster zwischen Offenlegung und Ausnutzung faktisch geschlossen”, schrieb Russ Smoak, Vice President für Informationssicherheit bei Cisco, in einem Blogbeitrag im Juni, mit dem das zweimal monatliche Offenlegungsmodell angekündigt wurde. Die Veröffentlichung vom 2. September ist die dritte planmäßige Härtungsrunde binnen 30 Tagen — nach der ersten am 5. August mit IOS XE und einem Catalyst-SD-WAN-Release sowie zwei Veröffentlichungen mit CVSS 10.0 für Crosswork und Secure Workload zwei Wochen später.
Gesondert behandelt Cisco zwei öffentlich bekannte S/MIME-Entschlüsselungsfehler in Secure Email, CVE-2026-20354 und CVE-2026-20355 (CVSS 5.9). Sie erlauben einem Angreifer in der Mitte, Klartext aus Mails zwischen Gateways mit AsyncOS 16.5.0 oder älter und konfiguriertem S/MIME zu rekonstruieren; korrigierte Versionen nennen nur die Bug-Einträge. Ebenfalls behoben wurde ein Denial-of-Service-Fehler bei Telefonen (CVE-2026-20281, CVSS 7.5) in Desk Phone 9800, IP Phone 7800 und 8800 sowie Video Phone 8875, sofern sie am Unified Communications Manager registriert sind und Web Access aktiviert ist — eine standardmäßig abgeschaltete Einstellung. Fixes kommen je nach Modell mit SIP Software 5.0(1), 14.4(1)SR3, 14.4(1)SR4 oder 11.0(6)SR8.
Sechs Tage zuvor hatte Sygnia berichtet, der China-nahe Akteur Fire Ant, erstmals 2025 dokumentiert, habe eigens entwickelte Implantate auf IOS-XR-Routern betrieben. Diese unterdrückten die Syslog-Zustellung, filterten die Ausgabe von show-Befehlen und unterstützten einen verborgenen GRE-Tunnel. Der Akteur zeichnete zudem Pakete auf, lud sie auf externe FTP-Server und führte Verbindungsversuche und Portscans gegen angeschlossene Systeme kritischer Infrastruktur durch. Ausgangspunkt der Untersuchung war ein aktives Tunnel-Interface auf einem Router, das weder durch die laufende Konfiguration noch durch die Commit-Historie erklärbar war — ein Hinweis darauf, dass dem Betriebszustand des Geräts “nicht länger vertraut werden konnte, dass er Konfiguration und Prüfaufzeichnungen entspricht”, so Sygnia. Wie der Akteur ursprünglich Zugang erlangte, konnte Sygnia nicht klären; eine Schwachstelle nannte das Unternehmen nicht.