Cisco ISE Zero-Day erreicht CVSS 10.0 – CISA meldet aktive Ausnutzung

Cisco hat am Mittwoch, dem 17. September, einen Zero-Day mit CVSS 10.0 in seiner Identity Services Engine gepatcht, und CISA hat ihn noch am selben Tag in den Known Exploited Vulnerabilities-Katalog aufgenommen. Diese sofortige KEV-Aufnahme ist das entscheidende Signal: Die Ausnutzung ist nicht theoretisch, und Verteidiger hatten praktisch kein Zeitfenster zwischen der Offenlegung und der Einstufung als aktiven Vorfall.

Die Zahlen sollten Plattform-Teams aufhorchen lassen. CVE-2026-76460 ist der dritte API-Authentifizierungs-Bypass mit maximalem oder nahezu maximalem CVSS-Score, den Cisco in sieben Monaten veröffentlicht hat: 10.0 im SD-WAN-Manager-Bereich im Februar-Umfeld (CVE-2026-20129 mit 9,8), 10.0 in Secure Workload (CVE-2026-20223) im Mai und nun 10.0 in ISE. Drei Treffer beim selben Fehlertyp sind ein Muster, kein Zufall.

Was passiert ist

Laut Dark Reading handelt es sich bei CVE-2026-76460 um einen Authentifizierungs-Bypass in einem API-Endpunkt von Ciscos Identity Services Engine – dem Produkt, das Cisco als Lösung für Netzwerkzugangskontrolle und Zero-Trust vermarktet. Ciscos eigene Sicherheitshinweise benennen die Ursache als „unzureichende Authentifizierungskontrolle" an einem ISE-API-Endpunkt und beschreiben die Ausnutzung als das Senden einer manipulierten Anfrage, um die webbasierte Verwaltungsoberfläche zu umgehen.

Bei erfolgreicher Ausnutzung erhält ein nicht authentifizierter Remote-Angreifer Root-Rechte und Befehlsausführung. Keine Anmeldedaten, keine Benutzerinteraktion, keine Konfigurationsvoraussetzung: Die Schwachstelle betrifft ISE und ISE-PIC unabhängig von der Gerätekonfiguration. Cisco hat Patches für die Versionen 3.1 bis 3.5 veröffentlicht. Version 3.0 ist End-of-Support und erhält keinen Fix; betroffene Kunden werden aufgefordert, ein Upgrade durchzuführen.

CISAs Entscheidung, die CVE noch am selben Tag ihrer Offenlegung in den KEV-Katalog aufzunehmen, verdient besondere Aufmerksamkeit. Zivile Bundesbehörden haben nun eine verbindliche Frist zur Behebung. Normalerweise geschieht das erst nach einem beobachteten Ausnutzungszeitraum in freier Wildbahn; hier erfolgte es gleichzeitig mit der Offenlegung, was darauf hindeutet, dass CISA bereits vor Veröffentlichung des Patches über Telemetriedaten oder verlässliche Berichte verfügte.

Cisco hat auch mehrere weitere Schwachstellen in ISE und ISE-PIC mit ähnlichen API-Authentifizierungsproblemen offengelegt und gepatcht. Das Unternehmen hat auf die Anfrage von Dark Reading um Stellungnahme nicht reagiert. Was wir nicht wissen – und das ist relevant –, ist, wer die Schwachstelle ausnutzt und in welchem Ausmaß. Die Obergrenze der Opferzahl entspricht im Wesentlichen der installierten Basis von ISE 3.1 bis 3.5, abzüglich des Anteils, der innerhalb von 48 Stunden gepatcht hat – was bei unternehmenskritischer Identitätsinfrastruktur historisch gesehen gering ist.

Technische Analyse

Der Mechanismus ist simpel – und genau das ist das Problem. Johannes Ullrich, Gründer des SANS Internet Storm Center, sagte gegenüber Dark Reading, dass „fehlende Authentifizierung für API-Endpunkte ein branchenweites Problem" sei, und verwies auf die spezifische Ursache: „APIs, die früher nicht direkt erreichbar waren, werden exponiert, und dabei werden ordnungsgemäße Authentifizierung und Zugangskontrolle übergangen." Das „passiert leicht, wenn umfangreichere APIs bereitgestellt werden, um modernere Webanwendungsschnittstellen zu unterstützen."

In technischen Begriffen ausgedrückt: Ein interner RPC- oder nur für Administratoren bestimmter Endpunkt wird zur öffentlichen API-Oberfläche befördert, um ein neues Dashboard, eine Single-Page-App oder einen Automatisierungs-Hook zu versorgen. Die Auth-Middleware, die die alte Oberfläche abgesichert hat, wird dabei nicht immer mitgenommen. In monolithischen Produkten mit jahrzehntelangem angehäuften Routing-Code wird die Frage, ob ein bestimmter Handler hinter oder vor der Session-Prüfung läuft, zu einer Frage, die niemand beantworten kann, ohne die Router-Konfiguration Zeile für Zeile zu lesen. Das ist OWASP Broken Access Control-Territorium, und es ist seit mehreren Jahren die Risikokategorie Nummer eins für Web-Apps.

Der Schadensradius ist es, der dies von einer schweren Schwachstelle zu einer systemischen macht. ISE ist kein Blattknoten. Emma Stevens, Senior Threat Intelligence Advisor bei Bitsight, schrieb im Advisory des Unternehmens, dass ISE „bestimmt, welche Benutzer und Geräte sich mit einem Netzwerk verbinden können und worauf sie nach der Verbindung zugreifen können", und dass „Root-Zugriff auf diese Infrastruktur Sichtbarkeits-, Integritäts- und Verfügbarkeitsrisiken in einer viel breiteren Umgebung schaffen kann." Ullrich brachte es noch deutlicher auf den Punkt: Andere Cisco-APIs nutzen ISE für Authentifizierungs- und Zugriffskontrollentscheidungen, sodass eine Kompromittierung von ISE einem Angreifer ermöglicht, die Lösung zu deaktivieren, auf die Netzwerke zuzugreifen, die ISE schützt, oder andere Hosts zu imitieren. Seine Analogie: „Es ist, als würde man den Sicherheitsdienst eines Gebäudes durch einen Betrüger ersetzen."

Es gibt einen noch gefährlicheren Sekundäreffekt. Ciscos Advisory weist darauf hin, dass eine erfolgreiche Ausnutzung Angreifern die Möglichkeit gibt, Beweise für die Ausnutzung und Indicators of Compromise auf dem Gerät selbst zu löschen oder zu verbergen. Deshalb empfiehlt das Unternehmen ausdrücklich, Netzwerk- und Firewall-Protokolle von außerhalb des betroffenen Geräts auf unerwartete Uploads zu externen IPs oder Downloads von schädlichen IPs gegenzuprüfen. Jede forensische Untersuchung, die sich ausschließlich auf ISEs eigene Protokolle nach einer Kompromittierung stützt, ist konstruktionsbedingt unzuverlässig. Die Quelle gibt nicht an, ob gepatchte Instanzen forensische Artefakte einer Ausnutzung vor dem Patch behalten, was wichtig ist, da Incident Responder wissen müssen, ob das Expositionsfenster überhaupt auditierbar ist.

Wer betroffen ist

Jeder, der ISE 3.1 bis 3.5 als Identity Control Plane für sein Unternehmensnetzwerk betreibt, befindet sich im unmittelbaren Schadensradius – und das ist eine große Gruppe: ISE ist die Standardwahl in Cisco-lastigen Umgebungen, was bedeutet: große Banken, Telekommunikationsunternehmen, Gesundheitssysteme, Behörden und jedes regulierte Unternehmen, das im letzten Jahrzehnt auf Cisco-Netzwerke standardisiert hat. Kunden mit Version 3.0 sind noch schlechter dran: Es kommt kein Patch, sodass sie ein Upgrade-Projekt unter Notfallbedingungen erben.

Für iGaming- und Fintech-Plattform-Teams, die ISE für NAC in Unternehmensnetzwerken (und nicht in Produktionsumgebungen) einsetzen, geht es bei der Exposition weniger um Zahlungswege als um laterale Bewegung. Ein Angreifer mit Root-Zugriff auf ISE kann in jedes Netzwerksegment eindringen, auf das ISE den Zugang vermittelt – einschließlich Admin-VLANs, Jump-Hosts und der Management-Planes der Produktionsinfrastruktur. In regulierten Bereichen verwandelt das eine Netzwerkzugangskontroll-Schwachstelle in ein Pflichtgespräch über Datenschutzverletzungsmeldungen.

Betreiber von Krypto-Custody- und DeFi-Infrastrukturen, die Cold-Signing-Umgebungen hinter Cisco NAC betreiben, sollten dies als ein Segmentierungsvalidierungsereignis behandeln, nicht als Patch-Ereignis. Wenn ISE entscheidet, welche Endpunkte Ihr HSM-Verwaltungsnetzwerk erreichen, existiert die Vertrauensgrenze, die Sie für gegeben hielten, während des Ausnutzungsfensters nicht.

Ad-Tech- und Enterprise-SaaS-Unternehmen mit Cisco-Identitätsinfrastruktur am Hauptsitz oder in Colocation-Einrichtungen stehen vor einem subtileren Problem: Ihre SOC-Dashboards vertrauen wahrscheinlich ISE-basierten Authentifizierungsereignissen. Jede Erkennungslogik, die besagt „Benutzer X hat sich über ISE authentifiziert, daher ist diese Sitzung legitim", ist vorübergehend unzuverlässig. Die Unbekannte ist, wie viele nachgelagerte SIEM-Regeln implizit auf ISE-Aussagen beruhen; ich schätze: „mehr als das Sicherheitsteam derzeit dokumentiert hat."

Der 90-Tage-Ausblick: Erwarten Sie mindestens einen öffentlich bekannt gegebenen Sicherheitsvorfall, der dieser CVE bis Ende Q4 2026 zugeschrieben wird, und erwarten Sie, dass Ciscos Wettbewerber (Aruba ClearPass, Fortinet FortiNAC und die verschiedenen Zero-Trust-Overlay-Anbieter) dies in Unternehmensverkaufszyklen bis in die erste Hälfte 2027 instrumentalisieren werden.

Maßnahmenplan für Sicherheitsteams

Zuerst patchen, dann verifizieren. Cisco hat Fixes für ISE und ISE-PIC 3.1 bis 3.5 veröffentlicht. Version 3.0 benötigt ein Upgrade, keinen Patch – das ist ein Projekt, kein Change-Ticket. Cisco bietet eine teilweise Abmilderung über Infrastructure Access Control Lists (iACLs) an, die einschränken, wer den anfälligen API-Endpunkt erreichen kann, aber das Unternehmen selbst sagt, dass Abmilderungen temporär sind. Behandeln Sie die iACL nicht als Endziel.

Gehen Sie von einer Kompromittierung vor dem Patch aus, wenn Ihre ISE-Verwaltungsschnittstelle von etwas Breiterem als einem gehärteten Admin-Subnetz erreichbar war. Da On-Box-Protokolle nach der Ausnutzung manipuliert werden können, holen Sie sich korrelierte Beweise von vorgelagerten Firewalls, Netflow-Kollektoren und Out-of-Band-Syslog-Zielen. Suchen Sie insbesondere nach unerwarteten ausgehenden Uploads von ISE-Appliances und eingehenden Verbindungen von IPs außerhalb Ihrer normalen Admin-Quellen.

Ersetzen Sie alles, was ISE kannte. Wenn ISE RADIUS-Shared-Secrets, TACACS-Schlüssel, PKI-Vertrauensmaterial oder API-Zugangsdaten für nachgelagerte Integrationen enthielt, behandeln Sie diese als kompromittiert während des Expositionsfensters. Das ist die mühsame, teure Arbeit, die die meisten Teams überspringen werden und später bereuen werden.

Prüfen Sie den CVE-Eintrag bei MITRE und stellen Sie sicher, dass Ihr Asset-Inventar jede ISE- und ISE-PIC-Instanz widerspiegelt, einschließlich derer, die in Labor-, DR- und übernommenen Tochtergesellschaftsumgebungen laufen, die niemand seit zwei Jahren angefasst hat. Schatten-ISE-Deployments sind der Ort, an dem diese Schwachstelle am längsten verbleibt.

Prognose: Wenn diese Ausnutzung so aktiv ist, wie CISAs sofortige KEV-Aufnahme impliziert, sollten wir innerhalb von 60 Tagen mindestens eine namentlich genannte Bedrohungsakteur-Zuschreibung und eine KEV-bedingte Pflichtmeldung einer US-Bundesbehörde sehen. Wenn das bis Mitte November nicht geschieht, war die Ausnutzungsaktivität enger begrenzt, als die CISA-Maßnahme andeutete.

Wichtigste Erkenntnisse

• CVE-2026-76460 ist ein CVSS-10.0-unauthentifizierter Remote-Root auf Cisco ISE, aktiv ausgenutzt, am 17. September gepatcht mit gleichzeitiger CISA-KEV-Aufnahme.
• Dies ist Ciscos dritter API-Auth-Bypass mit maximalem oder nahezu maximalem CVSS-Score im Jahr 2026, nach CVE-2026-20223 (Secure Workload, 10.0, Mai) und CVE-2026-20129 (SD-WAN Manager, 9.8, Februar). Ein Muster, kein Zufall.
• Eine ISE-Kompromittierung hat Kaskadeneffekte: Andere Cisco-APIs verlassen sich für Auth-Entscheidungen auf ISE, sodass Root-Zugriff auf ISE das Vertrauen in alle Netzwerksegmente untergräbt, die ISE vermittelt.
• On-Box-Forensikprotokolle sind nach der Ausnutzung unzuverlässig. Untersuchen Sie von vorgelagerten Firewalls und Out-of-Band-Protokollzielen aus, nicht von der Appliance selbst.
• Überprüfbare Einschätzung: Wenn die sofortige KEV-Aufnahme das tatsächliche Ausmaß der Ausnutzung widerspiegelt, ist innerhalb von 60 Tagen eine namentliche Zuschreibung oder eine Bundesbehörden-Meldung zu erwarten. Bleibt beides bis Mitte November aus, war die Aktivität enger begrenzt als signalisiert.