Bei 975 neuen CVEs im Monat ist Patchen kein Projekt mehr, sondern Betrieb
975 neue CVEs an einem Tag und zwei aktiv ausgenutzte Lücken zeigen: Schweizer KMU brauchen einen stehenden Patch-Prozess mit Ringen und Automatisierung statt Einzelaktionen.
In Kürze
- Am 8. September 2026 veröffentlichte Microsoft 975 neue CVEs an einem einzigen Tag.
- Zwei Schwachstellen waren bereits aktiv ausgenutzt, bevor der Patch überhaupt verfügbar war.
- Sechs Tage später folgte ein Out-of-Band-Fix für eine dritte, kritische Lücke im Secure Kernel.
Der Befund
Der Patch Tuesday vom 8. September 2026 brachte 975 neue CVEs auf einen Schlag, verteilt über Windows, Office, Azure und Edge. Zwei der Lücken galten laut Microsoft bereits vor der Veröffentlichung als aktiv ausgenutzt: CVE-2026-81963 in der Windows-Update-Stack-Komponente selbst und CVE-2026-85880 in der Advanced Local Procedure Call, kurz ALPC, einem Kernbaustein der Windows-Rechteverwaltung. Beide erlauben es einem Angreifer, der bereits einen Fuss auf dem System hat, sich auf Systemrechte hochzuschrauben, also von einem gekaperten Benutzerkonto auf volle Kontrolle über die Maschine zu wechseln. Gerade weil solche Rechteausweitungen selten für sich allein stehen, sondern meist den zweiten Schritt eines Angriffs bilden, zählen sie zu den Lücken, die Sicherheitsverantwortliche zuerst schliessen. Sechs Tage später, am 14. September, schob Microsoft ausserplanmässig einen weiteren Fix nach: CVE-2026-85921 betrifft den Secure Kernel und wurde als kritisch eingestuft, obwohl bei Erscheinen noch keine aktive Ausnutzung bekannt war.
Für IT-Verantwortliche in KMU heisst das: Innerhalb von zwei Wochen kamen drei dringliche Patch-Ereignisse zusammen, zwei davon mit echtem Zeitdruck, weil die Lücken bereits im Feld benutzt wurden. Wer im September noch mit einem klassischen Monatsrhythmus geplant hat, lag bei diesen beiden Fällen bereits hinter der Realität. Das ist kein Ausreisser. Microsoft selbst beschreibt den zweiten Dienstag im Monat als festen Rhythmus für kumulative Sicherheitsupdates, ergänzt um Out-of-Band-Releases, die ausserhalb dieses Plans erscheinen, wenn eine Lücke oder ein Qualitätsproblem nicht bis zum nächsten Fenster warten kann. Beides zusammen ergibt einen Kalender, der nicht mehr nur einmal im Monat Aufmerksamkeit verlangt, sondern laufend.
Der Mechanismus
Warum lässt sich das nicht mehr als Einzelprojekt abarbeiten? Weil die Grundannahme hinter dem klassischen Patch-Projekt, nämlich ein planbares, seltenes Ereignis mit Vorlaufzeit, nicht mehr zutrifft. Aktiv ausgenutzte Lücken wie CVE-2026-81963 und CVE-2026-85880 verschieben das Zeitfenster von Wochen auf Tage, und ein Out-of-Band-Fix wie bei CVE-2026-85921 hält sich ohnehin nicht an den Monatsplan. Ein Projekt hat einen Anfang und ein Ende; ein Betrieb hat keines von beidem, sondern läuft weiter, solange die IT-Umgebung existiert. Die Alternative zum Projektmodell ist deshalb ein stehender Prozess mit Ringen: eine kleine Testgruppe erhält Updates zuerst, eine breitere Gruppe folgt nach wenigen Tagen Beobachtung, der Rest nach einer weiteren Stufe. Wer diese Ringe einmal einrichtet, muss sie danach nicht mehr jeden Monat neu erfinden, sondern nur noch pflegen. Microsoft bietet mit Windows Autopatch genau diese Automatisierung als Dienst an, inklusive eines Zielwerts, mindestens 95 Prozent der verwalteten Geräte auf dem aktuellen Qualitätsupdate zu halten.
| Kriterium | Projekt-Modell (Patchen als Einzelaktion) | Betriebs-Modell (Ringe, automatisiert) |
|---|---|---|
| Auslöser | Patch Tuesday, manuell terminiert | Laufender Zeitplan mit Ringen |
| Reaktionszeit bei aktiver Ausnutzung | Tage bis Wochen, je nach Planungszyklus | Stunden bis wenige Tage über beschleunigte Ringe |
| Ausnahmen | Ad hoc, oft undokumentiert | Definierte Ausnahmeliste mit Ablaufdatum |
| Zielgrösse | Kein festes Ziel, "möglichst bald" | Messbare Quote, z. B. 95 Prozent aktuell |
Patchen ist bei 975 neuen Lücken in einem Monat kein Projekt mehr, sondern ein stehender Betriebsprozess.
Die Gegenseite
Der stärkste Einwand gegen schnelles, automatisiertes Patchen ist real und belegt: Updates können selbst zum Problem werden. Nach demselben September-Update meldeten Nutzer, dass Kopieren und Einfügen in mehreren Excel-Versionen lautlos fehlschlug, ohne Fehlermeldung, ohne Warnton, einfach ohne Wirkung. Microsoft bestätigte den Regressionsfehler und lieferte erst Tage später eine Korrektur nach, während Betroffene sich mit einem Behelf über Einfügen-Spezial durchhelfen mussten. Wer solche Vorfälle kennt, zieht daraus einen naheliegenden Schluss: Abwarten, bis andere die Regressionen gefunden haben, schützt vor genau diesem Ärger im eigenen Betrieb.
Der Einwand trifft einen echten Zielkonflikt, aber er widerlegt nicht die Grundidee eines stehenden Prozesses, sondern begründet, warum er Ringe braucht statt eines Alles-oder-nichts-Rollouts. Eine kleine Pilotgruppe, die neue Updates zuerst erhält und einige Tage lang beobachtet wird, hätte den Excel-Regressionsfehler abgefangen, bevor er die ganze Belegschaft erreicht. Bei aktiv ausgenutzten Lücken wie CVE-2026-81963 lässt sich dieses Beobachtungsfenster nicht beliebig verlängern, weil das Risiko einer Kompromittierung schneller wächst als das Risiko einer Regression. Der Prozess muss also beides gleichzeitig können: schnelle Ringe für kritische, aktiv ausgenutzte Lücken und ein längeres Beobachtungsfenster für den Rest. Reines Abwarten ohne Ringe verschiebt das Problem nur, es löst es nicht.
Was das für Ihr KMU heisst
- Legen Sie Update-Ringe mit klaren Fristen fest, statt jeden Patch Tuesday neu zu entscheiden.
- Definieren Sie eine Ausnahmeliste mit Ablaufdatum für Systeme, die nicht sofort patchen können.
- Prüfen Sie, ob Automatisierung wie Windows Autopatch die Ringe für Sie umsetzt, statt manuell nachzuziehen.
