Microsofts September-Patch-Day legte Remote Desktop lahm, der Fix kam sechs Tage später

Der Patch-Day von Microsoft im September 2026 war die größte Sicherheitsveröffentlichung der Unternehmensgeschichte. Er erwies sich zugleich als eine der chaotischsten. Wenige Stunden nach der Installation der Updates am 8. September mussten Administratoren von Remote-Desktop-Services-Hosts mitansehen, wie ihre Sitzungsserver keine Verbindungen mehr annahmen, und es dauerte bis zum 14. September, bis Microsoft Notfall-Pakete außerhalb des regulären Zyklus auslieferte, die das Problem behoben.

Zum Weiterlesen: Microsofts Project Zenith will Windows 'ready-to-code' machen. Entwickler sind nicht überzeugt · ServiceNows Aktie fiel um 27 Prozent, als die KI-Furcht die Softwareaktien erfasste.

Die betroffenen Server-Builds waren KB5122876 für Windows Server 2019, KB5122882 für Windows Server 2022 und KB5122871 für Windows Server 2025. Microsofts Release-Health-Dashboard beschreibt den Fehler mit denselben Worten, die Administratoren seit Tagen benutzten: RDS konnte instabil werden, RDP-Verbindungen scheiterten nach mehreren Minuten, Anmeldungen brachen ab, und Server hingen bei der Meldung fest, die zum Kürzel für den gesamten Vorfall wurde: „Please wait for the Remote Desktop Configuration“.

Der Kollateralschaden reichte über RDP hinaus. Die Microsoft Management Console, der RDS-Lizenzdiagnose, der Datei-Explorer und sogar die Windows-Update-Seite konnten alle nicht mehr reagieren. Wenn auch die Werkzeuge nicht mehr antworten, mit denen man einen fehlerhaften Server diagnostiziert, hört ein schlechter Patch auf, eine Unannehmlichkeit zu sein, und wird zum Ausfall.

Ein Fehler, der ein paar Stunden wartete

Das Timing machte diese Sache besonders übel. Das Update beschädigte die Server nicht bei der Installation. Die Hosts kamen zurück, Nutzer verbanden sich, und ein routinemäßiger Smoke-Test nach dem Patch hätte bestanden. Der Ärger zeigte sich später, als Sitzungen eine Weile gelebt hatten und Leute begannen, sich abzumelden.

Die von BleepingComputer und anderen gesammelten Berichte beschrieben eine gleichbleibende Abfolge. Neue RDP-Verbindungen hingen in der Verbindungsphase fest und scheiterten dann. Bereits angemeldete Nutzer konnten sich nicht sauber trennen oder abmelden. Mehrere Administratoren berichteten, ein gewöhnlicher Neustart habe den Fehler nicht behoben, nur ein Hard-Reset habe den Dienst zurückgebracht. Einige Hosts sollen speziell nach dem Abmelden des ersten Nutzers ausgefallen sein.

Die führende, von Administratoren verbreitete Erklärung war ein Deadlock zwischen dem RDP-Dienst und dem Local Session Manager, ausgelöst beim Abmelden. Diese Analyse stammte aus der Fehlersuche eines einzelnen Administrators auf einem einzigen Server-2022-Host, und Microsoft hat sie nicht als Ursache bestätigt. Man sollte sie als Arbeitshypothese und nicht als Befund behandeln, doch sie passt zum beobachteten Muster eines Dienstes, der sich verklemmt, sobald Sitzungen abgebaut werden.

Warum RDS-lastige Organisationen es zuerst spürten

Ein defekter Druckwarteschlangendienst ärgert eine Abteilung. Ein defekter RDS-Sitzungshost stoppt die Arbeit für alle, die davon abhängen, und die Abhängigkeitskette ist lang.

RDS ist für viele Organisationen der Standardweg, Windows-Anwendungen an Filialen, Auftragnehmer, Callcenter und Mitarbeiter im Homeoffice bereitzustellen. Ein einzelner Sitzungshost kann Dutzende oder Hunderte gleichzeitige Nutzer tragen, und die Server selbst werden häufig über genau den RDP-Pfad administriert, der gerade ausgefallen ist. Diese Kombination erzeugt eine Rückkopplungsschleife: Der Fernzugriff, auf den Nutzer angewiesen sind, ist ausgefallen, und der Fernzugriff, mit dem Administratoren das beheben, ebenfalls.

• Sitzungshosts, Sprungserver und gateway-nahe Systeme haben den breitesten Wirkungsradius, weil sie geteilte Infrastruktur sind und nicht der Schreibtisch einer einzelnen Person.
• Gehostete Desktop- und VDI-Umgebungen auf Basis von RDS oder Citrix VDAs erben den Fehler über jede veröffentlichte Anwendung.
• Server, die nur über RDP verwaltet werden, ohne Konsole oder Out-of-Band-Management, können schwer erreichbar sein, sobald der Dienst sich verklemmt.

Dazu kommt eine Terminfalle. Der Patch-Day fällt jeden Monat in dasselbe Wartungsfenster, und die meisten Teams patchen nach festem Rhythmus. Wenn ein Defekt Stunden an Nutzeraktivität braucht, um aufzutreten, und das eigene Rollback-Fenster früher schließt, erfährt man davon im Produktivbetrieb.

Der Sicherheitskompromiss, den niemand wollte

Die Ironie der September-Veröffentlichung liegt darin, wie viel Sicherheitsarbeit sie enthielt. Das Security Response Center von Microsoft zählte 974 CVEs in der Veröffentlichung, ein Rekord, während Drittanbieter-Tracker wie Talos, Rapid7, Ivanti, Tenable und CrowdStrike Gesamtzahlen zwischen 964 und 973 meldeten, je nachdem, wie sie Microsoft-, Drittanbieter- und Chromium-Fehler zählen. Nach jedem Maßstab war es die größte an einem Tag veröffentlichte Sammlung des Unternehmens.

Zwei dieser Schwachstellen wurden bereits aktiv ausgenutzt. CVE-2026-81963 ist eine Rechteausweitung im Windows Update Stack mit Bewertung 7,8, die aus einer unsachgemäßen Linkauflösung resultiert. CVE-2026-85880 ist ein heapbasierter Pufferüberlauf in Windows Advanced Local Procedure Call, ebenfalls mit 7,8 bewertet, der es einem lokal angreifenden Angreifer mit geringen Rechten erlaubt, eine AppContainer-Sandbox zu verlassen und SYSTEM zu erreichen. CISA nahm beide am 8. September in seinen Katalog bekannter ausgenutzter Schwachstellen auf, mit einer Behebungsfrist vom 22. September für US-Bundesbehörden.

Dann ist da die Schwachstelle, die den RDS-Ausfall wirklich unangenehm machte. CVE-2026-69525 ist eine Use-after-free-Schwachstelle für entfernte Codeausführung in Remote Desktop Services mit CVSS 9,8 in einem Dienst, der in Unternehmensnetzen häufig exponiert ist. Microsoft stufte sie als wahrscheinlich ausgenutzt ein.

Das schuf eine Wahl ohne gute Antwort. Das Zurückrollen des kumulativen September-Updates stellte Remote Desktop wieder her, wie Administratoren schnell entdeckten. Es entfernte zugleich die Patches für die beiden ausgenutzten Zero-Days und die mit 9,8 bewertete RDS-Schwachstelle, ausgerechnet in dem Dienst, der gerade destabilisiert worden war. Manche Teams gingen diesen Kompromiss ein. Andere warteten.

Microsofts Antwort: zurückrollen ohne Rollback

Bevor die Out-of-Band-Updates eintrafen, war die unterstützte Gegenmaßnahme von Microsoft ein Known Issue Rollback, ein Mechanismus, der die spezifische nicht sicherheitsrelevante Änderung deaktiviert, die für eine Regression verantwortlich ist, und die Sicherheitsfixes des Monats installiert lässt. IT-Connect und andere Medien dokumentierten Gruppenrichtlinien-Pakete, die über das Microsoft-365-Admin-Center statt über die öffentlichen KB-Seiten verteilt wurden, was bedeutete, dass sich die Existenz eines Teils des Fixes per Mundpropaganda verbreitete, bevor Microsoft ihn breit veröffentlichte.

Der kontraintuitive Teil, der in jeder Darstellung wiederkehrt, ist, dass die Richtlinie auf Disabled gesetzt werden muss, um das Rollback zu aktivieren, und das Gerät neu gestartet werden muss. Wird sie auf Enabled gesetzt, bleibt das fehlerhafte Verhalten bestehen.

„In manchen Umgebungen kann RDS instabil werden, sodass RDP-Verbindungen nach mehreren Minuten scheitern, Anmeldeprobleme auftreten oder Server bei ‚Please wait for the Remote Desktop Configuration' hängen bleiben.“ — Microsoft Windows Release Health

Was am 14. September ausgeliefert wurde

Sechs Tage nach dem Patch-Day veröffentlichte Microsoft kumulative Notfall-Pakete außerhalb des regulären Zyklus. Da jedes kumulativ ist, kann eine Maschine, die das Rollup vom 8. September nie installiert hat, es direkt einspielen und erhält dennoch die Sicherheitsinhalte des Monats. Das bedeutet auch, dass ein Administrator, der zurückgerollt hat, die Sicherheitsfixes und die RDS-Reparatur in einem Schritt wiederherstellen kann.

Die Pakete, abgeglichen mit den Supportseiten von Microsoft und der Citrix-Mitteilung CTX697101, sind:

• Windows 11 26H1: KB5129194, Build 28000.2956
• Windows 11 24H2 und 25H2: KB5129195, Builds 26100.9457 und 26200.9457
• Windows 11 24H2 und 25H2 Hotpatch: KB5129241
• Windows 11 23H2: KB5129242
• Windows 10 21H2 und 22H2: KB5129236, Builds 19044.7727 und 19045.7727
• Windows Server 2025: KB5129235, Build 26100.33451
• Windows Server 2022: KB5129237, Build 20348.5631
• Windows Server 2019 und Windows 10 Enterprise LTSC 2019: KB5129238
• Windows Server 2016 und Windows 10 LTSB 2016: KB5129239
• Windows Server 2012 R2 und Server 2012 (ESU): KB5129243 und KB5129244

Ein Detail, das eine Korrektur verdient, weil es sich in den ersten Tagen weit verbreitete: Es gibt einen spezifischen Fix für Server 2019. KB5129238 existiert, und der Release-Health-Eintrag von Microsoft für den Zweig Windows 10 1809 und Server 2019 führt das RDS-Problem inzwischen als dadurch Resolved. Frühe Berichte zu den Notfall-Updates, die nur Pakete für Server 2022 und Server 2025 nannten, wurden ergänzt, nachdem Leser die Auslassung angemerkt hatten.

Die Out-of-Band-Updates behoben zudem eine zweite Regression, die unter dem RDS-Lärm begraben worden war: Anwendungen, die über den Plan9-Anbieter von Hyper-V Windows-Hostordner mit Linux-VMs teilen, konnten freigegebene Ordner als fehlend oder unzugänglich vorfinden. Die Windows-11-Pakete beheben auch das.

Der Audio-Kater

Nicht alles ist behoben. Dieselben Updates vom 8. September machten Geräte mit USB Audio Class 1.0 kaputt; sie starteten mit einem Code-10-Fehler im Geräte-Manager nicht, gaben keinen Ton aus und ließen Lautstärkeregler und Soundeinstellungen nicht reagieren.

Die Out-of-Band-Updates beheben nur einen Teil davon. Die Versionshinweise zu KB5129237 von Microsoft nennen eine Reparatur für Geräte, die in Standardstereo funktionierten, aber in Mehrkanal-Konfigurationen wie 8-Kanal- oder 3D-Audiomodi versagten, und fügen dann ein separates bekanntes Problem hinzu, das klar feststellt, dass andere Audiosymptome nicht behoben sind. Geräte mit Code 10, ohne Ausgabe oder mit toten Lautstärkereglern bleiben betroffen.

Kein Einzelfall

Die September-Regression ist der jüngste Eintrag in einer langen Liste von Patch-Day-Nebenwirkungen. BleepingComputer merkte an, dass Microsoft im März 2025 ein ähnliches bekanntes Problem behob, das nach seit Januar 2025 veröffentlichten Updates zu Verbindungsfehlern bei Remote Desktop und RDS geführt hatte. Die jüngsten Monate brachten zudem Windows-Update-Regressionen, die Drucken und PDF-Export in manchen Anwendungen beeinträchtigten, sowie defekte Papierkorb-Abfragen, die jeweils eigene Nachbesserungen erforderten.

Das Muster ist wichtiger als jeder einzelne Vorfall. Microsoft hat den Anstieg gemeldeter Schwachstellen auf KI-gestützte Schwachstellensuche zurückgeführt, was die September-Veröffentlichung über alles hinaustrieb, was das Unternehmen zuvor ausgeliefert hatte. Mehr Fixes schneller über mehr Codepfade auszuliefern erhöht die Wahrscheinlichkeit, dass einer davon das Verhalten auf eine Weise ändert, die niemand getestet hat. Der kommerzielle Druck wirkt auch in die andere Richtung: Sobald eine Schwachstelle öffentlich und manchmal bereits ausgenutzt ist, hat es eigene Kosten, ein Update zurückzuhalten.

Für die Teams auf der Empfängerseite ist die Lehre eher operativ als technisch. Ein Patch, der einen Schnelltest besteht, ist nicht getestet. RDS-Sitzungshosts und alles mit geteiltem Schicksal verdienen einen gestaffelten Rollout, einen dokumentierten Rollback-Pfad und einen Out-of-Band-Managementweg, der nicht über den gerade gepatchten Dienst läuft. Und wenn das Update, das alles kaputt gemacht hat, zugleich das ist, das eine mit 9,8 bewertete Lücke zur entfernten Codeausführung geschlossen hat, braucht die Entscheidung, zu warten oder zurückzurollen, eine kompensierende Kontrolle und nicht nur ein Wartungsticket.

Microsoft hat nicht gesagt, ob die September-Fixes in ein überarbeitetes monatliches Rollup einfließen oder dem Oktober-Patch-Day überlassen werden. Bis dahin ist die sicherste Lesart der Release-Health-Seiten Zweig für Zweig: Die meisten sind Resolved, die USB-Audio-Einträge nicht.

Aufmacherbild: Serverraum-Foto von Carl Lender, CC BY 2.0, via Wikimedia Commons.