CVE-2026-76460: Cisco ISE Auth Bypass (CVSS 10.0) als Zero-Day ausgenutzt

Diese Woche in unserer InSEKurity of the Week-Reihe: die Schwachstelle, die Ihre Network-Access-Control-Plattform in die Network-Access-Control-Plattform des Angreifers verwandelt. Am 16. September 2026 veröffentlichte Cisco das Advisory cisco-sa-ISE-ABP-VNSW7Tn5 zu CVE-2026-76460, einem Authentication Bypass in Cisco Identity Services Engine (ISE) und ISE Passive Identity Connector (ISE-PIC). Bewertet mit CVSS 3.1 10.0 — dem Maximalwert — und klassifiziert als CWE-648, Incorrect Use of Privileged APIs. Das Cisco PSIRT stellte unmissverständlich fest, es sei “aware of active exploitation of this vulnerability”. Es war ein Zero-Day.

CISA nahm die Schwachstelle am selben Tag in den Known-Exploited-Vulnerabilities-Katalog auf, mit einer Frist zum 19. September — drei Tage — und markierte sie unter BOD 26-04 für die forensische Triage. Diese letzte Markierung sollte man zweimal lesen. CISA fordert Bundesbehörden hier nicht nur auf zu patchen. CISA fordert sie auf herauszufinden, ob sie bereits kompromittiert wurden.

Die Schwachstelle selbst ist beinahe langweilig zu beschreiben: unzureichende Authentifizierungskontrolle an einem API-Endpunkt. Senden Sie einen präparierten Request an diesen Endpunkt, und Sie sind am webbasierten Management-Interface vorbei — ohne Zugangsdaten, von überall dort, wo das Interface antwortet. Was daraus eine CVSS 10.0 statt einer CVSS 9.8 macht, ist der Scope Change: Das kompromittierte System ist nicht das leidtragende System. ISE ist die Instanz, die entscheidet, welche Geräte und welche Personen mit welchen Rechten ins Unternehmensnetz dürfen. Erfolgreiche Ausnutzung führt zu Befehlsausführung mit Root-Rechten auf dem Knoten, und Ciscos eigene Hinweise zur Konsequenz sind ungewöhnlich deutlich: Spuren der Ausnutzung und Indicators of Compromise können durch die Angreifer entfernt oder verborgen worden sein.

Und sie kam nicht allein. CVE-2026-76460 wurde am 16. September in den KEV-Katalog aufgenommen; tags zuvor, am 14. September, war bereits CVE-2026-76461 dort gelandet — eine unauthentifizierte SQL Injection bis Root in Cisco Secure Email Gateway, ebenfalls aktiv ausgenutzt. Und am 17. September veröffentlichte Cisco eine gebündelte Offenlegung von 20+ CVEs über ISE, Secure Firewall Management Center, Nexus Dashboard und ASA/FTD, von denen vier ISE-Schwachstellen ebenfalls mit CVSS 10.0 bewertet sind. Das war keine gute Woche, um Cisco-Security-Infrastruktur zu betreiben.

🚨 Zusammenfassung

CVE-ID: CVE-2026-76460
CVSS-3.1-Score: 10.0 Kritisch (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
CWE: CWE-648: Incorrect Use of Privileged APIs
Cisco Advisory: cisco-sa-ISE-ABP-VNSW7Tn5, erstveröffentlicht 2026-09-16, 16:00 GMT
Cisco Bug-ID: CSCww39530
Betroffene Software: Cisco ISE und ISE-PIC, Releases 3.0 bis 3.5 — unabhängig von der Gerätekonfiguration. Es gibt kein Feature zum Abschalten und keine Einstellung, die Sie schützt
Angriffsvektor: Netzwerk — überall dort, wo das ISE-Management-Interface antwortet
Authentifizierung erforderlich: Keine
Root Cause: Unzureichende Authentifizierungskontrolle an einem API-Endpunkt. Ein präparierter Request erreicht eine privilegierte API, ohne die Authentifizierung zu durchlaufen, die das webbasierte Management-Interface eigentlich erzwingen soll
Impact: Unautorisierter Zugriff auf das Gerät, eskalierend zu Befehlsausführung als Root — und von dort zu den RADIUS-Secrets, dem Active-Directory-Join-Konto, der internen CA und der Autorisierungsrichtlinie Ihres gesamten Netzwerks
Patch-Status: Verfügbar — 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7, 3.5 Patch 4
Release 3.0: End of Support. Kein Fix. Migration ist der einzige Weg
Workarounds: Keine. Cisco bietet eine Mitigation — Infrastructure Access Control Lists — keinen Workaround
Exploitation-Status: Aktiv ausgenutzt als Zero-Day. Zum Redaktionsschluss war kein öffentlicher Proof-of-Concept veröffentlicht; die Angreifer brauchten keinen
CISA KEV: Gelistet — aufgenommen 2026-09-16, Frist 2026-09-19, Ransomware-Nutzung als Unknown erfasst, forensische Triage erforderlich: Ja
Was dabei oft übersehen wird: Patchen beantwortet die Frage nicht. Cisco empfiehlt, jeden verdächtigen Knoten neu zu installieren, denn Root auf einem ISE-Knoten schließt Root über genau die Logs ein, mit denen Sie beurteilen würden, ob der Knoten angefasst wurde

🖥️ Was ist Cisco Identity Services Engine?

Cisco Identity Services Engine (ISE) ist Ciscos Plattform für Network Access Control und Policy-Durchsetzung. Einfach gesagt: Es ist das System, das die Frage beantwortet “Darf dieses Gerät ins Netzwerk, und wenn ja, mit welchem Zugriff?” — tausendfach pro Minute, für jeden Switch-Port, jede WLAN-Assoziation und jede VPN-Sitzung im Unternehmen.

Dazu fungiert ISE als RADIUS- und TACACS+-Server des Netzwerks. Ein Laptop wird an einen Switch-Port angeschlossen; der Switch entscheidet nichts selbst, er fragt ISE. ISE wertet sein Policy Set aus — wer ist der Benutzer, was ist das Gerät, gehört es dem Unternehmen, ist seine Posture konform, welche Uhrzeit, welcher Standort — und antwortet dem Switch mit einem Autorisierungsergebnis: erlauben, ablehnen, VLAN 40 zuweisen, diese Downloadable ACL anwenden, ins Gast-Portal schicken. Der Switch gehorcht. Das ist der gesamte Entwurf.

ISE-PIC (Passive Identity Connector) ist die abgespeckte Variante: kein RADIUS-Policy-Betrieb, sondern passives Lernen von User-zu-IP-Zuordnungen aus Active Directory, die dann anderen Cisco-Produkten bereitgestellt werden. Auch ISE-PIC ist von dieser Schwachstelle betroffen.

Eine produktive ISE-Installation ist auf Knoten mit Personas verteilt:

PAN (Policy Administration Node) — beherbergt die Administrations-GUI und die Konfigurationsdatenbank; der primäre PAN ist die maßgebliche Quelle für die gesamte Installation
MnT (Monitoring and Troubleshooting Node) — sammelt Logs und Reporting-Daten von allem
PSN (Policy Service Node) — die Arbeitspferde, die RADIUS-/TACACS+-Anfragen der Netzwerkgeräte tatsächlich beantworten
pxGrid Controller — veröffentlicht Identitäts- und Kontextdaten an andere Sicherheitsprodukte (Secure Firewall, Secure Network Analytics, Catalyst Center)

Seit ISE 3.1 stellen diese Knoten ihre REST-Schnittstellen über ein API Gateway bereit, das die ältere ERS-API (historisch auf TCP/9060) und die neuere OpenAPI-Schnittstelle hinter TCP/443 konsolidiert hat. Das Access-Log dieses Gateways ist genau jenes, das Cisco in seinen Indicator-of-Compromise-Hinweisen benennt: ise-kong/access.log. Der Dateiname ist der Hinweis — das Gateway ist eine Kong-Installation, und der verwundbare Endpunkt liegt dahinter.

Typische Einsatzszenarien

802.1X-Authentifizierung kabelgebunden und drahtlos für Unternehmensendpunkte und -benutzer
MAB (MAC Authentication Bypass) für Drucker, Kameras, Zutrittsleser und alles andere, was kein 802.1X spricht
Gast- und BYOD-Onboarding-Portale, inklusive Geräteregistrierung und Zertifikatsausstellung
Posture Assessment — Prüfung von Patch-Stand, Festplattenverschlüsselung und AV-Status vor Vollzugriff
TACACS+ Device Administration — Steuerung und Protokollierung, wer sich an Switches, Routern und Firewalls anmelden und welche Befehle ausführen darf
VPN-Authentifizierung für Cisco Secure Client / AnyConnect, inklusive MFA-Anbindung
Profiling — Fingerprinting und Klassifizierung jedes Geräts im Netzwerk
TrustSec / SGT-Policy — Vergabe von Security Group Tags, auf die nachgelagerte Enforcement Points reagieren
pxGrid-Kontextaustausch mit Firewalls, NDR- und SIEM-Werkzeugen

Warum eine NAC-Kompromittierung anders ist

Die meisten kritischen Schwachstellen verschaffen einem Angreifer einen Brückenkopf, den er anschließend ausbauen muss. Diese hier verschafft ihm die entscheidende Instanz. Man überlege, was auf einem kompromittierten primären PAN liegt oder von dort erreichbar ist:

RADIUS Shared Secrets für jedes Netzwerkgerät im Unternehmen. Das sind die Schlüssel, mit denen ein Gerät autoritativ mit ISE spricht — und ISE autoritativ mit ihm.
Das Active-Directory-Join-Konto. ISE tritt der Domäne bei, um Benutzer zu authentifizieren. Dieses Maschinenkonto ist ein echtes Domänenobjekt mit echten Rechten.
TACACS+-Schlüssel und Device-Administration-Policy — also die Control Plane jedes Switches, Routers und jeder Firewall, die ISE für den Admin-Login nutzt.
Die interne Certificate Authority von ISE. ISE stellt Endpunkten Zertifikate für BYOD und EAP-TLS aus. Wer diese CA kontrolliert, kann ein Zertifikat ausstellen, dem das Netzwerk für 802.1X per Konfiguration vertraut.
Die Autorisierungsrichtlinie selbst. Ein Angreifer, der Policy bearbeiten kann, muss NAC nicht umgehen. Er schreibt einfach eine Regel, die sein Gerät in ein privilegiertes VLAN legt, Posture-Prüfungen dafür deaktiviert und nichts protokolliert.
Die Aufzeichnungen des Monitoring-Knotens — also die Beweise für alles Vorgenannte.

Es besteht ein erheblicher Unterschied zwischen “ein Angreifer ist an der Network Access Control vorbeigekommen” und “ein Angreifer ist die Network Access Control.” Diese Schwachstelle erzeugt den zweiten Fall.

🔍 Technische Analyse

Beschreibung der Schwachstelle

CVE-2026-76460 ist ein Authentication Bypass in einer API, die von Cisco ISE und ISE-PIC bereitgestellt wird. Ciscos Beschreibung der Ursache ist einen Satz lang: Die Schwachstelle “is due to insufficient authentication control on an API endpoint.” Ein Angreifer nutzt sie aus, indem er “a crafted request to an affected API endpoint” sendet, und eine erfolgreiche Ausnutzung erlaubt ihm, “unauthorized access to the affected device by bypassing the web-based management interface” zu erlangen.

Cisco hat weder den Endpunktpfad noch die Struktur des präparierten Requests noch den technischen Mechanismus veröffentlicht, mit dem die Authentifizierung übersprungen wird. Das ist beabsichtigt und angesichts aktiver Ausnutzung ohne öffentlichen PoC vertretbar. Was Cisco sehr wohl veröffentlicht hat, ist die CWE-Klassifizierung, und sie ist das Informativste im gesamten Advisory: CWE-648, Incorrect Use of Privileged APIs.

CWE-648 beschreibt ein spezifisches und wiedererkennbares Fehlermuster. Eine Anwendung besitzt eine interne, privilegierte API — eine, der zugetraut wird, sensible Operationen auszuführen, weil sie ausschließlich von einer anderen vertrauenswürdigen Komponente aufgerufen werden soll, nachdem diese die Authentifizierung erledigt hat. Der Fehler ist nicht, dass die privilegierte API kaputt wäre. Der Fehler ist, dass sie direkt erreichbar ist — von jemandem, der nie durch die prüfende Komponente gegangen ist.

Das ist das klassische Versagensmuster einer Gateway-vorgelagerten Architektur, und ISE hat exakt diese Architektur. Die Authentifizierung der Management Plane wird auf einer Ebene erzwungen, die privilegierten Operationen liegen dahinter, und die Sicherheit des Ganzen beruht auf der Annahme, dass kein Request die zweite Ebene erreichen kann, ohne die erste durchquert zu haben. Wenn eine Routing-Regel, eine Eigenheit der Pfadnormalisierung, ein interner Listener oder schlicht ein Endpunkt, der nie in die geschützte Menge aufgenommen wurde, diese Annahme bricht, antwortet die privilegierte API dem Angreifer direkt — und tut genau das, wofür sie entworfen wurde, für genau den falschen Aufrufer.

Das ist auch der Grund, warum im Advisory “regardless of device configuration” steht. Es gibt kein Feature-Flag zum Abschalten, weil der verwundbare Endpunkt Teil der Plattform ist und nicht Teil eines Features.

Ursachenanalyse

Eine privilegierte API, die ohne die vorgelagerte Authentifizierung erreichbar ist. Gemäß CWE-648: Eine Schnittstelle, die nur von einer bereits authentifizierten, vertrauenswürdigen Komponente aufgerufen werden sollte, kann direkt von einem unauthentifizierten Aufrufer angesprochen werden.
Authentifizierung am Gateway statt an der Operation. Wenn die Prüfung auf einer Ebene liegt und die Fähigkeit auf einer anderen, ist jeder Pfad, der die zweite Ebene ohne die erste erreicht, ein vollständiger Bypass. Einen teilweisen Ausfall gibt es hier nicht.
Ein Endpunkt außerhalb der geschützten Menge. Entweder durch eine Auslassung in der Routenkonfiguration des Gateways oder durch einen internen Listener, der nie externen Verkehr erhalten sollte, hat ein Endpunkt Requests beantwortet, die ihn nie hätten erreichen dürfen.
Keine Defense in Depth an der Operation selbst. Die privilegierte API hat die Identität des Aufrufers nicht eigenständig überprüft. Sie vertraute ihrer Position in der Architektur — und diese Position erwies sich als erreichbar.
Eine Management Plane, die routinemäßig exponiert ist. ISEs Admin-Interface und API Gateway teilen sich TCP/443 mit Portalen, die tatsächlich von Endpunkten erreichbar sein müssen. Die Trennung von “das Gast-Portal muss allen antworten” und “die Admin-API darf fast niemandem antworten” ist operative Disziplin, keine Produktvoreinstellung.
Root-fähige Befehlsausführung hinter dem Bypass. Sobald die Authentifizierung passiert ist, handelt es sich nicht um lesende Administration. Ciscos Advisory-Hinweise und unabhängige Analysen laufen auf dasselbe Ergebnis hinaus: Befehlsausführung mit Root-Rechten auf dem darunterliegenden Betriebssystem.

Angriffsvektor

Der genaue Request ist nicht öffentlich. Das folgende Diagramm zeigt die architektonische Form eines CWE-648-Bypasses gegen eine Gateway-vorgelagerte Management Plane — es ist nicht der Exploit, und der Endpunktpfad unten ist ein Platzhalter.

+---------------------------------------------------------------------+
|  ILLUSTRATIVES ARCHITEKTURDIAGRAMM                                   |
|  Dies ist KEIN funktionsfaehiger Exploit. Cisco hat weder den        |
|  verwundbaren Endpunktpfad noch den praeparierten Request            |
|  veroeffentlicht. <undisclosed> unten ist ein Platzhalter,           |
|  keine reale URI.                                                    |
+---------------------------------------------------------------------+

   VORGESEHENER PFAD (Authentifizierung wird erzwungen)

   Admin ----> TCP/443 ----> API Gateway ----> AuthN-Pruefung ----> OK
                             (ise-kong)             |
                                                    v
                                            Privilegierte API
                                            (Konfiguration, Policy,
                                             Systemoperationen)

   EXPLOIT-PFAD (CVE-2026-76460, CWE-648)

   Angreifer -> TCP/443 -> praeparierter Request -> Privilegierte API
   (ohne Creds)                   |                 (antwortet direkt)
                                  |
                          erreicht die Operation
                          OHNE die Authentifizierungs-
                          pruefung zu durchlaufen
                                  |
                                  v
                    unautorisierter Management-Zugriff
                                  |
                                  v
                    Befehlsausfuehrung als Root auf dem Knoten
                                  |
                                  v
                  RADIUS-Secrets / AD-Join-Konto / interne CA
                  / Autorisierungsrichtlinie / die Logs selbst

Was nicht spekulativ ist, sind das Ergebnis und die Spur, die es hinterlässt. Ciscos Indicator-of-Compromise-Hinweise verweisen Administratoren auf das Access-Log des API Gateways und nennen dummyuser als ausdrücklich nicht abschließendes Beispiel eines verdächtigen Benutzernamens, der dort beobachtet wurde. Das Signal ist die Präsenz irgendeines unerklärten Benutzernamens in diesem Log; dummyuser ist eine Ausprägung davon, keine Signatur, nach der man sucht und dann aufhört.

Das ist ein wirklich nützliches Detail, weil es zeigt, wie die Ausnutzung aus Verteidigersicht aussieht: API-Requests, die das Gateway protokolliert, verknüpft mit einer Benutzeridentität, die in Ihrer Installation nicht existiert. Der Bypass macht den Request nicht unsichtbar. Er macht ihn autorisiert.

Ausnutzung in freier Wildbahn

Das Cisco PSIRT bestätigte aktive Ausnutzung bereits im Advisory zur Erstveröffentlichung am 16. September 2026. Es gab kein Zeitfenster, in dem Verteidiger von der Lücke wussten, bevor Angreifer sie nutzten.
CISA nahm CVE-2026-76460 am 16. September 2026 in den KEV-Katalog auf, also am selben Tag, mit Frist zum 19. September — ein Drei-Tage-Fenster und damit eine der kürzesten Fristen, die CISA vergibt.
Der KEV-Eintrag setzt forensicTriage: Yes unter BOD 26-04. Das verpflichtet Behörden nicht nur zum Patchen, sondern zu einer forensischen Triage der betroffenen Assets. CISA reserviert diese Markierung für Schwachstellen, bei denen sie eine bereits erfolgte Kompromittierung erwartet.
Bekannte Nutzung in Ransomware-Kampagnen: Unknown laut KEV-Eintrag. Das ist eine Aussage über CISAs Sichtbarkeit, nicht darüber, dass Ransomware-Betreiber an einer NAC-Plattform desinteressiert wären.
Kein verifizierter öffentlicher Proof-of-Concept war zum Redaktionsschluss veröffentlicht. Das senkt das kurzfristige Risiko nicht — die Ausnutzung ging der Offenlegung voraus — bedeutet aber, dass der Kreis der Angreifer derzeit kleiner und gezielter ist, als er es sein wird, sobald ein PoC erscheint.
Cisco warnt ausdrücklich, dass IoCs durch die Angreifer entfernt oder verborgen worden sein können. Root auf dem Knoten schließt Root über die Logs ein.

Auch der Kontext ist relevant. ISE steht seit zwei Jahren in Folge im Fokus. 2025 wurden CVE-2025-20281, CVE-2025-20282 und CVE-2025-20337 — allesamt unauthentifizierte RCE, allesamt CVSS 10.0 — im Juni und Juli offengelegt, gefolgt von aktiver Ausnutzung. Ein Angreifer, der 2025 Werkzeuge gegen ISE gebaut hat, hatte jeden Grund, 2026 weiter hinzusehen.

Auswirkungen nach erfolgreicher Ausnutzung

Root auf dem ISE-Knoten. Vollständige Kontrolle über das Betriebssystem unter der Appliance, inklusive Konfigurationsdatenbank und Logging-Subsystem.
Extraktion der RADIUS- und TACACS+-Shared-Secrets für jedes in ISE konfigurierte Netzwerkgerät — die Credentials, die ein Gerät auf der Access-Control-Plane autoritativ machen.
Kompromittierung des Active-Directory-Join-Kontos. ISE hält eine echte Domänenidentität, um Benutzer gegen AD zu authentifizieren.
Kontrolle über die interne CA von ISE. Aus ihr ausgestellte Zertifikate werden von der EAP-TLS-Konfiguration des Netzwerks als vertrauenswürdig behandelt. Ein Angreifer kann sich ein Credential ausstellen, das das Netzwerk per Konstruktion akzeptiert.
Umschreiben der Autorisierungsrichtlinie. Eine Regel, die einer angreifergesteuerten MAC-Adresse Vollzugriff auf ein privilegiertes VLAN gewährt und Posture Assessment deaktiviert, ist eine Zwei-Minuten-Änderung in der ISE-GUI.
Anlegen administrativer Konten in der Installation — für Zugriff, der den Patch überlebt.
Manipulation oder Löschung von Monitoring-Daten auf dem MnT-Knoten — genau jener Daten, mit denen ein Incident Responder den Hergang rekonstruieren würde.
Laterale Bewegung in jeden pxGrid-Consumer — Firewalls, NDR-Plattformen und SIEM-Integrationen, die dem Identitäts-Feed von ISE per Entwurf vertrauen.
Persistenz, die von Konfiguration nicht zu unterscheiden ist. Eine bösartige Autorisierungsregel ist keine Malware. Sie ist ein Policy-Objekt — in einem Produkt, dessen Aufgabe es ist, Policy-Objekte zu halten.

📊 Impact-Bewertung

Unmittelbare Auswirkungen

Unauthentifizierte, entfernte Kompromittierung ohne Benutzerinteraktion eines Tier-0-Identitätssystems
Dreitägige CISA-Frist mit verpflichtender forensischer Triage
Kein Workaround — die einzige Remediation im Produkt ist der Patch; alles andere ist Eindämmung auf Netzwerkebene
Detektionsunsicherheit per Konstruktion: Die IoC-Hinweise des Advisories warnen selbst davor, dass lokale Beweise zerstört sein könnten
Ciscos Empfehlung bei Verdacht ist Neuinstallation, nicht Bereinigung — eine Operation mit realer Ausfallzeit auf einem System, ohne das das Netzwerk nicht funktioniert

Betroffene Versionen

Release	Status	Erstes fehlerbereinigtes Release
ISE / ISE-PIC 3.0	Verwundbar — End of Support	Keines. Migration auf ein unterstütztes Release
ISE / ISE-PIC 3.1	Verwundbar	3.1 Patch 12
ISE / ISE-PIC 3.2	Verwundbar	3.2 Patch 11
ISE / ISE-PIC 3.3	Verwundbar	3.3 Patch 12
ISE / ISE-PIC 3.4	Verwundbar	3.4 Patch 7
ISE / ISE-PIC 3.5	Verwundbar	3.5 Patch 4

Cisco stellt fest, dass die Schwachstelle diese Releases unabhängig von der Gerätekonfiguration betrifft. Es gibt keine “wir nutzen dieses Feature nicht”-Ausnahme.

Betroffene Umgebungen

Jedes Unternehmen, das Cisco ISE für 802.1X, VPN oder Device Administration einsetzt — das ist ein sehr großer Anteil mittlerer und großer Cisco-basierter Netzwerke
Installationen, deren Admin-Interface oder API Gateway aus nicht vertrauenswürdigen Netzsegmenten erreichbar ist, einschließlich aus Benutzer-VLANs, nicht nur aus dem Internet
Organisationen mit ISE 3.0, die ein verwundbares, nicht behebbares End-of-Support-System betreiben, das die Netzwerkzugriffsrichtlinie hält
Managed Service Provider und Systemintegratoren, die ISE für Kunden betreiben und remote darauf zugreifen
Umgebungen, in denen ISE der Active-Directory-Domäne beigetreten ist — also praktisch alle — wo die Kompromittierung des Knotens in die Identitätslandschaft hineinreicht
Alle, die das Cisco-Bündel vom 17. September zurückgestellt haben, weil zwanzig weitere CVEs darin waren und diese eine wie ein weiterer Listeneintrag aussah

Angreiferprofile

Staatsnahe Intrusion Sets, für die eine NAC-Plattform nahezu die ideale Position ist: dauerhaft, privilegiert, vertrauenswürdig und auf dem Authentifizierungspfad jedes Geräts im Unternehmen
Access Broker, die eine ISE-Kompromittierung in dauerhaften Netzwerkzugriff auf Policy-Ebene umwandeln und genau so verkaufen können
Ransomware-Affiliates, denen eine Autorisierungsinstanz nützt, die ihren Werkzeugen den Weg in Segmente öffnet, die eigentlich isoliert sein sollten
Opportunistische Scanner, die heute mangels öffentlichem PoC kein Faktor sind — und es in dem Moment werden, in dem einer existiert

🛡️ Mitigationsstrategien

Sofortmaßnahmen (Priorität 1)

1. Exakte Version und Patch-Stand jedes Knotens feststellen.

Der Patch-Stand ist knotenspezifisch und muss auf jedem Knoten bestätigt werden, nicht nur auf dem primären PAN. Aus der ISE-CLI im EXEC-Modus:

# Zeigt das ADE-OS-Release und die installierte Cisco-ISE-Version.
show version

# Zeigt Version, Build-Datum und Installationsdatum der ISE-Anwendung.
# Der Anwendungsname fuer Cisco ISE lautet "ise".
show application version ise

In der GUI ist die maßgebliche Ansicht der installierten Patches — inklusive der Information, welche Knoten sie haben — unter Administration > System > Maintenance > Patch Management. Sie erfordert die Rolle Super Admin oder System Admin.

2. Vor dem Patchen sichern.

# Konfigurationsbackup in ein zuvor konfiguriertes Repository schreiben.
# "myrepository" durch Ihren Repository-Namen ersetzen, eigenen Schluessel waehlen.
# "plain" bedeutet, dass der Schluessel im Klartext in dieser Zeile steht;
# verwenden Sie "hash", wenn Sie einen bereits gehashten Schluessel uebergeben.
backup ise-cfg-pre-patch repository myrepository ise-config encryption-key plain <IhrSchluessel>

3. Den fehlerbereinigten Patch installieren.

Beim Patchen über die GUI wird zuerst der primäre PAN und danach werden die übrigen Knoten in fester Reihenfolge installiert. Beim Patchen über die CLI steuern Sie die Knotenreihenfolge selbst — weshalb große Installationen diesen Weg bevorzugen:

# Patch-Bundle aus einem konfigurierten Remote-Repository installieren.
# Den exakten Dateinamen des von Cisco heruntergeladenen Patches sowie
# den auf diesem Knoten konfigurierten Repository-Namen einsetzen.
patch install ise-patchbundle-3.4.0.608-Patch7-<build>.SPA.x86_64.tar.gz myrepository

# Anschliessend pruefen, ob der Knoten den erwarteten Patch-Stand meldet.
show version

Zielen Sie auf das erste fehlerbereinigte Release Ihres Trains: 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 oder 3.5 Patch 4. Wenn Sie auf 3.0 sind, gibt es keinen Patch — planen Sie eine Migration und behandeln Sie den ACL-Schritt unten als dauerhafte Maßnahme statt als vorübergehende.

4. Den Zugriff auf die Management Plane einschränken — und die Einschränkung nach dem Patchen beibehalten.

Cisco stellt ausdrücklich fest, dass es keinen Workaround gibt, empfiehlt aber Infrastructure Access Control Lists, um den Management-Verkehr zum Gerät zu begrenzen. Das behebt die Lücke nicht; es entfernt den Weg des Angreifers zu ihr. Auf einem IOS-/IOS-XE-Gerät vor ISE:

! Cisco IOS / IOS-XE. HTTPS zum ISE-Knoten nur aus dem Management-Netz
! erlauben, von ueberall sonst verweigern, und den uebrigen Verkehr
! (RADIUS, TACACS+, Portale) den folgenden Zeilen ueberlassen.
! 10.10.0.0/24 = Management-Netz, 10.20.0.10 = ISE-Knoten.
ip access-list extended ACL-ISE-MGMT-IN
 permit tcp 10.10.0.0 0.0.0.255 host 10.20.0.10 eq 443
 deny   tcp any host 10.20.0.10 eq 443
 permit ip any any
!
interface GigabitEthernet0/0/1
 ip access-group ACL-ISE-MGMT-IN in

5. Feststellen, ob das Interface von außen überhaupt erreichbar war.

# Diesen Befehl von einem EXTERNEN Host ausfuehren, nicht aus dem Management-Netz.
# Jeder HTTP-Status ausser einem Verbindungsfehler bedeutet, dass das
# Admin-Interface einem Request von dieser Netzposition geantwortet hat.
curl -sk -o /dev/null -w '%{http_code}\n' https://ise.example.com/admin/

# Pruefen, welche ISE-Dienstports von einer bestimmten Netzposition antworten.
# 443 = Admin-GUI und API Gateway, 9060 = alte ERS-API,
# 9070 = OpenAPI-Port zwischen Knoten. -Pn ueberspringt die Host-Discovery.
nmap -Pn -p 443,9060,9070 ise.example.com

Detektionsmaßnahmen

Beginnen Sie mit dem Log, das Cisco benennt. Führen Sie dies auf jedem Knoten der Installation aus, nicht nur auf dem primären PAN:

# Ciscos eigene IoC-Pruefung. "dummyuser" ist ein NICHT ABSCHLIESSENDES
# Beispiel eines verdaechtigen Benutzernamens -- jeder hier zurueckgegebene
# Eintrag rechtfertigt eine Untersuchung.
show logging application ise-kong/access.log | include dummyuser

Da dummyuser ein Beispiel und keine Signatur ist, ist die nützlichere Suche die nach jedem Benutzernamen in diesem Log, den Sie nicht zuordnen können:

# Das Access-Log des API Gateways lesen und durchblaettern. Die dort
# auftauchenden Identitaeten mit Ihren tatsaechlichen Administrator- und
# API-Dienstkonten abgleichen -- alles Unbekannte ist der Fund.
show logging application ise-kong/access.log

# Dem Log waehrend der Arbeit live folgen, um laufende Aktivitaet zu sehen.
# Mit Strg+C beenden.
show logging application ise-kong/access.log tail

Dann hören Sie auf, dem System zu vertrauen. Cisco warnt, dass Indikatoren durch den Angreifer entfernt worden sein können — die wichtigsten Beweise liegen also woanders. Ziehen Sie Firewall-, Proxy-, NetFlow- und DNS-Aufzeichnungen zu den IP-Adressen der ISE-Knoten und suchen Sie nach Verkehr, den eine Appliance nicht erzeugen sollte:

# Splunk SPL -- ausgehende Sitzungen von ISE-Knoten zu externen Zielen.
# Index, Feldnamen und ISE-Adressen an Ihre Umgebung anpassen.
index=firewall src_ip IN ("10.20.0.10","10.20.0.11")
  NOT (dest_ip="10.0.0.0/8" OR dest_ip="172.16.0.0/12" OR dest_ip="192.168.0.0/16")
| stats count AS sessions, sum(bytes_out) AS total_bytes_out
        BY src_ip, dest_ip, dest_port
| sort - total_bytes_out

# Microsoft Sentinel / Defender KQL -- dieselbe Frage fuer Firewall-Logs,
# die nach CommonSecurityLog normalisiert sind. Adressliste anpassen.
CommonSecurityLog
| where SourceIP in ("10.20.0.10", "10.20.0.11")
| where ipv4_is_private(DestinationIP) == false
| summarize Sessions = count(), BytesOut = sum(SentBytes)
          by SourceIP, DestinationIP, DestinationPort
| order by BytesOut desc

In der Installation selbst gilt die Suche der Policy, die niemand geschrieben hat. Dafür gibt es keinen einzelnen Befehl; es braucht einen Menschen, der weiß, wie die Konfiguration aussehen soll:

Administratorkonten unter Administration > System > Admin Access > Administrators, die keiner Person und keinem dokumentierten Dienst zuzuordnen sind
Änderungen an Autorisierungsrichtlinien und Policy Sets — besonders neue Regeln mit freizügigen Ergebnissen oder Regeln, die eine bestimmte MAC oder Identität in ein privilegiertes VLAN oder SGT legen
Posture-Ausnahmen, die für einzelne Endpunkte oder Gruppen hinzugefügt wurden
Von der internen ISE-CA ausgestellte Zertifikate, die keinem bekannten Onboarding-Vorgang entsprechen
Neue oder geänderte Netzwerkgeräte-Einträge und RADIUS Shared Secrets
pxGrid-Subscriber, die Sie nicht autorisiert haben
Repository-Definitionen und geplante Backups, die auf Ziele zeigen, die Ihnen nicht gehören — ein sauberer Exfiltrationskanal, der wie Administration aussieht
Lücken in den MnT-Logs: Ein Zeitraum ganz ohne Aufzeichnungen ist selbst ein Fund

Wenn Sie etwas finden

Ciscos Empfehlung bei Verdacht auf Kompromittierung ist eindeutig und unbequem: Betroffene Knoten neu installieren und die Konfiguration aus einem Backup wiederherstellen, das vor der vermuteten Kompromittierung erstellt wurde. Die Bereinigung einer gerooteten Appliance im laufenden Betrieb wird nicht als Option angeboten — aus dem guten Grund, dass sich das Ergebnis mit den Logs der Appliance selbst nicht verifizieren lässt.

Behandeln Sie darüber hinaus alles, was ISE gehalten hat, als offengelegt:

Zuerst externe Beweise sichern — Firewall-, NetFlow-, Proxy-, DNS- und SIEM-Daten, die der Angreifer nicht erreichen konnte.
Jedes RADIUS- und TACACS+-Shared-Secret rotieren, unternehmensweit. Das ist disruptiv, und genau darum geht es.
Das Active-Directory-Join-Konto zurücksetzen sowie seine Rechte und jüngsten Aktivitäten prüfen.
Zertifikate der internen ISE-CA neu ausstellen oder widerrufen und überprüfen, was das Netzwerk für EAP-TLS als vertrauenswürdig behandelt.
Administrator-Credentials, API-Dienstkonten und pxGrid-Credentials rotieren.
Die wiederhergestellte Konfiguration gegen das letzte bekannte gute Backup diffen, Regel für Regel. Eine einzige hinzugefügte Autorisierungsregel ist die gesamte Payload.
Nachgelagert untersuchen — pxGrid-Consumer, angebundene MDM-Systeme und alles, was sich während des Expositionsfensters über ISE authentifiziert hat.

Langfristige Sicherheitsverbesserungen

Nehmen Sie die ISE-Management-Plane aus jedem Netz, das sie nicht braucht. Admin-GUI und API Gateway sollten aus einem Management-Segment erreichbar sein und sonst nirgendwoher. Endpunktseitige Portale können bleiben, wo sie sind; sie sind eine andere Funktion auf demselben System und verdienen eine andere Exposition.
Behandeln Sie ISE als Tier-0-Asset. Es hält Domänen-Credentials, eine Certificate Authority und die Richtlinie, die den Netzwerkzugriff regelt. Es gehört in dasselbe Isolations-, Monitoring- und Change-Control-Regime wie ein Domain Controller — nicht in die Schublade “Netzwerk-Hardware”.
Schicken Sie ISE-Logs in Echtzeit von der Appliance weg. Die schädlichste Eigenschaft dieser Schwachstelle ist, dass der Angreifer die Kontrolle über die Beweise erbt. Zentralisiertes, append-only geführtes Logging macht aus “wir haben gepatcht” ein “wir wissen es”.
Alarmieren Sie auf ISE-Konfigurationsänderungen, nicht nur auf ISE-Verfügbarkeit. Die meisten Organisationen überwachen, ob ISE RADIUS beantwortet. Weit weniger alarmieren, wenn sich eine Autorisierungsrichtlinie außerhalb eines Change-Fensters ändert — also genau beim Post-Exploitation-Signal.
Halten Sie ein offline gelagertes, verifiziertes Konfigurationsbackup und testen Sie die Wiederherstellung. Ciscos Remediationsweg bei Kompromittierung ist die Wiederherstellung aus dem Backup; ein nie getestetes Backup ist ein nie getesteter Plan.
Kommen Sie von ISE 3.0 herunter. Eine nicht behebbare CVSS 10.0 auf dem System, das entscheidet, wer in Ihr Netzwerk darf, ist kein Risiko, das sich dauerhaft akzeptieren lässt.
Lesen Sie gebündelte Hersteller-Offenlegungen richtig. Das Cisco-Release vom 17. September enthielt 20+ CVEs, allein vier davon CVSS 10.0 in ISE. Bündel komprimieren Aufmerksamkeit; Angreifer verlassen sich darauf.
Abonnieren Sie Cisco-PSIRT-Benachrichtigungen und leiten Sie sie an eine Person mit Befugnis zur Notfall-Patch-Planung. Eine dreitägige CISA-Frist ist kein Zeitplan für ein Change Advisory Board.

⚠️ Warum ist das kritisch?

CVSS 10.0 mit Scope Change. Netzwerkvektor, geringe Komplexität, keine Privilegien, keine Benutzerinteraktion, vollständige Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit — und die kompromittierte Komponente kontrolliert andere.
Sie wurde ausgenutzt, bevor sie bekannt war. Cisco meldete aktive Ausnutzung bereits bei der Erstveröffentlichung. Es gab kein sicheres Intervall.
Jede Installation ist betroffen. “Regardless of device configuration” streicht den üblichen Triage-Schritt, bei dem sich die Hälfte der Landschaft als nicht exponiert herausstellt.
Es gibt keinen Workaround. ACLs schränken den Pfad ein; sie beheben den Fehler nicht. Alles, was das Interface erreicht, kann es weiterhin ausnutzen.
Der Wirkungsradius ist die Access Control Plane. RADIUS-Secrets, das AD-Join-Konto, die interne CA und die Autorisierungsrichtlinie des gesamten Netzwerks liegen hinter diesem Bypass.
Die Persistenz sieht aus wie Konfiguration. Eine bösartige Autorisierungsregel ist ein legitimes Policy-Objekt in einem Policy-Produkt. Keine EDR schlägt an, weil es nichts anzuschlagen gibt.
CISA hat eine forensische Triage verlangt. Der KEV-Eintrag sagt nicht nur patchen. Er sagt geht nachsehen — das deutlichste verfügbare Signal, dass CISA eine bereits erfolgte Kompromittierung erwartet.
Drei Tage. Aufgenommen am 16. September, fällig am 19. September. Dieses Fenster vergibt CISA nicht für theoretische Risiken.
ISE 3.0 bekommt nichts. Ein Teil der installierten Basis hat eine maximal bewertete, aktiv ausgenutzte Schwachstelle ganz ohne Herstellerfix.
Es ist das zweite Jahr in Folge. Drei unauthentifizierte CVSS-10.0-RCEs in ISE im Jahr 2025, vier weitere CVSS-10.0-ISE-Lücken in derselben Woche wie diese hier. Die Angriffsfläche wird dauerhaft untersucht.

📅 Zeitleiste und Offenlegung

2025-06-25 — Cisco legt CVE-2025-20281 und CVE-2025-20282 offen, unauthentifizierte RCE in ISE, beide CVSS 10.0
2025-07-16 — CVE-2025-20337 offengelegt, ebenfalls CVSS 10.0 unauthentifizierte RCE; Ausnutzungsversuche folgen, die Lücken landen im CISA-KEV-Katalog
2026-09-14 — CVE-2026-76461 (Cisco Secure Email Gateway, unauthentifizierte SQL Injection bis Root, CVSS 9.8) wird in den CISA-KEV-Katalog aufgenommen, Frist 2026-09-17
2026-09-16, 16:00 GMT — Cisco veröffentlicht das Advisory cisco-sa-ISE-ABP-VNSW7Tn5 zu CVE-2026-76460 und bestätigt aktive Ausnutzung; Patches für 3.1 bis 3.5 sind verfügbar
2026-09-16 — CISA nimmt CVE-2026-76460 in den KEV-Katalog auf, Frist 2026-09-19, forensische Triage erforderlich, Ransomware-Nutzung Unknown
2026-09-17 — Cisco veröffentlicht eine gebündelte Offenlegung von 20+ CVEs über ISE, Secure Firewall Management Center, Nexus Dashboard und ASA/FTD, darunter vier weitere CVSS-10.0-Lücken in ISE (CVE-2026-20130, CVE-2026-20192, CVE-2026-76423 sowie CVE-2026-76460 selbst); die Berichterstattung zu CVE-2026-76460 weitet sich aus
2026-09-19 — CISA-BOD-26-04-Frist für zivile US-Bundesbehörden
2026-09-22 — Es wurde kein verifizierter öffentlicher Proof-of-Concept veröffentlicht

📚 Ressourcen und Referenzen

🤝 SEKurity Unterstützt Sie

In diesen Beiträgen zeichnet sich ein Muster ab, das sich kaum noch ignorieren lässt. Der VPN-Konzentrator, das Build-Repository, die MSP-Konsole — und jetzt die Network-Access-Control-Plattform. Vier Wochen, vier Systeme, deren gesamtes Wertversprechen darin besteht, von allem anderen als vertrauenswürdig behandelt zu werden. Sie sind in den meisten Organisationen die am wenigsten getestete Software, gerade weil sie Infrastruktur sind: Sie funktionieren, sie sehen nach Cisco aus, und niemand plant eine Prüfung gegen das System, das entscheidet, ob die Prüfer überhaupt ins Netzwerk kommen.

Die praktischen Fragen zu ISE sind kurz, und die meisten Organisationen können sie nicht schnell beantworten. Auf welchem Patch-Stand ist jeder Knoten — nicht der primäre PAN, sondern jeder? Welche Netzsegmente erreichen das Admin-Interface und das API Gateway, und wer hat das zuletzt überprüft? Existieren Ihre ISE-Logs irgendwo außerhalb von ISE? Würden Sie eine Änderung an der Autorisierungsrichtlinie um 03:00 Uhr an einem Sonntag bemerken? Und falls die Prüfung von ise-kong/access.log einen unbekannten Benutzernamen zurückgäbe: Haben Sie ein Backup, das alt genug und sauber genug für eine Wiederherstellung ist?

Wir testen Management Planes so, wie Angreifer sie angehen — von der Netzposition aus, die ein Angreifer tatsächlich hätte, gegen die Appliance, die niemand für ein Testfenster abschalten möchte. Wenn Ihre ISE-Installation noch nie aus einem Benutzer-VLAN heraus betrachtet wurde, ist das die Lücke, die sich vor der nächsten CVSS 10.0 schließen lässt. Nach derzeitigem Stand wird das Warten darauf nicht lange dauern.

Unsere Leistungen

Penetration Testing: Webanwendungen, Mobile Apps (Android & iOS), SAP-Systeme, Active Directory
Groß angelegte Angriffe: Perimeter-Tests, IT-Infrastruktur-Tests, Red-Team-Einsätze
Security Awareness: Phishing-Kampagnen, Hacking-Demonstrationen

Handeln Sie jetzt — bevor es Angreifer tun.

Kontakt:

Website: www.sekurity.de

Anfragen: www.sekurity.de/kontakt

LinkedIn: SEKurity GmbH

Ihr SEKurity Team — Your Trusted Adversaries

Die Sicherheit Ihrer Netzwerkzugriffs-Infrastruktur ist unser Antrieb.

Quellen

Cisco Security Advisory — Cisco Identity Services Engine Authentication Bypass Vulnerability (cisco-sa-ISE-ABP-VNSW7Tn5) — CVSS-3.1-Vektor AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, CWE-648, Bug-ID CSCww39530, Erstveröffentlichungsdatum, Tabelle der fehlerbereinigten Releases, der ise-kong/access.log-IoC-Befehl, die “no workarounds”-Aussage, iACL-Mitigation, Empfehlung zur Neuinstallation
CISA — Known Exploited Vulnerabilities Catalog — KEV-Eintrag zu CVE-2026-76460: aufgenommen 2026-09-16, Frist 2026-09-19, CWE-648, Ransomware-Nutzung Unknown, forensicTriage: Yes; sowie CVE-2026-76461, aufgenommen 2026-09-14, Frist 2026-09-17
The Hacker News — Cisco Warns of New Zero-Day ISE Auth Bypass (CVSS 10.0) Exploited in Active Attacks — der wörtliche IoC-Befehl, KEV-Daten, verwandte ISE- und Secure-Email-Gateway-CVEs derselben Woche
Help Net Security — Unauthenticated attackers are bypassing Cisco ISE’s management interface (CVE-2026-76460) — betroffener Release-Bereich, fehlerbereinigte Patch-Stände, Hinweis zur Log-Prüfung je Knoten, Korrelation mit externen Netzwerk- und Firewall-Logs
SecurityWeek — Active Exploitation Triggers Emergency Patch for Cisco ISE Zero-Day — Befehlsausführung auf Root-Ebene, Fähigkeit der Angreifer, IoCs zu verbergen oder zu löschen, Advisory-Referenz
Qualys ThreatPROTECT — Cisco ISE Vulnerability (CVE-2026-76460) — End-of-Life-Status von ISE 3.0, KEV-Daten, Tabelle der fehlerbereinigten Versionen, QID 317886
SOC Prime — CVE-2026-76460: Cisco ISE Zero-Day Exploited — Hunting-Indikatoren über das Herstellerbeispiel hinaus, Korrelation externer Telemetrie, Hinweise zu Neuinstallation und Credential-Rotation
Cybersecurity News — Cisco Warns of Critical ISE 0-Day Vulnerability Exploited in Attacks — Root-Rechte als Ergebnis, Credential-Diebstahl und Vorbereitung lateraler Bewegung, vorübergehender Charakter der iACL-Mitigation
securityonline.info — Weekly CVE Report: 10 Exploited Flaws (Sept 14-20, 2026) — die Wochenliste, auf deren Basis dieses Thema ausgewählt wurde, Exploitation-Status von CVE-2026-76460 und CVE-2026-76461
Cisco ISE CLI Reference Guide, Release 3.4 — Cisco ISE CLI Commands in EXEC Show Mode — Syntax von show version, show application version, show logging application
Cisco ISE CLI Reference Guide, Release 3.3 — Cisco ISE CLI Commands in EXEC Mode — Syntax von patch install und backup
Cisco ISE Upgrade Guide, Release 3.4 — Install Latest Patch — der GUI-Pfad Administration > System > Maintenance > Patch Management, erforderliche Admin-Rollen, Knotenreihenfolge bei GUI vs. CLI
Cisco ISE Administrator Guide, Release 3.1 — Basic Setup — das mit ISE 3.1 eingeführte API Gateway, ERS auf TCP/9060 und OpenAPI auf TCP/443 und 9070
Cisco — Cisco Identity Services Engine Unauthenticated Remote Code Execution Vulnerabilities (CVE-2025-20281 / CVE-2025-20282 / CVE-2025-20337) — die CVSS-10.0-Serie in ISE aus 2025 als historischer Kontext
EntryZero — Top 5 Hacker-relevante Schwachstellen — wöchentliches Schwachstellen-Briefing, konsultiert zur Themenauswahl

InSEKurity of the Week (CW38/2026): Cisco ISE Authentication Bypass ueber Privileged API (CVE-2026-76460)