Donnerstag, 1. Oktober 2026, später Nachmittag. Auf dem Patch-Board steht eine Zeile, die gestern noch fehlte: Cisco Catalyst SD-WAN Manager, aufgenommen in den KEV-Katalog der CISA, Due Date Samstag. Zwei Tage. Am Tisch fällt eine kurze Frage. Wie viele Manager haben wir, und welche sieht das Internet?

Stille. Jemand sagt, das stehe im Wiki. Das Wiki kennt den Umzug des Rechenzentrums nicht. Jemand anderes sagt, die Netzwerkabteilung wisse das. Die Netzwerkabteilung hat Urlaub, und ihre Vertretung weiß es nicht.

Das ist eine Redaktionslage, kein beobachteter Vorfall. Sie ist trotzdem realistisch genug, um daran zu arbeiten. Der Plot Twist steht im Advisory von Cisco: Es gibt keine Workarounds. Der Manager steht bis Samstag auf dem Board oder er steht exponiert.

Spoiler: Der Patch ist der kleinere Teil des Problems. Er schließt nach vorn. Ob vorher schon etwas passiert ist, beantwortet er nicht. Ohne Exposure-Inventar und ohne Triage-Auftrag ist „bis Samstag“ keine Planung. Es ist Hoffnung. Hoffnung hat kein Wartungsfenster.

Dieser Text auf digital-magazin.de geht den Weg Stück für Stück: Was CISA und Hersteller tatsächlich sagen, wo die Meldungen schweigen und was ein Betrieb bis Samstag organisatorisch auf den Tisch legen muss. Technik zum Nachstellen finden Sie hier nicht. Es geht um Zuständigkeiten, Listen und die unbequeme Frage nach der Zeit vor dem Patch.

Was der KEV-Eintrag der CISA sagt – und was nicht

Am 30. September 2026 hat die CISA einen Alert veröffentlicht. Der Inhalt in einem Satz: Die Behörde hat ihren Katalog bekannt ausgenutzter Schwachstellen (KEV) um einen Eintrag ergänzt, nach eigener Angabe auf Basis von Belegen für aktive Ausnutzung. Die CVE heißt CVE-2026-76504. Das Produkt: Cisco Catalyst SD-WAN Manager.

Der Alert trägt außerdem einen Standardsatz über den Schwachstellentyp. Sinngemäß: Diese Art von Schwachstelle sei ein häufiger Angriffsvektor für böswillige Akteure und bringe deutliche Risiken für die Bundesverwaltung der USA mit sich. Das ist CISA-Standardformulierung über den Typ. Einen zweiten konkreten Fall nennt der Alert nicht, und wir erfinden keinen. Den offiziellen Typnamen lassen wir hier weg. Für die Verteidigung braucht es ihn nicht.

Jetzt das Pikante daran. Der Alert nennt kein Datum als Due Date. Kein Stichtag im Text, keine Frist im Absatz. Das ist eine Lücke des Alerts, kein Widerspruch, den wir glätten. Wer nur die Meldung liest, weiß: aufgenommen, ausgenutzt, Handlungsbedarf. Bis wann, steht dort nicht.

In der Praxis sieht das so aus: Das Security-Team liest den Alert am späten Abend, schreibt eine Zeile in den Chat und nimmt an, der Betrieb kenne den Termin. Der Betrieb liest nur die Ticketqueue. Das Datum liegt in keiner von beiden. Wenig überraschend wird aus „kein Termin genannt“ dann „kein Termin vorhanden“.

Ein Termin existiert. Er steht nur woanders. Wie sich solche Einträge im Alltag in eine belastbare Reihenfolge bringen lassen, ist ein eigenes Thema, zu dem es Überlegungen zur Priorisierung nach KEV an anderer Stelle gibt. Hier geht es um diesen einen Eintrag.

Der Katalog nennt Samstag, die Redaktion rechnet

Das Datum steht im KEV-Katalog selbst. Katalogstand 30. September 2026. Der Eintrag zu CVE-2026-76504 nennt als Hersteller Cisco, als Produkt Catalyst SD-WAN Manager, als Aufnahmedatum den 30. September 2026 und als Due Date den 3. Oktober 2026.

Zwei weitere Felder lohnen den Blick. Das Feld forensicTriage steht auf Yes. Das ist ein Katalogfeld, keine Anleitung. Es markiert, dass hier mehr erwartet wird als ein Patch. Das Feld zur Nutzung in Ransomware-Kampagnen steht auf Unknown. Unknown heißt nicht Nein. Es heißt: Dazu liegt nichts vor.

Die verlangte Maßnahme lautet sinngemäß: Mitigations gemäß Herstelleranweisung, im Einklang mit BOD 26-04 und den dort genannten Erwartungen an die Forensics-Triage. Sind Mitigations nicht verfügbar, folgen Betreibende den anwendbaren Vorgaben aus BOD 26-04 für Cloud-Dienste oder nutzen das Produkt nicht weiter. Und: Betreibende bewerten die Internet-Exposition jedes Assets.

Dieser letzte Satz ist der eigentliche Auftrag. Er lässt sich mit keiner Versionsnummer abhaken. Er verlangt eine Antwort pro Instanz, mit Namen und Quelle.

Zu den „zwei Tagen“: Das ist Redaktionsrechnung, kein CISA-Wortlaut. Heute ist Donnerstag, 1. Oktober 2026. Das Due Date ist Samstag, 3. Oktober 2026. Rechnen Sie Freigaben, Rückfragen und das Wartungsfenster heraus, bleibt weniger, als der Kalender zeigt.

Dazu kommt: Ein Termin, der auf ein Wochenende fällt, erzwingt die Entscheidung am Donnerstag. Wer sie bis dahin nicht trifft, trifft sie zufällig. Am Samstag sind Zuständige im Zweifel nicht erreichbar, Dienstleistende haben Bereitschaft statt Budget, und die Person mit der Berechtigung für den Change sitzt im Zug.

Cisco SD-WAN Manager: keine Workarounds, aber eine Mitigation

Das Cisco-Advisory erschien am 30. September 2026 um 13:00 GMT, in Berlin 15:00 Uhr. Version 1.0, Status Final. Die Advisory-ID lautet cisco-sa-sdwan-webauth-xr8beuuU, die Bug-ID CSCww79570. Mehr Aktenlage braucht es nicht.

Der Hersteller gibt für CVSS 3.1 einen Basiswert von 9.8 an: über das Netz erreichbar, niedrige Komplexität, keine Privilegien, keine Nutzerinteraktion, unveränderter Wirkbereich, hohe Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit.

Zur Wirkung nennt der Hersteller sinngemäß: Eine Schwachstelle in der sitzungsbasierten Authentifizierungsverwaltung der API des Cisco Catalyst SD-WAN Manager könnte einer nicht authentifizierten, entfernten angreifenden Seite den Zugriff auf ein betroffenes System mit den Privilegien des Admin-Nutzers erlauben. Mehr braucht dieser Text dazu nicht.

Betroffen ist der Manager laut Hersteller unabhängig von der Systemkonfiguration. Eine Konfigurationsvariante ist damit kein Ausweg. Wer hofft, seine Einstellungen seien „irgendwie anders“, sollte die Hoffnung an dieser Stelle abgeben.

Das Workarounds-Feld des Advisorys lautet: No workarounds available. Im Klartext: Es gibt keine Workarounds, die diese Schwachstelle beheben. Und trotzdem beschreibt der Hersteller eine Mitigation für On-Prem-Umgebungen. Das ist der Clou, und er ist keine Entwarnung. Eine Mitigation ist kein Workaround und kein Patch. Sie verkleinert den Kreis derer, die ankommen. Sie repariert nichts.

Die Mitigation im Wortlaut des Herstellers, sinngemäß: Den Zugang aus unsicheren Netzen, etwa dem Internet, einschränken. Wenn Zugang aus dem Internet nötig ist, nur für bekannte, vertrauenswürdige Hosts. Die Control Components hinter ein filterndes Gerät stellen, etwa eine Firewall. Die Mitigation war laut Hersteller in einer Testumgebung erfolgreich. Ob sie in Ihrer Umgebung passt und wirkt, bewerten Sie selbst. Workarounds und Mitigations sind aus Herstellersicht temporär, bis ein Fixed Release eingespielt ist.

Für Cisco Catalyst SD-WAN Cloud Hosted gilt laut Hersteller: Die Mitigation ist bereits ausgerollt. On-Prem sieht anders aus. Dort liegt die Arbeit bei den Betreibenden, und dort liegt auch die Exposition.

Zur Ausnutzung gibt es eine Angabe des Cisco PSIRT, keine Beobachtung von digital-magazin.de: Im September 2026 wurde das PSIRT auf aktive Ausnutzung aufmerksam. Empfohlen wird das Upgrade auf ein Fixed Release. Entdeckt wurde die Schwachstelle laut Hersteller bei der Bearbeitung eines Support-Falls des TAC. Mehr Herkunftsgeschichte braucht niemand, und ein Nachbau daraus schon gar nicht.

Fixed Releases: Zweig vor Wunschversion

Wer Ziele setzt, beginnt beim Zweig, nicht bei der Version, die gerade schön klingt. Laut Advisory gilt: Zweige früher als 20.9 sind auf ein Fixed Release zu migrieren. Eine Zielversion nennt das Advisory dafür nicht, und wir erfinden keine.

Für die übrigen Zweige gilt: 20.9 geht auf 20.9.10.1, 20.12 auf 20.12.8.2, 20.15 auf 20.15.6.1, 20.18 auf 20.18.4.1, 26.1 auf 26.1.2.1 und 26.2 auf 26.2.1. Das ist die Liste. Sie gehört ins Inventar, nicht in den Kopf einer einzelnen Person.

Getrennt davon: Für Cisco SD-WAN Cloud (Cisco Managed) hat der Hersteller die Schwachstelle im Release 20.15.605 behoben. Das geschieht cloudbasiert, Nutzende müssen laut Hersteller nichts tun. Den Stand prüfen Sie über die Help-Funktion in der Service-Oberfläche. Das ist eine Cisco-Angabe, keine Entwarnung der Redaktion für jede gehostete Instanz.

Das PSIRT validiert nur die betroffenen und gefixten Release-Angaben, die im Advisory stehen. Alles andere bleibt Hausaufgabe: Compatibility Matrix, Upgrade Matrix und Hardening Guide. Wir nennen sie beim Namen und erzählen sie nicht nach. Wer den Zweig wechseln muss, liest die Upgrade Matrix, bevor er das Ticket schließt, nicht danach.

Die allgemeine Härtung bleibt organisatorisch und ist wenig spektakulär: Zugang aus unsicheren Netzen unterbinden oder auf bekannte Hosts begrenzen. Ein filterndes Gerät davor. Web-Logs auf unerwarteten Verkehr beobachten und extern ablegen, lang genug für eine spätere Untersuchung. Das Default-Passwort des Admin-Kontos ändern, den Admin-Zugang einschränken, Operator-Konten prüfen, ein Zertifikat einer Zertifizierungsstelle verwenden. Die Details gehören in den Hardening Guide, nicht in diesen Text.

Plot Twist: Der Patch schließt nach vorn

Ein Fixed Release schließt die Lücke. Es sagt nichts darüber, wer vorher schon durch war. Der Hersteller nennt aktive Ausnutzung im September 2026, die CISA hat die Schwachstelle in den KEV-Katalog aufgenommen. Beides zusammen heißt: Der Zeitraum vor dem Patch ist offen. Wie lang er ist, wissen weder Sie noch wir.

Genau hier kippt die Rechnung. Keine Workarounds heißt: Der Manager steht bis Samstag auf dem Board oder er steht exponiert. Die Mitigation kauft Zeit, sie beantwortet die Schwachstelle nicht. Wer sie umsetzt, hat die Tür enger gemacht, aber nicht abgeschlossen. Und über gestern hat er damit noch nichts gesagt.

Ein Manager, bei dem eine Ausnutzung Admin-Rechte bedeutet, ist keine Komponente am Rand. Er verwaltet das Netz, das er verwaltet. Ob dort etwas verändert wurde, ist eine Frage an Menschen und Unterlagen, nicht an den Versionsstand.

Deshalb liest sich die Meldung für Entscheidende anders als für Admins. Dass ein KEV-Eintrag ein Board-Signal ist, gilt hier doppelt: Es geht nicht nur um ein Update, sondern um die Frage, wer was wann verantwortet.

Die Frage nach der Zeit davor gehört nicht ins Bauchgefühl. Wer sie nicht beantworten kann, eskaliert: an den Betrieb, an Legal, an die, die Entscheidungen tragen. Eine ungestellte Frage ist kein erledigtes Thema. Sie ist nur eine, die später jemand anderes stellt.

BOD 26-04: Pflicht für Behörden, Einladung für alle anderen

KEV: Servergang hinter Glas und leeres Whiteboard — Manager-Instanzen und ein unbeschriebenes Wartungsfenster (Symbolbild)

BOD 26-04 trägt den Titel Prioritizing Security Updates Based on Risk und richtet sich an die Federal Civilian Executive Branch, kurz FCEB. Laut CISA stärkt die Direktive den Katalog: Behörden sollen hochriskante Einträge auf öffentlich exponierten Assets schnell beheben, wenn eine Ausnutzung die totale Kontrolle über das Asset gibt, und niedrigere Risiken zurückstellen. Außerdem legt sie Basiserwartungen fest, wann zu prüfen ist, ob Angreifende das System vor dem Patch kompromittiert haben.

Die Pflicht gilt nur für FCEB. Für alle anderen ermutigt CISA zu risikobasiertem Schwachstellenmanagement und zur Priorisierung von KEV-Einträgen. Ein Unternehmen in Hamburg oder Linz ist nicht gebunden. Es ist eingeladen. Einladungen, die man ignoriert, haben die unangenehme Eigenschaft, später als Versäumnis zu erscheinen.

Redaktionseinschätzung: Ein internet-exponierter Manager, bei dem eine Ausnutzung Admin-Zugriff bedeutet, sitzt näher am Priorisierungssatz der Direktive als ein Gerät im abgeschotteten Segment. Trotzdem ist das Due Date ein Katalogdatum für den Eintrag. Es ist keine Einladung, interne Instanzen zu vergessen. Exposition bewerten, nicht raten.

„Bewerten“ heißt hier organisatorisch: Jemand hat die Liste, jemand hat sie geprüft, jemand hat die Prüfung abgezeichnet. Nicht: Jemand meint, die Instanz hänge schon irgendwie hinter einer Firewall. Die Direktive setzt Erwartungen an die Prüfung. Sie liefert keine Erlaubnis zum Schulterzucken.

DACH-Redaktionslage: Das Tier für exponierte Manager

Noch einmal der Hinweis: Das ist eine Redaktionslage, kein echter Vorfall. Ein mittelgroßer Betrieb im DACH-Raum, mehrere Standorte, ein SD-WAN-Fabric, gewachsen über Jahre. Zwei Fragen entscheiden den Samstag. Welche internet-exponierten Manager stehen bis dahin auf dem Patch-Board? Und existiert ein Exposure-Inventar samt Triage-Auftrag?

Die Antwort beginnt mit einer Trennung. Cloud-Hosted und On-Prem gehören nicht in einen Topf. Cloud-Hosted hat laut Hersteller die Zugangsminderung bereits, und das Release 20.15.605 braucht laut Hersteller keine Aktion der Nutzenden. On-Prem ohne diese Minderung steht exponiert, bis der passende Stand aus der Liste läuft.

Wer das nicht auseinanderhält, patcht eine Liste und weiß nicht, welche Instanz das Internet noch sieht. Das ist der Unterschied zwischen einem Ticket, das „erledigt“ zeigt, und einer Umgebung, die es ist. Das Ticket sagt: Version erreicht. Die Frage lautet: Wer kommt heran?

Deshalb braucht es ein Tier. Internet-exponierte Manager bekommen eine eigene Klasse mit eigener Frist, eigenem Eigentümer und eigener Rückmeldung an die Leitung. Alle anderen Instanzen laufen im normalen Rhythmus, aber nicht im Verborgenen. Betriebe, die diese Klasse nicht führen, bearbeiten die Menge und verlieren die Exposition aus dem Blick.

Ein solches Tier steht und fällt mit sauberen Daten. Wo Asset-Daten ein Exposure-Inventar überhaupt erst möglich machen, ist die Frage nach der Erreichbarkeit in Minuten beantwortet. Wo nicht, beginnt eine Archäologie aus Tabellen, Zurufen und einer Datei namens „final_neu“.

Dann das Wartungsfenster. Es klingt nach Prozess, ist aber oft eine Verabredung unter Netten. Dass das Wartungsfenster am Wochenende kein Prozess ist, merkt man spätestens, wenn die Freigabe fehlt und die Person mit der Berechtigung nicht erreichbar ist. Ein Termin, der auf Samstag fällt, verlangt Vorabfreigaben am Donnerstag.

Gallows Humor am Rande: Die Instanz, die niemand auf der Liste hat, ist erfahrungsgemäß die, die das Internet am besten kennt. Sie läuft seit dem Pilotprojekt. Der Pilot ist längst vorbei. Das Projekt hat sie überlebt.

Triage-Checkliste bis Samstag

Die folgende Liste ist organisatorisch. Sie stellt nichts nach und prüft nichts technisch. Sie sorgt dafür, dass am Samstag jemand sagen kann, was er weiß und woher.

Exposition pro Instanz: internet-exponierte Manager, ja oder nein, mit Quelle. „Glauben wir“ ist keine Quelle. Eine Angabe ohne Verantwortlichen und Datum zählt nicht.
Kandidat für das Fixed Release: pro Instanz der Zweig und das passende Fixed Release aus der Liste, nicht die Wunschversion. Zweige früher als 20.9 bekommen einen Migrationsauftrag, keine erfundene Zahl.
Inventar und Eigentümer: Existiert ein Inventar, und wer führt es? Name, nicht Abteilung. Wenn die Antwort „müsste jemand“ lautet, ist das die Antwort.
Auftrag vor Samstag: Wer schaut, bis wann, und was ist die Quelle? Die Quelle ist das Inventar. Der Auftrag deckt auch die Frage nach der Zeit vor dem Patch ab, im Sinne der Forensic Triage, die BOD 26-04 erwartet und das Katalogfeld mit Yes markiert.
Eskalation: an Betrieb und Legal, schriftlich, mit Datum. Wer die Frage nach der Zeit davor nicht beantworten kann, eskaliert, statt sie mit einem Bauchgefühl zu schließen.

Zwei Hinweise zur Anwendung. Erstens: Die Liste gilt pro Instanz, nicht pro Produkt. Zweitens: Cloud-Hosted bekommt eine eigene Zeile mit der Herstellerangabe und dem Vermerk, wer den Stand in der Service-Oberfläche geprüft hat. Die Herstellerangabe ist eine Grundlage. Sie ersetzt keine Bestätigung durch Ihre Leute.

Und die Mitigation? Wer sie für On-Prem-Instanzen einsetzt, vermerkt das als temporär mit Enddatum. Eine Mitigation ohne Enddatum wird zur Dauerlösung. Dauerlösungen sind die, die man beim nächsten Audit mit dem Satz „war nur für den Moment gedacht“ erklärt.

Was ins Exposure-Inventar gehört

Ein Exposure-Inventar ist keine Tabelle für die Schublade. Es ist die Quelle, aus der der Samstag gespeist wird. Es muss für diese Lage nur wenige Dinge enthalten, aber die vollständig und mit Verantwortlichen:

Instanz: eindeutige Bezeichnung, so dass auch Vertretungen wissen, welche gemeint ist.
Betriebsform: On-Prem oder Cloud-Hosted. Nicht gemischt, nicht „teils“.
Erreichbarkeit aus unsicheren Netzen: ja oder nein, mit Quelle und Datum der Prüfung.
Zweig: der aktuelle Stand der Instanz, damit das passende Fixed Release zugeordnet werden kann.
Ziel-Release: das Fixed Release des Zweigs oder der Migrationsauftrag bei Zweigen früher als 20.9.
Eigentümer: eine Person, eine Vertretung. Kein Funktionspostfach als alleinige Adresse.
Auftrag: Triage-Auftrag, Zuständige, Zeitpunkt, Ergebnisablage.
Frist: Samstag, 3. Oktober 2026, und die interne Frist davor, die realistisch ist.

Das klingt banal. Ist es auch. Der Unterschied liegt darin, ob die Zeilen ausgefüllt sind. Ein halbes Inventar erzeugt die gefährlichste Form von Sicherheit: die gefühlte. Es zeigt sieben von zehn Instanzen sauber und verschweigt, dass die übrigen drei fehlen.

Praktisch lohnt eine Regel für unklare Zeilen: Was sich bis Donnerstagabend nicht belegen lässt, gilt als exponiert, bis das Gegenteil belegt ist. Das kostet vielleicht einen Termin zu viel. Die Alternative kostet einen Termin bei der Aufsicht, und der ist selten freiwillig.

Dazu gehört die Ablage. Ergebnisse der Prüfung landen dort, wo Legal und Betrieb sie wiederfinden, nicht im Postfach der Person, die gerade im Urlaub ist. Auch die Entscheidung gegen etwas gehört hinein: warum eine Instanz als nicht exponiert gilt, wer das belegt hat und wann.

Samstag patcht nach vorn, nicht zurück

Trockene Einschätzung: Wenn der Stand stimmt, schließt der Samstag die Lücke nach vorn. Instanzen, die auf dem Board standen, laufen auf dem passenden Fixed Release. Das ist gut, es ist Pflicht, und es ist nicht das Ende der Geschichte.

Er sagt nicht, was davor war. Er sagt nichts über die Tage, in denen die Ausnutzung laut Hersteller schon lief und niemand bei Ihnen hingesehen hat. Dafür braucht es den Auftrag, die Quelle und jemanden, der die Antwort unterschreibt oder die Frage offen nach oben trägt.

Wer ein Inventar hat, hat eine Chance auf eine ehrliche Antwort. Wer keines hat, hat eine Liste und die Hoffnung, dass sie vollständig ist. Der Plot Twist dieser Lage ist nicht die Schwachstelle. Es ist die Frage, die der Patch nicht beantwortet.

Bis Samstag bleibt wenig Zeit. Es reicht für eine Entscheidung, nicht für eine Neuordnung Ihrer Landschaft: Läuft die betroffene Instanz auf einem Fixed Release, oder ist sie exponiert? Wer das nicht in Minuten beantworten kann, hat kein belastbares Inventar. Genau dort beginnt die Arbeit, noch vor dem Wartungsfenster.

Der Stichtag ist Samstag, der 3. Oktober 2026. Der Patch beantwortet die Zeit davor nicht, er schließt nur die Lücke von jetzt an. Deshalb gehört der Triage-Auftrag auf Ihre Liste: Prüfen Sie, ob in der Zwischenzeit etwas passiert ist, bevor Sie Entwarnung geben. Das Board bleibt am Wochenende leer, die Frage nicht.