Am 8. September hat Microsoft rund 970 Sicherheitslücken geschlossen, darunter zwei, die bereits aktiv ausgenutzt wurden. Zwei Tage später haben die ersten Unternehmen ihre RDS-Farmen nicht mehr erreicht, Clients die Vertrauensstellung zur Domäne verloren und Anwender nach dem Login auf einen schwarzen Bildschirm geschaut. Beides stammt aus demselben Paket.
Das ist die unangenehme Realität des Patchmanagements 2026: Nicht patchen ist keine Option mehr, patchen aber auch nicht ohne Weiteres.
Was KB5124008 tatsächlich angerichtet hat
Das kumulative Update für Windows 11 24H2 und 25H2 (Builds 26100.9445 und 26200.9445) schließt nach Zählung der Sicherheitsanbieter etwa 974 CVEs, über hundert davon kritisch. Die beiden Zero-Days – CVE-2026-81963 im Windows Update Stack und CVE-2026-85880 in der ALPC-Schnittstelle – standen noch am selben Tag im KEV-Katalog der CISA. Beide führen zu SYSTEM-Rechten, CVE-2026-85880 sogar ohne Nutzerinteraktion aus einem AppContainer heraus. Das Update ist also nicht verhandelbar.
Die Liste der Nebenwirkungen ist es leider auch nicht.
Am heikelsten für klassische AD-Umgebungen: Windows-11-Clients verlieren die Vertrauensstellung zur Domäne, wenn im Netz noch Domänencontroller unter Server 2019 stehen. Die Aushandlung des sicheren Netlogon-Kanals scheitert, das Ereignis kommt als ERROR_NO_TRUST_LSA_SECRET (1786). Der dokumentierte Workaround ist Domäne verlassen und neu beitreten – bei fünfzig Geräten ein verlorener Tag, bei fünfhundert ein verlorenes Wochenende.
Dazu kommen schwarze Bildschirme nach der Anmeldung, lokal wie über RDP. Der Desktop bleibt unsichtbar, das Startmenü reagiert trotzdem auf Eingaben, geöffnete Anwendungen laufen im Hintergrund weiter. In den RDP-Fällen hat Windows den Grafiktreiber durch seinen eigenen Standardtreiber ersetzt. In virtualisierten Umgebungen mit Citrix oder FSLogix stürzt zusätzlich der Explorer beim Login ab.
Weiter unten in der Fehlerliste, aber nicht harmloser: Das Secure-Boot-Update scheitert auf Systemen mit einer WinRE-Partition unter 750 MB und hinterlässt Rechner, die nicht mehr booten – ein Klassiker bei älteren Images und manuell partitionierten Geräten. BitLocker meldet Event ID 24641 und kommt beim Neustart nicht mehr an den Volume Master Key im TPM. USB-Audio-Geräte der Klasse 1.0 quittieren mit Code 10. Freigaben, die über Plan9 an Linux-VMs durchgereicht werden, sind nicht mehr erreichbar.
Und weil ein schlechter Monat selten allein kommt: Das separate Office-Update KB5002914 bricht in Excel 2016 bis 2024 das Kopieren und Einfügen sowie das Ziehen von Formeln. Auch hier hilft momentan nur die Deinstallation.
Für den RDS-Bug hat Microsoft inzwischen reagiert – mit Known Issue Rollback. Die Pakete kommen als MSI mit ADMX-Vorlagen; man installiert die zur OS-Version passende Datei, bekommt dadurch eine neue Richtlinie unter „Administrative Vorlagen" und schaltet das fehlerhafte Feature per GPO ab. Ein permanenter Out-of-Band-Fix war angekündigt. Prüfen Sie vor dem Ausrollen, ob er inzwischen da ist.
Kein Ausrutscher, sondern ein Muster
Wer den September für einen Einzelfall hält, hat Mai und Juni verdrängt.
Im Mai brach KB5089549 mit Fehler 0x800f0922 ab, weil die EFI-Systempartition zu klein war – betroffen vor allem ältere Hardware und alles, was irgendwann einmal von Hand partitioniert wurde. Im Juni änderte KB5094126 etwas an der Virtualization Based Security und zerlegte damit die OLE-Automation zu Office. Fachanwendungen, die Word oder Excel im Hintergrund fernsteuern – Kanzleisoftware, Praxisverwaltung, Literaturverwaltung – konnten Dokumente nicht mehr öffnen. Geschäftskunden mussten für dieses Problem einen KIR beim Business-Support anfragen; einen öffentlichen Termin für einen dauerhaften Fix gab es nicht.
Drei Monate, drei Update-Wellen, in denen der Rollout nicht am Ausrollen scheiterte, sondern an dem, was danach passierte.
Warum Update-Ringe allein nicht mehr reichen
Kurzer Zwischenruf zur Terminologie, weil sie in Tickets und Dokumentationen für Verwirrung sorgt: Windows Update for Business heißt seit April 2025 offiziell Windows Update client policies. Technisch hat sich nichts geändert, die CSPs sind dieselben, aber in Microsofts Dokumentation existieren beide Begriffe nebeneinander. Wer nach „WUfB" sucht, landet bei Artikeln von 2021 – wer nach dem neuen Namen sucht, bei den aktuellen.
Das eigentliche Problem ist aber ein anderes. Das klassische Ringmodell – Pilot, Broad, Critical – geht davon aus, dass Fehler im Pilotring auffallen, bevor der Rest dran ist. Das funktioniert nur, wenn drei Dinge stimmen, und im September stimmte keines davon zuverlässig.
Erstens: Die Pause ist kein Notaus. Ein Update-Ring lässt sich in Intune für maximal 35 Tage pro Update-Typ pausieren, danach läuft die Pause automatisch aus. Vor allem aber greift der Pause-Befehl erst, wenn das Gerät das nächste Mal eincheckt. Geräte, die über das Wochenende ausgeschaltet waren, holen sich beim Einschalten unter Umständen erst das geplante Update und melden sich danach beim Dienst. Wenn Sie am Donnerstagnachmittag pausieren, sind die Notebooks, die freitags zurück ins Büro kommen, nicht mehr sicher davor.
Zweitens: Safeguard Holds greifen nur bei Feature-Updates. Microsoft blockiert damit Geräte mit bekannten Inkompatibilitäten, und der Deployment-Service pausiert Deployments für betroffene Geräte selbsttätig. Für monatliche Qualitätsupdates existiert dieser Schutzmechanismus in der Form nicht – ausgerechnet dort, wo die Probleme im September auftraten.
Drittens: Die Durchsetzung hängt am Dienst. Am 4. Juni meldete Microsoft unter der Vorfallnummer MO1332784 eine Cache-Fehlkonfiguration, durch die verwaltete Geräte zeitweise als nicht verwaltet galten. Treiber, die Intune-Richtlinien hätten blockieren oder zur Freigabe zwingen sollen, wurden installiert. Die Treiber selbst waren signiert und freigegeben – ausgefallen war die Durchsetzung der Richtlinie, nicht die Richtlinie. Für die Praxis heißt das: Eine Konfiguration in der Konsole ist eine Absichtserklärung, kein Nachweis. Was auf dem Endgerät passiert ist, steht im Reporting, nicht im Profil.
Dazu kommt Zeitdruck von außen. Windows 11 24H2 verliert am 13. Oktober 2026 den Support – zumindest für Home und Pro. Enterprise und Education haben ein Jahr länger, bis zum 12. Oktober 2027. In gemischten Umgebungen, in denen Pro-Lizenzen auf Notebooks und Enterprise auf den Standardgeräten laufen, endet der Support also mitten im Gerätebestand. Und seit Windows 10 im Oktober 2025 aus dem Support gefallen ist, gibt es kein Ausweichen mehr nach unten.
Was jetzt konkret zu tun ist
Ein Ablauf, der sich in den letzten Monaten bewährt hat:
Inventur der Risikofaktoren, bevor der nächste Patchday kommt. Gibt es noch Domänencontroller unter Server 2019? Wie groß sind die WinRE-Partitionen im Standard-Image? Welche Fachanwendungen steuern Office über OLE fern? Diese drei Fragen hätten im September, Juni und Mai jeweils den Ausschlag gegeben. Die Antworten gehören in die CMDB, nicht in den Kopf eines Kollegen.
Den Pilotring so bauen, dass er repräsentativ ist. Zehn Geräte der IT-Abteilung sind kein Pilotring. Er braucht mindestens je ein Gerät aus jeder Hardware-Generation, ein RDS-/VDI-System, ein Gerät mit aktivem BitLocker und Secure Boot und eines mit der kritischsten Fachanwendung. Lieber fünfzehn gut ausgewählte als hundert zufällige.
Deferral statt Pause als Grundeinstellung. Sieben Tage Aufschub für Qualitätsupdates im Broad Ring kosten kaum Sicherheit, geben aber genug Zeit, um die Meldungen aus dem Pilotring und den einschlägigen Blogs zu lesen. Die Pause bleibt dann für den Ernstfall – mit dem Wissen, dass sie verzögert greift.
Known Issue Rollback vorbereiten, nicht improvisieren. Legen Sie eine GPO-Struktur an, in die sich KIR-ADMX-Vorlagen einhängen lassen, und dokumentieren Sie den Weg einmal sauber. Wenn der Fall eintritt, haben Sie keine Zeit, das Verfahren zum ersten Mal zu lesen. Für Probleme ohne öffentlichen KIR – wie im Juni – gilt: Der Business-Support ist der Weg, und ein bestehender Support-Vertrag entscheidet dann über Stunden statt Tage.
Rollback-Fenster nicht verkürzen. Die Deinstallationsdateien für Feature-Updates lassen sich in Intune zwischen 2 und 60 Tagen vorhalten. Der Standardwert von 14 Tagen ist knapp, wenn ein Problem erst nach drei Wochen auffällt.
Nach jedem Patchday gegenprüfen, was wirklich installiert wurde. Update-Reports gegen die zugewiesenen Richtlinien halten, Treiberinstallationen im Zeitfenster kontrollieren, Helpdesk-Tickets zu Audio, Netzwerk, Display und Neustarts mit dem Rollout korrelieren. MO1332784 hat gezeigt, warum das keine Fleißarbeit ist.
Und, weniger technisch, aber wirksam: Setzen Sie Patchdays und die 72 Stunden danach als Sperrzeit für Change-Freeze-freie Zeiträume. Wer am Dienstagabend patcht und am Mittwoch die Migration eines Fileservers plant, sucht den Fehler an der falschen Stelle.
Fazit
Der September 2026 war ein guter Monat zum Patchen und ein schlechter zum Vertrauen. Zwei aktiv ausgenutzte Zero-Days auf der einen Seite, verlorene Domänenvertrauensstellungen und tote RDS-Farmen auf der anderen – die Abwägung zwischen Sicherheit und Verfügbarkeit ist nicht mehr theoretisch.
Drei Dinge bleiben hängen. Ein Pilotring ist nur so gut wie seine Vielfalt, nicht seine Größe. Die Pause in Intune ist eine Verzögerung, keine Garantie. Und was auf dem Endgerät passiert ist, steht im Reporting, nicht im Profil.
Wenn Sie gerade nicht sagen können, ob Ihre Ringe im Ernstfall halten würden: Das ist eine Stunde Arbeit, keine Woche. Wir schauen uns Ihre Update-Ringe, Ihre Richtlinienzuweisung und Ihr Update-Reporting an und sagen Ihnen, wo die Lücken sind – bevor der nächste Patchday sie findet. Sprechen Sie uns an.
