Cisco SD-⁠WAN Manager: aktiv ausgenutzte Authentifizierungslücke – korrigierten Release einspielen

Cisco meldet die aktive Ausnutzung einer Authentifizierungslücke im Catalyst SD-⁠WAN Manager (CVE-⁠2026-⁠76504). Angreifer können die Schwachstelle aus der Ferne und ohne gültiges Benutzerkonto ausnutzen, um Administratorrechte zu erlangen. Betroffen sind Installationen unabhängig von ihrer Konfiguration.

Der Angriff zielt auf die API des Managers

Catalyst SD-⁠WAN Manager, früher als SD-⁠WAN vManage bekannt, verwaltet SD-⁠WAN-⁠Umgebungen. Ein erfolgreicher Angriff auf die Verwaltungsplattform betrifft deshalb nicht nur einen einzelnen Arbeitsplatzrechner: Die Lücke kann einem Angreifer Administratorrechte auf dem Manager verschaffen.

Cisco beschreibt einen Fehler in der sitzungsbasierten Authentifizierung einer API. Eine fehlerhafte Behandlung der URI-⁠Kodierung in einer HTTP-⁠Anfrage ermöglicht es, eine Zugriffskontrolle für einen bestimmten API-⁠Endpunkt zu umgehen. Für den Angriff wird eine speziell präparierte Anfrage an die API des betroffenen Systems gesendet. Ein Benutzerkonto ist dafür nicht erforderlich.

Auch eine besondere Konfiguration ist laut Cisco keine Voraussetzung für die Betroffenheit. Eine Installation lässt sich daher nicht allein aufgrund ihrer Konfiguration als sicher einstufen. Für die Priorisierung zählt der tatsächlich installierte Release-⁠Zweig.

Die Korrektur richtet sich nach dem Release-⁠Zweig

Cisco nennt für die betroffenen Zweige folgende korrigierte Versionen:

| Release-⁠Zweig | Erster korrigierter Release |
|—|—|
| Älter als 20.9 | Auf einen korrigierten Release migrieren |
| 20.9 | 20.9.10.1 |
| 20.12 | 20.12.8.2 |
| 20.15 | 20.15.6.1 |
| 20.18 | 20.18.4.1 |
| 26.1 | 26.1.2.1 |
| 26.2 | 26.2.1 |

Ordnen Sie Ihre Installation zuerst dem passenden Release-⁠Zweig zu und vergleichen Sie den installierten Stand mit der jeweiligen Korrektur. Für Versionen älter als 20.9 nennt Cisco keinen behobenen Stand innerhalb dieses Zweigs, sondern die Migration auf einen korrigierten Release. Ein Update auf eine beliebige neuere Versionsnummer ist damit kein ausreichender Nachweis: Entscheidend ist, ob der konkrete Zweig den Fix enthält.

Da die Lücke bereits ausgenutzt wird, sollte die Aktualisierung nicht bis zum nächsten regulären Wartungsfenster warten. Planen Sie den Wechsel auf den korrigierten Stand für den tatsächlich eingesetzten Zweig ein. Die Meldung, dass die Konfiguration keine Rolle spielt, ist besonders wichtig für Umgebungen, in denen die Betroffenheit sonst anhand einzelner Einstellungen ausgeschlossen würde.

Protokolle auf konkrete Indikatoren prüfen

Cisco nennt `%6a` als Indikator für schädliche Anfragen. Dabei handelt es sich um die URI-⁠kodierte Darstellung des Zeichens „j“. Für die Prüfung auf mögliche Angriffsversuche sind laut Cisco Einträge zu `j_security_check` relevant, wenn sie von unbekannten oder nicht autorisierten IP-⁠Adressen stammen.

Die genannten Protokolle liegen unter folgenden Pfaden:

• `serviceproxy-access.log` unter `/var/log/nms/containers/service-proxy`
• `vmanage-server.log` unter `/var/log/nms/`

Solche Einträge sind ein konkreter Anlass für eine weitergehende Untersuchung, aber für sich genommen kein Beweis für eine erfolgreiche Übernahme. Behandeln Sie die Prüfung deshalb als eigene Aufgabe und nicht als Ersatz für das Update. Ebenso beantwortet ein korrigierter Release nicht rückwirkend die Frage, ob die Installation zuvor angegriffen wurde.

Bei Verdacht die Untersuchung eskalieren

Cisco empfiehlt, bei einem möglichen Kompromiss einen Fall beim Cisco TAC zu eröffnen. Für die Unterstützung sollen zunächst Admin-⁠Tech-⁠Dateien gesammelt werden. Verdächtige Einträge sollten daher in die weitere Klärung einfließen, statt sie allein anhand eines einzelnen Protokolltreffers als bestätigten Angriff oder als Entwarnung zu werten.

Die sinnvolle Reihenfolge ist klar: Release-⁠Zweig feststellen, auf den dafür korrigierten Stand aktualisieren und parallel die genannten Protokollindikatoren prüfen. Gibt es verdächtige Einträge, beziehen Sie den Cisco TAC ein und stellen Sie die angeforderten Admin-⁠Tech-⁠Dateien bereit.

Quellen: BleepingComputer – „Cisco warns of new SD-⁠WAN zero-⁠day exploited in attacks“ (https://www.bleepingcomputer.com/news/security/cisco-warns-of-new-sd-wan-authentication-bypass-zero-day-exploited-in-attacks/)