Cisco prüfte den eigenen Quellcode mit KI-Modellen und veröffentlichte im August 21 neue CVE-Einträge zu vier Produktlinien. Fünf davon tragen den CVSS-Höchstwert 10,0, drei in der Netzverwaltung Crosswork und zwei in der Segmentierungsplattform Secure Workload. Umgehungslösungen nennt der Hersteller keine.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Die beiden Hinweise vom 19. August listen zusammen neun Einträge. Der interessantere Teil steht weiter unten: Neun Nummern bedeuten bei Cisco nicht neun Fehler.
Das Wichtigste in Kürze
- Fünf der neun neuen Einträge zu Crosswork und Secure Workload tragen CVSS 10,0, die drei Crosswork-Lücken sogar ohne Zugangsdaten und ohne Nutzeraktion.
- Gefunden hat Cisco die Fehler intern, nach eigener Angabe mit Testverfahren und KI-Spitzenmodellen.
- Je Fehlerklasse vergibt Cisco genau eine CVE-Nummer. Der CVSS-Wert nennt darin den schwersten Einzelfehler.
- Umgehungslösungen nennt Cisco keine, Abhilfe schaffen allein die Releases 7.2.1-SP, 3.10.9.1 und 4.0.4.16.
Welche Cisco-Produkte trifft die August-Welle?
Verwundbar sind Crosswork Data Gateway, Network Controller und Planning bis Version 7.2.1.[1] Bei Secure Workload betreffen die Lücken die Reihe 3.10 und älter sowie 4.0, korrigiert in 3.10.9.1 beziehungsweise 4.0.4.16.[2]
Die drei Crosswork-Einträge mit Höchstwertung stehen für eine SQL-Injektion, für eine fehlende Authentifizierung an einer kritischen Funktion und für externe Kontrolle über das Dateisystem. Der CVSS-Vektor lautet in allen drei Fällen AV:N/AC:L/PR:N/UI:N/S:C: Angriff über das Netz, keine Rechte, keine Nutzeraktion, Wirkung über die verwundbare Komponente hinaus.[1]
Dasselbe Verfahren lief zwei Wochen zuvor bei weiter verbreiteten Produkten. Am 5. August erschienen sieben Einträge zu IOS XE mit einem Spitzenwert von 9,8 und fünf zu Catalyst SD-WAN, drei davon bei 9,9.[3] Ob ein Gerät solche Korrekturen überhaupt noch bekommt, hängt am Wartungsplan des Herstellers, der mitunter Jahre vor dem Gerät selbst endet.
Warum steckt hinter einer CVE-Nummer mehr als ein Fehler?
Cisco gruppiert die intern gefundenen Fehler nach ihrer Fehlerklasse (Common Weakness Enumeration) und vergibt je Gruppe eine einzige CVE-Nummer. Der angegebene CVSS-Wert beschreibt den schwersten Einzelfehler dieser Gruppe, nicht jeden Fehler darin.[3]
Diese Zählweise verschiebt für Betreiber zwei Größen. Neun Nummern untertreiben die Fehlermenge, weil Cisco nicht veröffentlicht, wie viele Funde in einer Klasse stecken. Umgekehrt gilt die 10,0 nicht für jeden Fund, sondern markiert die Obergrenze der Klasse.
Als Herkunft nennt Cisco vorhandene Testverfahren und ausdrücklich KI-Spitzenmodelle.[1] Im Juli veröffentlichte der Konzern dazu ein eigenes offenes Modell für die Schwachstellensuche. Bei Microsoft schlug derselbe Effekt anders durch, dort wuchs der Rückstau an offenen Meldungen.
Die Kehrseite kennt die Branche: Anfang August landete eine halluzinierte SQLite-Lücke in der CVE-Datenbank. Ein Befund aus dem eigenen Quellcode wiegt schwerer, weil dem Hersteller Code und Testumgebung vorliegen.
Fünf Höchstwertungen auf einmal klingen nach Alarm, zeigen aber vor allem, dass Cisco die eigenen Fehler findet, bevor Angreifer darauf stoßen. Für Betreiber bleibt trotzdem die Pflicht, den Versionsstand sofort zu prüfen.
— Michael Dobler, Herausgeber Dr. Web
Vier Produktlinien, zwei Veröffentlichungstermine, 2026
Was folgt daraus für Netze im DACH-Raum?
Crosswork steuert die Netze von Providern, Secure Workload segmentiert Rechenzentren. Genau für solche Systeme verlangt § 30 BSIG ein dokumentiertes Schwachstellenmanagement.[4]
Absatz 2 Nummer 5 nennt ausdrücklich „Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von informationstechnischen Systemen, Komponenten und Prozessen, einschließlich Management und Offenlegung von Schwachstellen“.[4] Der eingeplante Patch-Termin gehört damit in die Dokumentation nach Absatz 1, nicht nur ins Ticketsystem. Warum die Verantwortung dafür in der Geschäftsleitung liegt, zeigt unser Beitrag über Cybersecurity als Chefsache ein.
Bei SaaS-Instanzen von Secure Workload hat Cisco den Cluster bereits selbst aktualisiert, Agenten und Konnektoren ziehen die Kunden nach.[2]
Der Satz „nicht bekannt als aktiv ausgenutzt“ beschreibt einen Stichtag, keine Eigenschaft. Bei der SAP Commerce Cloud lagen zwischen Patch und erstem Angriff drei Tage. Bei Fortinet genügte ein beliebiges Passwort für den Administratorzugang.
FAQ: Cisco findet mit KI-Modellen fünf Lücken der Höchststufe im eigenen Code
Welche Cisco-Versionen schließen die Lücken vom 19. August 2026?
Crosswork Data Gateway, Network Controller und Planning brauchen Release 7.2.1-SP. Secure Workload braucht 3.10.9.1 in der Reihe 3.10 und älter sowie 4.0.4.16 in der Reihe 4.0. Umgehungslösungen nennt Cisco für keine der neun Schwachstellen, ein Update ist damit der einzige Weg.
Was bedeutet CVSS 10,0?
CVSS 10,0 ist der höchste Wert der Skala und steht für einen Angriff über das Netz ohne Zugangsdaten, ohne Nutzeraktion und mit voller Wirkung auf Vertraulichkeit, Integrität und Verfügbarkeit. Bei den drei Crosswork-Lücken reicht die Wirkung zusätzlich über die verwundbare Komponente hinaus.
Was ist eine Security Hardening Release bei Cisco?
Eine Security Hardening Release bündelt Schwachstellen, die Cisco bei einer internen Prüfung selbst gefunden hat, in einer einzigen Softwareversion. Cisco gruppiert die Funde nach der Fehlerklasse der Common Weakness Enumeration. Jede Gruppe bekommt genau eine CVE-Nummer.
Sind die Cisco-Lücken bereits ausgenutzt worden?
Cisco erklärt zum Veröffentlichungszeitpunkt am 19. August 2026, dass keine Ausnutzung bekannt ist. Diese Aussage beschreibt einen Stichtag. Nach der Veröffentlichung eines Advisories verkürzt sich die Zeit bis zum ersten Angriff erfahrungsgemäß auf wenige Tage.
Welche Pflichten hat ein NIS2-reguliertes Unternehmen bei so einer Meldung?
Nach § 30 Absatz 2 Nummer 5 BSIG gehört das Management und die Offenlegung von Schwachstellen zu den Mindestmaßnahmen besonders wichtiger und wichtiger Einrichtungen. Der Umgang mit dem Advisory und der eingeplante Patch-Termin gehören deshalb in die Dokumentation nach § 30 Absatz 1 BSIG.
Quellen
[1] Cisco: „Cisco Crosswork Security Hardening Release: August 2026“
[2] Cisco: „Cisco Secure Workload Software Security Hardening Release: August 2026“
[3] Cisco: „Cisco IOS XE Software Security Hardening Release: August 2026“
[4] Bundesministerium der Justiz: „§ 30 BSIG, Risikomanagementmaßnahmen besonders wichtiger Einrichtungen und wichtiger Einrichtungen“
Mehr Newshunger?
- Siemens-S7-Steuerungen: US-Behörden warnen vor KI-generierten Angriffen
- Defender-Lücke ShieldBreak: CISAs 14-Tage-Frist läuft ohne Patch
- Cloudflare Workers: Ein Spectre-Angriff las das JWT eines fremden Kunden
- GitLab schließt die Lücke, die öffentliche Projekte ohne Anmeldung löscht
- GLM-5.3 und die Schwachstellen-Suche: Zhipu vergibt den Vollzugriff nur nach Prüfung
- TeamCity-Lücke: Angreifer übernehmen den Build-Server ohne Zugangsdaten
