Microsoft Patchday September 2026: 974 Schwachstellen, zwei aktiv ausgenutzt
Microsoft schließt im September einen Rekordzyklus. Je nach Quelle sind es 966, 970, 972, 974 oder über 1.100 Schwachstellen. Keine dieser Zahlen ist falsch, und keine beantwortet die Frage, die im Betrieb zählt.
Der September 2026 ist der bislang größte Patchday in der Geschichte von Microsoft. Der vorherige Rekord stammt aus dem Juli dieses Jahres mit 622 CVEs, was wiederum etwa dem Fünffachen des Mai und dem Zehnfachen des Februar entsprach. Die Kurve steigt nicht, sie knickt nach oben.
Wer nach der genauen Zahl sucht, findet allerdings fünf verschiedene. Das ist kein Fehler der Berichterstattung, sondern eine Folge unterschiedlicher Zählweisen. Da diese Unterscheidung darüber entscheidet, wie viel Arbeit tatsächlich ansteht, lohnt es sich, sie zu klären.
Fünf Zahlen, fünf Bezugsgrößen
| Zahl | Was gezählt wird |
|---|---|
| rund 1.170 | CVE-Nummern im maschinenlesbaren MSRC-Datensatz, einschließlich Einträgen ohne eigene Einstufung |
| 974 | Von Microsoft eingestufte Schwachstellen, die am Patchday veröffentlicht wurden |
| 972 | Abweichender Auswertungsstand, abhängig vom Abrufzeitpunkt |
| 970 | Ebenso |
| 966 | Enger gefasst, ohne früher im Monat geschlossene Cloud- und Azure-Positionen |
Der Datensatz wird nach der Veröffentlichung mehrfach nachgeführt. Wer am Dienstagabend abruft, bekommt eine andere Zahl als am Donnerstagmorgen. Für die Berichterstattung ist das eine Fußnote. Für ein Schwachstellenmanagement, das gegen einen Sollstand arbeitet, ist es eine Fehlerquelle.
Die praktisch belastbare Größe ist nicht die Gesamtzahl, sondern die Schnittmenge aus dem, was im eigenen Bestand überhaupt installiert ist, und dem, was davon erreichbar ist.
Was tatsächlich dringend ist
Zwei Schwachstellen waren vor dem Patch bekannt und werden aktiv ausgenutzt. Beide sind inzwischen im KEV-Katalog der CISA geführt:
CVE-2026-81963 betrifft den Windows Update Stack. Ursache ist eine fehlerhafte Auflösung von Verknüpfungen vor dem Dateizugriff.
CVE-2026-85880 ist ein Heap-basierter Pufferüberlauf in Windows Advanced Local Procedure Call.
Beide sind mit CVSS 7.8 bewertet und erlauben einem lokal angemeldeten Angreifer die Ausweitung seiner Rechte. Das ist eine Einordnung, die in beide Richtungen missverstanden wird. Ein Angreifer braucht zunächst einen Zugang, aus dem Internet allein sind diese Lücken nicht ausnutzbar. Genau deshalb sind sie aber wertvoll: Rechteausweitung ist der Standardbaustein nach einem erfolgreichen Phishing oder einem gekaperten Dienstkonto. Wer bereits im Netz ist, kommt damit auf SYSTEM.
Über diese beiden hinaus gelten fünf weitere Positionen als vorrangig: Codeausführung in Exchange Server (CVE-2026-55007), Rechteausweitung im Microsoft Authenticator (CVE-2026-80097), Codeausführung in SharePoint (CVE-2026-69465), Rechteausweitung im SQL Server (CVE-2026-65669) sowie Codeausführung in den Remotedesktopdiensten (CVE-2026-69525).
Zwanzig der geschlossenen Schwachstellen werden als wurmfähig eingestuft.
Die Verteilung über alle Positionen: etwa 45 Prozent Rechteausweitung, 26 Prozent Codeausführung, 18 Prozent Informationsoffenlegung. Der Rest verteilt sich auf Denial of Service, Umgehung von Sicherheitsfunktionen, Spoofing und Manipulation.
Der Stolperstein, der in den Zahlen nicht auftaucht
Aus dem Umfeld des SANS Internet Storm Center wird über Anmeldeprobleme unter Windows 11 25H2 nach Installation von KB5124008 berichtet. Offenbar kollidiert eine verschärfte Sicherheitsprüfung mit älteren Domänencontrollern, genannt wird Windows Server 2019.
Für viele mittelständische Umgebungen ist das der praktisch relevanteste Punkt dieses Patchdays. Der Mainstream-Support für Server 2019 endete 2024, der erweiterte Support mit Sicherheitsupdates läuft bis 2029. Entsprechend viele Domänencontroller dieser Generation sind produktiv.
Wer Clients unter 25H2 betreibt und Domänencontroller älterer Stände einsetzt, sollte das Update vor dem breiten Rollout in einer Testgruppe prüfen. Ein gescheiterter Anmeldevorgang auf breiter Front ist im Tagesgeschäft teurer als die Verzögerung um wenige Tage.
Wenn das Patchvolumen die Kapazität übersteigt
Bei knapp tausend Positionen im Monat verliert die naheliegende Reihenfolge ihren Sinn. Nach CVSS absteigend zu arbeiten führt dazu, dass Systeme zuerst gepatcht werden, die niemand erreichen kann, während erreichbare Systeme warten.
Tragfähiger ist eine Priorisierung entlang von drei Fragen:
Ist es installiert? Ein Bestandsverzeichnis, das diese Frage beantwortet, reduziert tausend Positionen typischerweise auf einen mittleren zweistelligen Bereich.
Ist es erreichbar? Eine lokale Rechteausweitung auf einem Server ohne Benutzeranmeldung hat ein anderes Gewicht als dieselbe Lücke auf einem Terminalserver.
Wird sie ausgenutzt? KEV-Listung und Ausnutzungswahrscheinlichkeit nach EPSS sagen mehr über das reale Risiko aus als der Schweregrad allein. Ein CVSS von 9.8 ohne Exploit ist weniger dringend als ein CVSS von 7.8 mit bestätigter Ausnutzung, wie dieser Zyklus zeigt.
Diese Reihenfolge lässt sich automatisieren. Die Bewertung des eigenen Bestands ist die Voraussetzung dafür, und sie ist der Teil, der in vielen Organisationen fehlt.
Zur Ursache des Volumens
Die Zero Day Initiative führt den Anstieg auf den verstärkten Einsatz KI-gestützter Codeanalyse zurück. Die Zahl der aktiv ausgenutzten Schwachstellen ist dabei nicht mitgewachsen: zwei, wie in einem durchschnittlichen Monat.
Das ist die nüchterne Lesart. Es werden mehr Schwachstellen gefunden, nicht mehr ausgenutzt. Wer die Gesamtzahl als Maß für die Bedrohungslage nimmt, zieht den falschen Schluss.
Die weniger beruhigende Seite: Dieselbe Technik steht Angreifern zur Verfügung. Der Abstand zwischen Veröffentlichung einer Schwachstelle und Verfügbarkeit eines Exploits wird dadurch tendenziell kürzer. Zwanzig als wurmfähig eingestufte Positionen in einem einzelnen Zyklus sind in diesem Licht die eigentlich bemerkenswerte Zahl, nicht die 974.
Für Betreiber unter NIS2
Artikel 21 verlangt Verfahren für die Behandlung von Schwachstellen. Ein nachvollziehbar dokumentiertes Priorisierungsverfahren ist bei diesem Volumen keine Kür mehr, sondern die einzige Möglichkeit, gegenüber einer Prüfung darzulegen, warum bestimmte Positionen zuerst behandelt wurden und andere später.
Wer nach CVSS sortiert und der Reihe nach abarbeitet, wird die Frage nach der Begründung nicht beantworten können.