Authentifizierungsfehler in der Cisco ISE API eröffnet Remote-Zugriff mit Root-Rechten

Cisco hat dringend erforderliche Sicherheitsupdates für eine kritische Zero-Day-Schwachstelle in der Identity Services Engine und dem ISE Passive Identity Connector veröffentlicht. Die Schwachstelle wird bereits ausgenutzt. Erfolgreiche Angriffe können die Ausführung von Befehlen mit Root-Rechten ermöglichen.

Die als CVE-2026-76460 geführte Schwachstelle erreicht den maximalen CVSS-Score von 10,0. Betroffen sind Cisco ISE und ISE-PIC unabhängig von der jeweiligen Produktkonfiguration.

Cisco veröffentlichte seine Sicherheitsmeldung am 16. September 2026 um 16:00 Uhr GMT. Noch am selben Tag nahm CISA die Schwachstelle in seinen Katalog der bekannten ausgenutzten Schwachstellen auf und setzte für US-Bundesbehörden eine Frist zur Behebung bis zum 19. September 2026.

Es gibt keine vollständige Umgehungslösung. Administratoren müssen das passende korrigierte Release installieren und betroffene Appliances auf Hinweise für eine frühere Ausnutzung untersuchen.

Management-API setzt Authentifizierung nicht ordnungsgemäß durch

CVE-2026-76460 besteht, weil ein ISE-API-Endpunkt keine ausreichenden Authentifizierungskontrollen anwendet. Cisco ordnet das Problem CWE-648 zu, der fehlerhaften Verwendung privilegierter APIs.

Ein nicht authentifizierter Angreifer kann eine speziell präparierte Anfrage an eine betroffene Appliance senden. Damit lassen sich die Schutzmechanismen der webbasierten Managementoberfläche umgehen und unbefugte Zugriffe auf das System ermöglichen.

Für die Ausnutzung sind keine gestohlenen Zugangsdaten, kein bestehendes Konto und keine Interaktion durch einen Administrator erforderlich. Die Komplexität gilt außerdem als niedrig. Das bedeutet, dass der Angriff weder von ungewöhnlichen Race Conditions noch von schwer erfüllbaren Voraussetzungen abhängt.

Der vollständige CVSS-3.1-Vektor lautet:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:X/RL:X/RC:X

Die Bewertung mit geändertem Scope spiegelt Folgen wider, die über die ursprünglich verwundbare Komponente hinausgehen. Vertraulichkeit, Integrität und Verfügbarkeit sind jeweils als stark beeinträchtigt eingestuft.

Cisco warnt, dass die Ausnutzung die Ausführung von Befehlen als Root ermöglichen kann. Mit diesen Rechten könnte ein Angreifer die Appliance verändern, ihren Betrieb stören oder lokal gespeicherte Beweismittel manipulieren. Root-Zugriff erschwert außerdem die Analyse nach einem Sicherheitsvorfall, da ein Angreifer Protokolle löschen oder Spuren des Eindringens verbergen könnte.

Cisco führt die Schwachstelle intern unter der Bug-ID CSCww39530. Die Kennung der Sicherheitsmeldung lautet cisco-sa-ISE-ABP-VNSW7Tn5.

Für jeden unterstützten ISE-Release-Zweig ist ein bestimmtes Update erforderlich

Betroffen sind folgende Produkte:

• Cisco Identity Services Engine
• Cisco ISE Passive Identity Connector

Laut Cisco hängt die Gefährdung nicht von der Gerätekonfiguration ab. Unternehmen sollten daher nicht davon ausgehen, dass ein ungewöhnlicher Bereitstellungsmodus, eine deaktivierte Funktion oder eine andere lokale Einstellung das Risiko beseitigt.

Das erforderliche korrigierte Release richtet sich nach dem installierten Softwarezweig:

Installiertes Cisco-ISE- oder ISE-PIC-Release	Erstes Release mit Korrektur
3.1	3.1 Patch 12
3.2	3.2 Patch 11
3.3	3.3 Patch 12
3.4	3.4 Patch 7
3.5	3.5 Patch 4

Administratoren, die einen dieser Zweige einsetzen, sollten den aufgeführten Patch oder ein späteres korrigiertes Release für diesen Zweig installieren.

Cisco ISE Software Release 3.0 hat das Ende der Softwarewartung erreicht. Dafür ist kein korrigierender Patch aufgeführt. Unternehmen, die diese Version noch einsetzen, sollten daher auf ein unterstütztes Release mit der Korrektur migrieren.

Die Sicherheitsmeldung des Herstellers ist die maßgebliche Referenz für die Zuordnung der Releases. Unternehmen mit verteilten Bereitstellungen müssen jeden einzelnen Knoten erfassen und prüfen, statt nur das primäre Administrationssystem zu kontrollieren.

Aktive Angriffe führen zu dreitägigem Zeitfenster für Bundesbehörden

Das Product Security Incident Response Team von Cisco hat die Ausnutzung in freier Wildbahn bestätigt. Das Unternehmen entdeckte die Schwachstelle bei der Bearbeitung eines Supportfalls des Cisco Technical Assistance Center und nicht im Rahmen einer planmäßigen internen Prüfung.

Es wurde kein Angreifer identifiziert. Cisco hat die Aktivitäten weder einer kriminellen Organisation, einer staatlich unterstützten Operation noch einer namentlich bekannten Ransomware-Gruppe zugeordnet. Die verfügbaren Informationen enthalten außerdem keine Angaben zu den Zielen der Angreifer.

CISA nahm CVE-2026-76460 am 16. September 2026 in seinen Katalog der bekannten ausgenutzten Schwachstellen auf. Bundesbehörden müssen die erforderlichen Maßnahmen bis zum 19. September 2026 abschließen.

Der KEV-Eintrag verpflichtet Behörden, Ciscos Abhilfemaßnahmen umzusetzen und dabei BOD 26-04, „Priorisierung von Sicherheitsupdates nach Risiko“, sowie die Forensics Triage Requirements von CISA einzuhalten. Die geltenden Bestimmungen von BOD 26-04 umfassen auch Cloud-Dienste. Falls keine Abhilfemaßnahme verfügbar ist, weist CISA betroffene Stellen an, das Produkt nicht weiter zu verwenden.

Eine forensische Triage ist ausdrücklich erforderlich. Ob die Schwachstelle in Ransomware-Kampagnen eingesetzt wird, ist weiterhin unbekannt.

Die kurze Frist beruht auf beobachteter Ausnutzung und nicht lediglich auf einem theoretischen Angriffspfad. Verantwortliche für die jeweiligen Systeme müssen außerdem prüfen, ob jede Appliance dem Internet ausgesetzt oder aus Netzwerken erreichbar ist, von denen ein Angreifer Anfragen an die Managementebene senden könnte.

iACLs können die Gefährdung verringern, die Schwachstelle aber nicht beseitigen

Cisco hat keine Umgehungslösung identifiziert, die CVE-2026-76460 vollständig behebt. Die Installation eines korrigierten Releases ist die einzige angegebene Maßnahme zur Behebung.

Während die Patches ausgerollt werden, können Administratoren Infrastructure Access Control Lists, kurz iACLs, einsetzen, um den Datenverkehr zur betroffenen Appliance zu begrenzen. Diese Kontrollen sollten ausschließlich erforderliche Management- und Control-Plane-Verbindungen von ausdrücklich autorisierten Systemen und Netzwerken zulassen.

Die Maßnahme kann die für einen Remote-Angreifer verfügbaren Angriffswege verringern, insbesondere wenn Managementdienste bisher weitreichend erreichbar waren. Die fehlerhafte Authentifizierungslogik im API-Endpunkt wird dadurch jedoch nicht korrigiert.

Priorität sollten Systeme mit Internetzugang und Appliances haben, die aus weniger vertrauenswürdigen Netzwerksegmenten erreichbar sind. Eine rein interne Platzierung ist jedoch kein Beleg für Sicherheit. Eine kompromittierte Workstation, ein kompromittierter Server oder ein kompromittiertes Remote-Access-Konto könnte einem Angreifer die erforderliche Netzwerkposition verschaffen, um eine unzureichend geschützte Managementoberfläche zu erreichen.

Netzwerkbeschränkungen sollten nach dem Patchen beibehalten werden, sofern dies betrieblich möglich ist. Sie bilden eine zusätzliche Grenze um einen privilegierten Infrastrukturdienst, dürfen aber nicht als Ersatz für das Softwareupdate betrachtet werden.

Verteidiger sollten die Protokolle jedes Knotens prüfen

Cisco empfiehlt, access.log-Daten auf verdächtige Benutzernamen und API-Aktivitäten zu überprüfen. Bei einer verteilten ISE-Bereitstellung müssen Ermittler jeden Knoten untersuchen, da relevante Einträge möglicherweise nicht im primären oder zentralen System erscheinen.

Cisco stellt folgendes Beispiel für die Suche im API-Gateway-Protokoll bereit:

admin#show logging application ise-kong/access.log | include dummyuser

Der Wert dummyuser ist ein Beispiel und kein vollständiger Kompromittierungsindikator. Ein Treffer kann auf bösartige Aktivitäten hindeuten. Ermittler sollten ihn jedoch anhand der umgebenden Anfragen, Quelladressen, Zeitstempel und des erwarteten Administrationsverhaltens überprüfen. Außerdem sollten sie nach weiteren ungewöhnlichen Benutzernamen suchen und sich nicht allein auf diesen Wert verlassen.

Zusätzliche API-Gateway-Protokolle lassen sich erfassen, indem ein Support-Bundle mit aktivierten Debug-Protokollen erstellt wird. Cisco empfiehlt, das Bundle mit einer Shared-Key-Verschlüsselung zu schützen, es in der Untersuchungsumgebung zu entschlüsseln und die Dateien unter folgendem Pfad zu prüfen:

./ise/logs/apigateway/access.log..gz

Lokale Beweismittel können unvollständig sein. Da die Schwachstelle potenziell die Ausführung von Befehlen mit Root-Rechten ermöglicht, könnte ein erfolgreicher Angreifer Protokolle verändern, Dateien löschen oder Aktivitäten auf der Appliance anderweitig verbergen.

Ermittler sollten ISE-Datensätze mit Telemetriedaten aus anderen Quellen abgleichen, darunter Firewall-Ereignisse und Netzwerkflussdaten. Sie sollten nach nicht erklärbaren ausgehenden Uploads von einem ISE-Knoten, Downloads mit verdächtigen externen Adressen sowie ungewöhnlichen eingehenden oder ausgehenden Verbindungen im Zusammenhang mit der Bereitstellung suchen.

Bei einem Verdacht auf eine Kompromittierung empfiehlt Cisco dringend, betroffene Knoten neu zu installieren und sie bei Bedarf aus Konfigurationssicherungen wiederherzustellen. Das bloße Einspielen des Patches entfernt keine Persistenzmechanismen oder unbefugten Änderungen, die ein Angreifer möglicherweise bereits eingeführt hat.

Zuerst patchen, anschließend prüfen, ob bereits ein Zugriff erfolgt ist

Die unmittelbare Reaktion umfasst zwei parallele Maßnahmen: den verwundbaren API-Pfad schließen und feststellen, ob Angreifer ihn vor der Behebung erreicht haben.

Administratoren sollten jeden ISE- und ISE-PIC-Knoten identifizieren, das genaue Release überprüfen, den entsprechenden korrigierten Patch installieren und den Managementdatenverkehr mit iACLs einschränken, bis die Bereitstellung abgeschlossen ist. Systeme mit Release 3.0 müssen migriert werden; ein gewöhnlicher Patch reicht nicht aus.

Anschließend sollten sie verfügbare Protokolle sichern und prüfen, externe Netzwerkdaten erfassen und nicht erklärbare Aktivitäten auf der Managementebene als möglichen Sicherheitsvorfall behandeln. Wenn Indikatoren auf eine erfolgreiche Ausnutzung hindeuten, ist eine Neuinstallation sicherer, als der Integrität eines Systems zu vertrauen, das möglicherweise mit Root-Rechten kontrolliert wurde.