Windows-CVE-Volumen 2026: Was Patching-Teams messen sollten

In den drei vollständigen Jahren unserer neuen Forschung stieg die Zahl der verschiedenen Windows- und Office-CVEs von 679 auf 941 und dann auf 2.438 (+38,6 %, dann +159,1 %), während sich der mittlere CVSS-v3-Basiswert von 7,43 auf 7,37 und dann auf 7,28 bewegte. Das ist eine sehr viel größere eingehende Arbeitslast bei einer durchschnittlichen Schwere, die nicht gestiegen ist, weshalb eine rohe CVE-Anzahl ein schlechter Maßstab für die Steuerung eines Patching-Programms ist. Dieser Beitrag geht durch, was die Zahlen aussagen, wie die Kohorte aufgebaut wurde, was Sie stattdessen messen sollten und was die Studie nicht messen konnte. Die Forschung stammt aus dem Haus des Unternehmens und wurde nicht begutachtet (Peer Review). Wir haben sie am 2. November angekündigt, und das vollständige Papier ist über die Registrierungsseite erhältlich.

Was die Jahreszahlen aussagen

Das Papier vergleicht drei sich nicht überschneidende vollständige Jahre, die jeweils von Oktober bis September laufen, damit kein unvollständiger Monat den Vergleich verzerrt.

Verschiedene Windows- und Office-CVEs in den drei vollständigen Jahreskohorten des Papiers. Windows und Office überschneiden sich, daher ist die Vereinigungsmenge bereinigt, und die beiden Zahlen dürfen nicht addiert werden.

Der Anstieg verteilt sich nicht gleichmäßig. Das Papier stellt fest, dass er sich auf Mitte bis Ende 2026 konzentriert: Im Juli gab es 483 CVEs, im August 316 und im September 819, gegenüber einem Median von 69 pro Monat über die 36 vollständigen Monate. Der Oktober 2026 trägt bis zum Stichtag am 26. Oktober bereits 1.277 Windows- und Office-CVEs bei, darunter 1.114 Datensätze zu Windows-Betriebssystemen. Das sind revidierte monatliche Offenlegungssummen einschließlich außerplanmäßiger Datensätze, sie sollten daher nicht mit einem Medienbericht gleichgesetzt werden, der nur die ursprüngliche Patch-Tuesday-Veröffentlichung zählt. Das Papier rechnet keinen einzelnen Monat auf eine Jahresprognose hoch, und es nimmt weder einen Signifikanztest noch einen kausalen Bruchpunkt für sich in Anspruch.

Über die letzten 12 Berichtsmonate (November 2025 bis Oktober 2026, der Oktober nur teilweise) umfasst die Kohorte 3.565 CVEs, etwa 297,1 pro Berichtsmonat. Die Division durch 12 beschreibt den Durchsatz pro Berichtsmonat und rechnet den Oktober nicht auf ein Jahr hoch. Die Prüfung mit vollständigen Monaten bis September 2026 ergibt 2.438 CVEs über 12 Monate, 3.379 über 24 und 4.058 über 36.

Die durchschnittliche Schwere stieg nicht

Der Mittelwert belegt keinen allgemeinen Anstieg der durchschnittlichen Basisschwere, bedeutet aber auch nicht, dass das Risiko gesunken ist. Die absolute Zahl schwerwiegender Offenlegungen kann wachsen, während ihr Durchschnitt stabil bleibt: Im letzten Jahr erreichen 1.841 von 2.436 bewerteten Datensätzen (75,6 %) mindestens 7, und 60 erreichen 9,0 oder höher. Das Papier behandelt CVSS als Schweregradskala und ihren Mittelwert als deskriptive Zusammenfassung, nicht als erwarteten finanziellen Schaden oder als Wahrscheinlichkeit einer Kompromittierung. Die Schweregradbezeichnung "Critical" der Hersteller ist eine andere Klassifikation und wird getrennt ausgewiesen.

Die Studie verknüpft außerdem jedes CVE mit dem CISA-Katalog Known Exploited Vulnerabilities. Die Zugehörigkeit in den drei Jahreskohorten beträgt zum Stichtag 29, 25 und 21. Das Papier nennt dies einen deskriptiven Querschnitt und keinen Beleg dafür, dass Ausnutzung seltener wird: Die Nachbeobachtungszeit unterscheidet sich, die Katalogabdeckung ist unvollständig, und ein wachsender Nenner kann den beobachteten Anteil rein rechnerisch senken.

Wie die Kohorte aufgebaut wurde

Die Methode ist bewusst konservativ, und jeder Schritt ist im Papier nachvollziehbar.

1. Quelle. 37 monatliche CVRF-Dokumente des Microsoft Security Response Center, Oktober 2023 bis Oktober 2026, aufbewahrt mit Zeitstempeln und SHA-256-Hashwerten.
2. Bereinigung. Sieben Advisory-Zeilen ohne CVE und 48 ausdrücklich zurückgewiesene CVE-Kennungen wurden ausgeschlossen. Wiederholte Zeilen zu Produktversionen wurden auf einen Datensatz pro CVE zusammengeführt.
3. Begrenzter Umfang. Nummerierte Windows-Clients und Windows-Server-Produkte sowie Office-Desktopanwendungen, mit einer expliziten Produkt-Allowlist. Summen über alle Datensätze des Microsoft Security Response Center sind nicht die Hauptkennzahl, weil sie auch Azure Linux, Clouddienste und Upstream-Komponenten enthalten.
4. Ein Datum pro CVE. Das früheste gültige Revisionsdatum. Das Papier stellt klar, dass dies ein Näherungswert für die Offenlegung anhand von Microsoft-Meldungen ist, kein beobachtetes Entdeckungsdatum, kein globales Veröffentlichungsdatum und kein Datum der Patch-Installation.
5. Ein Wert pro CVE. Der höchste beobachtete anwendbare CVSS-v3.x-Basiswert über alle aufbewahrten Revisionen. Fehlende Werte werden aus dem Mittelwert und seinem Nenner ausgeschlossen, und CVSS v4 sowie zeitabhängige Werte (Temporal) werden nicht beigemischt.
6. Verknüpfung mit Ausnutzung. Zugehörigkeit zum CISA KEV nach CVE-ID, anhand der Katalogversion 2026.10.23.
7. Teilmonate. Vollständige Jahre laufen von Oktober bis September. Der Oktober 2026 wird für sich ausgewiesen und nie als abgeschlossener Monat behandelt.

Automatisierte Prüfungen bestätigten die 37 erwarteten Dokumente, keine doppelten CVE- und Umfangsschlüssel, gültige Wertebereiche und monatliche Zählungen, die mit den Kohortensummen übereinstimmen. Ein Vergleich von sechs Datensätzen mit NVD und der CVE Services API ist eine Konsistenzprüfung und keine unabhängige Replikation, und NVD wird nicht als alleiniger Nenner für bewertete Produkte verwendet, weil sein Rückstand von 2024 und eine Änderung der Anreicherungsrichtlinie im April 2026 einen Bruch in der Abdeckung verursachen. Laut Papier enthält das analytische Supplement die Tabellen der Kohorten auf CVE- und Monatsebene, die Prüfung des Produktumfangs, ausgeschlossene und zurückgewiesene Datensätze, die Release-Ereignisse und Monatsreihen der Anwendungen, den 17-zeiligen Datensatz zu den Behebungszeiten samt Abdeckungsdatei, die Belegprotokolle und ein SHA-256-Manifest, einschließlich der Analyseskripte.

Sechs Anwendungs-Release-Streams

Paketierungsteams patchen nicht nach einem einzigen Kalender, daher ergänzt das Papier ein gezielt zusammengestelltes Panel aus sechs Release-Streams: Chrome, Edge, Firefox, Visual Studio Code, Notepad++ und 7-Zip. Ein Release-Tag ist ein eindeutiges Datum, an dem eine Version einer App veröffentlicht wurde. Im letzten vollständigen Jahr reicht das Panel von 69 Release-Tagen für Edge, 64 für Chrome und 61 für Visual Studio Code über 44 für Firefox und 17 für Notepad++ bis hinunter zu 4 für 7-Zip. Spitzenmonate sind geschäftiger, als diese Durchschnitte vermuten lassen: Visual Studio Code erreichte in einem einzigen Monat neun Release-Tage.

Über die 36 vollständigen Monate erzeugten die sechs Streams 661 App-spezifische Release-Tage. Das Panel ist keine repräsentative Stichprobe von Windows-Software, die Grundgesamtheiten der CVEs und der Releases unterscheiden sich, und das Papier sagt, dass die Zahlen nicht miteinander multipliziert oder als Ursache-Wirkungs-Beziehung gelesen werden dürfen. Release-Tage beschreiben Verfügbarkeit und Überwachungsmöglichkeiten, keine verpflichtenden Bereitstellungen oder Paketierungsstunden.

Was Sie statt CVE-Anzahlen messen sollten

Das Papier schlägt diese Größen als Managementkennzahlen vor, nicht als aus CVE-Summen abgeleitete Werte.

• Zeit bis zum verifizierten Schutz: von der Verfügbarkeit eines anwendbaren Herstellerfixes bis zum bestätigten Schutz, einschließlich Browser-Neustarts, Systemneustarts und erneuter Scans. Weisen Sie den Median und das 90. Perzentil aus, dazu fehlgeschlagene Installationen, die Rollback-Rate und den Ablauf von Ausnahmen.
• Verzögerung von Release bis Entscheidung und von Release bis Schutz für jede App und jeden Kanal.
• Qualifizierungsaufwand: monatlich ausgewählte Versionswechsel, zentrale Artefakt-Builds sowie Median und 90. Perzentil der Qualifizierungsdauer.
• Nacharbeit: Notfallanteil, Fehler- und Nacharbeitsrate sowie der Rückstand an Updater-Fehlern.
• Gefährdung: das Alter ausstehender anwendbarer Sicherheitsupdates sowie exponierte KEV-Instanzen und deren Alter, nicht mehr unterstützte Assets und der Rückstand nach Wichtigkeit des Dienstes.

Allem liegt ein versioniertes Inventar zugrunde, damit ein CVE den installierten und exponierten Assets zugeordnet wird, bevor die Behebungswarteschlange wächst. Halten Sie CVE-Anzahlen getrennt von Geräteinstanzen und Bereitstellungsaufwand.

Was die Studie nicht messen konnte

• Einen Durchschnitt der Behebungsdauer für die gesamte Kohorte. Jedes einzelne der 4.058 CVEs im vollständigen Fenster hat einen gültigen Revisionszeitstempel, aber kein angegebenes Entdeckungs- oder Release-Datum. Alle 98.265 anwendbaren Behebungszeilen tragen das Sentinel-Datum im Jahr 0001 mit DateSpecified=false. Fixeinträge der Hersteller gibt es für alle 4.058 CVEs, ausdrückliche Workaround-Einträge für fünf und Mitigationseinträge für 66, es gibt also null verwertbare strukturierte Datumspaare. Fehlende Daten sind keine Verzögerung von null.
• Eine einzige Uhr. Datierte Fälle, etwa drei Intervalle von der privaten Meldung bis zum Release bei PHP und NGINX von 61, 71 und 81 Tagen, verwenden unterschiedliche Start- und Endereignisse und werden getrennt ausgewiesen, nicht zu einem Durchschnitt zusammengefasst.
• Die Schwere jedes Browser-CVEs. Nur 240 von 2.931 Edge-bezogenen Datensätzen (8,2 %) tragen in dieser Extraktion einen anwendbaren numerischen CVSS-v3-Wert, daher kann der Mittelwert dieser Gruppe nicht für alle Browser-CVEs stehen.
• Was Administratoren am jeweiligen Tag sahen. Die historischen Monatsdateien sind veränderbar, und Werte können sich nach der ersten Offenlegung ändern. Der Snapshot unterstützt die Replikation der Studie, nicht die Wiederherstellung früherer Quellzustände.

Wo EtherApps Forge ins Bild passt

Die Studie bewertet weder EtherApps Forge noch ein kommerzielles Produkt, und EfficientEther legt im Papier sein Interesse an EtherApps Forge offen. Der Zusammenhang ist die Arbeit, die die Zahlen erzeugen. Wenn Hersteller-Releases schneller eintreffen, lautet die Paketierungsfrage, welche Anwendungen Sie zentral paketieren und wie schnell Sie jede neue Version qualifizieren können. EtherApps Forge erfasst Windows-Anwendungen dort, wo sie bereits laufen, und baut signierte MSIX-, MSI-, Intune- und App-Attach-Pakete, also die Paketierungsseite dieser Routine. Anwendungsmodernisierung und -migration und Modernisierung von Legacy-Anwendungen behandeln die älteren Anwendungen, die sich am schwersten aktuell halten lassen, und unsere frühere Studie zu 3.261 automatisierten MSIX-Paketierungsfällen zeigt, wie wir die Paketerstellung von Start- und Testbelegen trennen.

Die Windows-Patching-Forschung erhalten für die vollständigen Tabellen, die Methode und die Kennzahlen, die Ihr Team übernehmen kann.