Die kurze Antwort
Eine ungepatchte Cisco ISE lässt sich mit einem einzigen präparierten Request übernehmen — ohne Login, ohne Zugangsdaten. CVE-2026-76460 (CVSS 10.0) ist eine Authentifizierungs-Bypass-Lücke an einem ISE-API-Endpunkt, die in die beliebige Befehlsausführung als root übergeht. Cisco bestätigte aktive Ausnutzung, CISA nahm die Lücke im September 2026 in den Known-Exploited-Vulnerabilities-Katalog auf, und Cisco erklärt, dass es keinen Workaround gibt. Die Behebung ist ein sofortiges Upgrade von ISE auf ein korrigiertes Release.
Für Teams in DACH und der EU liegt der Stachel dort, wo die Lücke sitzt: ISE ist das System, das entscheidet, wer und was ins Netzwerk darf — wer es besitzt, besitzt die Zugriffs-Policy selbst. Solche Appliances genießen implizites Vertrauen und schaffen es selten in einen Testumfang — genau deshalb gehören sie hinein. Diese Haltung bauen wir in einen Penetrationstest und ein Security-Audit ein: Systeme, die Ihre Sicherheit durchsetzen sollen, als Angriffsfläche behandeln und beweisen, dass sie standhalten.
Was Cisco offengelegt hat
Cisco Identity Services Engine (ISE) ist das Policy-Gehirn der Netzwerkzugangskontrolle im Unternehmen. Sie authentifiziert Benutzer und Geräte, erzwingt, wer welches Netzsegment erreichen darf, und steuert 802.1X, Gastzugang, Posture-Checks und Segmentierung. Diese Rolle macht sie zu einem der sensibelsten Nadelöhre in einer Unternehmensarchitektur: Wer ISE kontrolliert, kompromittiert nicht nur einen Server, sondern erlangt einen Hebel über die Regeln, die den Zugriff auf alles andere bestimmen.
Im September 2026 legte Cisco CVE-2026-76460 offen, eine Schwachstelle, die durch unzureichende Authentifizierungskontrollen an einem bestimmten API-Endpunkt in ISE und im ISE Passive Identity Connector (ISE-PIC) verursacht wird. Ein nicht authentifizierter, entfernter Angreifer kann einen präparierten Request an diesen Endpunkt senden, die webbasierte Verwaltungsoberfläche umgehen und letztlich Befehle mit root-Rechten auf dem zugrunde liegenden System ausführen. Cisco bewertete sie mit CVSS 10.0 — dem oberen Ende der Skala —, wies darauf hin, dass ISE und ISE-PIC unabhängig von der Konfiguration betroffen sind, und bestätigte, dass es keinen Workaround gibt.
Ciscos PSIRT erklärte zudem, von aktiver Ausnutzung Kenntnis zu haben. Kurz nach der Offenlegung nahm CISA CVE-2026-76460 in seinen Katalog der Known Exploited Vulnerabilities auf, was für US-Bundesbehörden eine verbindliche Behebungsfrist auslöst und für alle anderen ein starkes Signal ist. Eine KEV-Aufnahme bedeutet, dass die Angriffe bestätigt und nicht theoretisch sind — und da ein erfolgreicher Exploit als root läuft, kann ein Eindringling genau die Spuren verbergen oder löschen, nach denen ein Verteidiger suchen würde.
Warum ein Request zu root wird
Was diesen Bug so schwerwiegend macht, ist das vollständige Fehlen von Voraussetzungen. Es gibt kein Passwort zu erraten, keine Session zu übernehmen, keinen Phishing-Köder, den ein Benutzer anklicken müsste. Der Angreifer sendet einen präparierten Request an einen API-Endpunkt, der die Authentifizierung nicht erzwingt, und dieses eine Versäumnis öffnet die Verwaltungsoberfläche. Da der ausgenutzte Prozess mit hohen Rechten läuft, endet die Kette in der Befehlsausführung als root auf dem Host — eine vollständige Kompromittierung des Geräts von einem nicht authentifizierten Ausgangspunkt aus.
Diese Kombination — nicht authentifiziert, entfernt, ohne Benutzerinteraktion, root-Ergebnis — ist der Grund, warum der CVSS-Wert 10.0 erreicht und warum die Ausnutzung der Offenlegung so schnell folgte. Wer ISE besitzt, besitzt das System, das den Netzwerkzugang entscheidet: Er kann Zugriffs-Policys anlegen oder ändern, eigene Geräte autorisieren, eine Segmentierung deaktivieren, die ihn eindämmte, die Identitäts- und Posture-Daten von ISE auslesen und das Gerät als dauerhaften, vertrauenswürdigen Brückenkopf nutzen, um sich seitlich zu bewegen. Für ein Sicherheitssystem ist das der schlimmste Fehlerfall, denn der Einbruch geschieht innerhalb genau des Mechanismus, den die Organisation zur Verhinderung installiert hat.
Es gibt kein Feature-Flag und keine Policy-Einstellung, die CVE-2026-76460 neutralisiert — deshalb ist Cisco explizit, dass kein Workaround existiert. Der verwundbare Code liegt im Authentifizierungspfad der API selbst. Cisco veröffentlichte korrigierte Releases über die unterstützten Trains hinweg — ISE und ISE-PIC 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 und 3.5 Patch 4 —, und das Upgrade auf eines davon ist die einzige echte Behebung. Als Übergangsmaßnahme, während Sie das Update planen, können Infrastructure Access Control Lists (iACLs), die den Verkehr zu den ISE-Management- und -API-Schnittstellen einschränken, den entfernten Pfad blockieren, den ein Angreifer benötigt.
Was es für Software-Teams in DACH bedeutet
Die erste Lehre lautet, dass das Identitätssystem Teil Ihrer Angriffsfläche ist, kein Ersatz für deren Absicherung. Teams vertrauen dem Security-Stack implizit — dem NAC, dem Identitätsserver, der Firewall — und lassen diese Geräte aus den Bewertungen heraus, die sie gegen ihre eigenen Anwendungen fahren. Doch ein aus dem Internet oder dem Management erreichbares Gerät mit einem Pre-Auth-Pfad zu root ist genau das, wonach ein Angreifer zuerst sucht — und hier verschafft es in einem Schritt Kontrolle über die Zugriffs-Policy. Dieselbe Härtungsdisziplin, die Sie auf Ihre Cloud- und DevOps-Plattform anwenden — least privilege, enge Netzexposition, schnelle Patch-Pipelines und Monitoring —, muss sich auf Identitäts- und Netzwerk-Appliances erstrecken und nicht beim selbst geschriebenen Code enden.
Die zweite Lehre betrifft Patch-Geschwindigkeit als operative Fähigkeit. Wenn ein Bug innerhalb kurzer Zeit von der Offenlegung in den CISA-KEV wandert, mit 10.0 bewertet ist und keinen Workaround hat, ist die einzige Variable, die Sie steuern, wie schnell Sie betroffene Knoten identifizieren und den Fix ausrollen können. Organisationen, die ein aktuelles Asset-Inventar pflegen, wissen, welche Appliances Management- oder API-Schnittstellen exponieren, und ein Out-of-Band-Update innerhalb von Stunden einplanen können, schließen dies, bevor es gegen sie verwendet wird; wer seine Exposition erst während eines Vorfalls entdeckt, nicht. Diese Bereitschaft ist ein Prozess, den man im Voraus aufbaut, nicht unter Feuer improvisiert.
Drittens ist dies ein Compliance- und Meldeereignis, nicht bloß ein IT-Ticket. ISE steuert den Zugriff auf Systeme, die regelmäßig personenbezogene und regulierte Daten verarbeiten, sodass ein root-Kompromiss davon direkt in die Erwartungen von DSGVO, NIS2 und — für den Finanzsektor — DORA an Zugriffskontrolle und zügige, dokumentierte Behebung fällt. In DACH kommen für KRITIS-Betreiber die Melde- und Nachweispflichten nach dem BSIG hinzu. Nachweisen zu können, welche Knoten betroffen waren, wann Sie gepatcht haben, ob Sie zwischenzeitlich iACLs angewendet haben und wonach Sie an Ausnutzungsspuren gesucht haben, ist genau der Nachweis, den Aufsicht und Prüfer zuerst verlangen.
Was jetzt zu tun ist
- Jeden ISE-Knoten erfassen. Finden Sie alle Cisco-ISE- und ISE-PIC-Installationen, auch Standby-, Sekundär- und Laborinstanzen — die, die auf Ihrer Liste fehlen, bleiben ungepatcht.
- Sofort patchen. Spielen Sie das korrigierte Release für Ihren Train ein — 3.1 P12, 3.2 P11, 3.3 P12, 3.4 P7 oder 3.5 P4. Es gibt keinen Workaround, behandeln Sie dies also als Notfalländerung, nicht als geplantes Wartungsfenster.
- Zugriff übergangsweise einschränken. Bis jeder Knoten gepatcht ist, beschränken Sie mit iACLs den Verkehr zu den ISE-Management- und -API-Schnittstellen auf vertrauenswürdige Administrationsnetze und kappen so den entfernten Pfad, den ein Angreifer benötigt.
- Nach Ausnutzung suchen. Prüfen Sie ISE- und Netzwerk-Logs auf unerwartete API-Aufrufe, neue oder geänderte Zugriffs-Policys, unbekannte autorisierte Geräte und root-Aktivität. War ein Knoten erreichbar und ungepatcht, ermitteln Sie unter der Annahme, dass er bereits kompromittiert sein könnte — und denken Sie daran, dass ein root-Angreifer Logs manipuliert haben kann.
- Eindämmen, rotieren, dann testen. Rotieren Sie Zugangsdaten, Zertifikate und Secrets, die ISE hielt oder beobachten konnte, prüfen Sie die Integrität Ihrer Zugriffs-Policys und nehmen Sie Identitäts- und Netzwerkzugangs-Appliances in den Umfang Ihres nächsten Penetrationstests auf, damit die nächste KEV-Aufnahme automatisch zu Handeln führt.
Häufig gestellte Fragen
Was ist CVE-2026-76460?
Es ist eine kritische Authentifizierungs-Bypass-Schwachstelle (CVSS 10.0) in einer API von Cisco Identity Services Engine (ISE) und ISE Passive Identity Connector (ISE-PIC). Unzureichende Authentifizierungskontrollen an einem bestimmten Endpunkt lassen einen nicht authentifizierten, entfernten Angreifer einen präparierten Request senden, die webbasierte Verwaltungsoberfläche umgehen und letztlich Befehle mit root-Rechten ausführen. Beide Produkte sind unabhängig von der Konfiguration betroffen, und es gibt keinen Workaround.
Wie wird die Lücke ausgenutzt?
Der Angriff braucht keine Authentifizierung und keine Interaktion auf der Zielseite. Ein Angreifer sendet einen speziell präparierten Request an einen verwundbaren API-Endpunkt, der die Authentifizierung nicht erzwingt; dieser Bypass öffnet die Verwaltungsoberfläche, und eine erfolgreiche Ausnutzung endet in der Befehlsausführung als root. Da ISE entscheidet, wer und was sich mit dem Netzwerk verbinden darf, bedeutet die Kontrolle darüber die Kontrolle über die Netzwerkzugriffs-Policy.
Welche Versionen sind betroffen, und was sind die Fixes?
Cisco ISE und ISE-PIC sind unabhängig von der Konfiguration betroffen. Cisco veröffentlichte korrigierte Releases: ISE/ISE-PIC 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 und 3.5 Patch 4. Es gibt keinen Workaround; das Einspielen des korrigierten Release ist die einzige Behebung. Als Übergangsschutz können iACLs, die den Verkehr zum betroffenen Gerät einschränken, eine entfernte Ausnutzung verhindern.
Wird CVE-2026-76460 in freier Wildbahn ausgenutzt?
Ja. Ciscos PSIRT bestätigte, von aktiver Ausnutzung Kenntnis zu haben, und CISA nahm die Lücke im September 2026 in den US-Katalog der Known Exploited Vulnerabilities auf, was Bundesbehörden zur Behebung innerhalb einer gesetzten Frist verpflichtet. Eine KEV-Aufnahme bedeutet bestätigte Angriffe, daher sollte jede Organisation mit einer betroffenen ISE-Installation den Patch als Notfall behandeln.
Was sollten Teams jetzt tun?
Erfassen Sie jeden ISE- und ISE-PIC-Knoten, auch Standby- und Laborinstanzen, und spielen Sie das korrigierte Release für Ihren Train sofort ein. Beschränken Sie während des Patchens mit iACLs den Management- und API-Zugriff auf vertrauenswürdige Netze. Prüfen Sie Logs auf unerwartete API-Aufrufe, geänderte Zugriffs-Policys und root-Aktivität und gehen Sie von einer Kompromittierung aus, falls das Gerät erreichbar und ungepatcht war. Rotieren Sie Zugangsdaten und Zertifikate, die ISE hielt, und nehmen Sie Identitäts- und Netzwerk-Appliances in Ihren nächsten Penetrationstest auf.
Quellen
SecurityWeek — Active Exploitation Triggers Emergency Patch for Cisco ISE Zero-Day
Security Affairs — CISA Adds Acronis Backup, Cisco ISE, and Google Pixel Flaws to KEV Catalog
CISA — CISA Adds Two Known Exploited Vulnerabilities to Catalog