Erinnern Sie sich an den September-Patchday? Knapp tausend geschlossene Lücken, der größte Patch Tuesday aller Zeiten, zwei aktiv ausgenutzte Zero-Days, das ganze angetrieben von Microsofts neuer KI-gestützter Schwachstellensuche. Ein Kraftakt. Man möchte fast applaudieren.
Dann spielt man die Updates ein und stellt fest, dass die Kur schlimmer ist als die Krankheit. Innerhalb von 48 Stunden meldeten Administratoren weltweit dasselbe Muster: Terminalserver, die nach ein paar Stunden einfrieren. Windows-11-Clients, die ihre Vertrauensstellung zur Domäne verlieren und sich nicht mehr anmelden lassen. Schwarze Bildschirme. BitLocker-Fehler bei jedem Neustart. Rechner, die nach dem Secure-Boot-Update gar nicht mehr hochkommen. Man hat 966 Löcher gestopft und dafür vier neue Baustellen aufgerissen. Willkommen zur Nachlese.
Remote Desktop Services: gepatcht und tot
Das prominenteste Problem trifft ausgerechnet die Remotedesktopdienste. Nach der Installation der September-Updates auf Windows Server 2019 (KB5122876), 2022 (KB5122882) und 2025 (KB5122871) laufen die RDS-Server zunächst ein paar Stunden normal. Dann klemmt es: Neue RDP-Verbindungen bleiben dauerhaft im Status „Verbindung wird hergestellt“ hängen, bestehende Sitzungen lassen sich nicht mehr sauber trennen oder abmelden. Besonders perfide ist ein zweites Fehlerbild, das mehrere Administratoren unabhängig voneinander beschreiben: Sobald sich der erste Nutzer abmeldet, stürzt der Dienst ab, und danach kommt niemand mehr herein. Nicht einmal der Task-Manager lässt sich noch als Administrator starten. Ein Neustart hilft nicht. Was hilft, ist ein harter Reset und anschließend die Deinstallation des Updates.
Ein Administrator hat den Hänger auf Server 2022 bis in die Funktion WDLIB_Close zurückverfolgt und vermutet einen Deadlock zwischen dem RDP-Stack und dem Local Session Manager, also genau beim Abbau einer Sitzung. Das ist eine plausible, aber unbestätigte Fremddiagnose. Und jetzt der eigentliche Treppenwitz: Das September-Paket schließt vier Schwachstellen, die direkt in den Remotedesktopdiensten sitzen, darunter CVE-2026-69525 mit einem CVSS-Wert von 9,8. Aus dem Netz erreichbar, ohne Anmeldung, ohne Zutun des Nutzers. Genau die Art Lücke, die man sofort schließen will. Nur nimmt das Update, das sie schließt, den Dienst gleich mit. Sie haben also die Wahl zwischen einem gepatchten, aber toten Terminalserver und einem laufenden, aber verwundbaren. Danke für nichts.
Als Sahnehäubchen deutet einiges darauf hin, dass die Ursache in derselben Komponente steckt, die Microsoft in den Release Notes als Verbesserung anpreist: die Audioweiterleitung in Remote-Desktop-Sitzungen. Eine Tonspur-Korrektur, die die komplette Anmeldung lahmlegt. Man muss es erst einmal schaffen.
Domänen-Vertrauensstellung: Sicherheit, die Sicherheit bricht
Der zweite große Ausfall betrifft die Clients. Nach der Installation von KB5124008 auf domänengebundenen Windows-11-Arbeitsstationen verlieren betroffene Rechner ihren sicheren Domänenkanal. Die Symptome sind eindeutig: nltest meldet „ERROR_NO_TRUST_LSA_SECRET“ (1786), eine interaktive Anmeldung ist nicht mehr möglich, und zwischengespeicherte Anmeldeinformationen funktionieren offline weiterhin. Letzteres verrät, wo es klemmt: Die Vertrauensbeziehung des Computerkontos ist auf Ebene des LSA-Geheimnisses gerissen. Besonders zuverlässig tritt der Effekt bei Geräten auf, die sich per VPN verbinden.
Die vermutete Ursache ist an Ironie kaum zu überbieten. Laut einem Moderator im Microsoft-Learn-Forum hat Microsoft die Anforderungen an den sicheren Netlogon-Kanal in den jüngsten kumulativen Updates verschärft, also strengere Schlüsselaushandlung und Signierung erzwungen. Auf Server-2019-Domänencontrollern scheitert der Handshake dann, weil der Client strengere Anforderungen durchsetzt, als die Domänencontroller anbieten. Kurz gesagt: Microsoft härtet den Kanal, der das Vertrauen absichern soll, und bricht dabei genau dieses Vertrauen. Eine Sicherheitsmaßnahme, die die Anmeldung an der eigenen Domäne verhindert. Sicherer ist der Rechner damit zweifellos, denn niemand kommt mehr rein, auch nicht der rechtmäßige Nutzer.
Der Rest des Trümmerfelds
Damit nicht genug. Die Nachlese fördert eine ganze Reihe kleinerer, aber ärgerlicher Baustellen zutage:
Schwarze Bildschirme in RDP- und Hyper-V-Sitzungen, bei denen nur noch der Mauszeiger sichtbar ist. Ursache in mindestens einem gut dokumentierten Fall: Das Update hat den installierten Grafiktreiber durch den generischen Windows-Treiber ersetzt. Die manuelle Neuinstallation des richtigen Treibers und ein Neustart bringen die Sitzung zurück.
BitLocker mit Event-ID 24641 nach jedem Reboot, das über einen Fehler beim Abruf des Volume-Master-Keys klagt. Immerhin bleiben die Laufwerke offenbar zugänglich, das Ganze ist also eher kosmetisch. Beruhigend, wenn die Verschlüsselung nur so tut, als wäre etwas kaputt.
Die Secure-Boot-Falle. Das Secure-Boot-Update erwartet eine WinRE-Partition von rund 750 MB. Ist sie kleiner, versucht Windows Update sie zu vergrößern, was schiefgehen und den Rechner am Booten hindern kann. Bonuspunkt: Microsofts eigene Größenempfehlungen im Web widersprechen sich, je nachdem, welche Seite man erwischt. Wer soll da noch die richtige Partitionsgröße kennen?
Dazu kommen vereinzelte Update-Installationen, die nach dem ersten Reboot per Rollback wieder verschwinden, ein .NET-Update, das den Windows-Start torpediert, und eine kaputte Kopierfunktion in Excel nach dem zugehörigen Office-Update. Copy und Paste in einer Tabellenkalkulation. 2026.
„Aber die KI findet doch so viele Lücken“
Man kann das alles als Pech abtun, als unglückliche Häufung. Nur ist es keine. Der August hat den Druck von WPF-Anwendungen genommen, indem er das Drucken und den PDF-Export in ihnen zerlegte. Auf Windows Server 2016 warfen die August-Updates reihenweise 0xc0000409-Fehler. Und während Administratoren noch mit den September-Trümmern kämpfen, macht bereits eine frische Defender-Zero-Day namens „ShieldCrash“ die Runde, die Microsofts jüngsten Patch aushebelt. Es ist ein Muster, kein Ausrutscher.
Und hier wird es dann grundsätzlich. Microsoft rühmt sich, dank KI-gestützter Analyse inzwischen fast tausend Schwachstellen pro Monat aufzuspüren. Schön für die Statistik. Nur nützt die beste Schwachstellensuche der Welt wenig, wenn das Update, das eine Lücke schließt, den Server gleich mit abräumt. Softwarequalität misst sich nicht an der Zahl der gefundenen Bugs, sondern an der Zahl der Updates, die sauber durchlaufen. Eine KI, die Lücken findet, aber keine, die dafür sorgt, dass der Fix niemanden aussperrt, verschiebt das Problem nur von der einen auf die andere Seite. Am Ende steht der Administrator, der abwägen muss, ob die aktiv ausgenutzte Zero-Day oder der eigene Patch das größere Risiko ist. Das ist kein Fortschritt, das ist eine Zumutung.
Was Microsoft (nicht) bestätigt
Der Vollständigkeit halber, weil es zum Bild passt: Zu den RDS-Ausfällen hat Microsoft gegenüber BleepingComputer inzwischen immerhin eingeräumt, die Berichte zu kennen und zu untersuchen. Eine bestätigte Ursache, ein Fix oder ein offizieller Workaround fehlen bislang, ebenso ein Eintrag im Windows Release Health Dashboard. Die Deadlock-Theorie stammt von Administratoren, nicht von Microsoft.
Zum Verlust der Domänen-Vertrauensstellung, zu den schwarzen Bildschirmen, zum BitLocker-Fehler und zur Secure-Boot-Falle gibt es Stand jetzt überhaupt keine offizielle Stellungnahme, kein bestätigtes Known Issue und keinen Known Issue Rollback. Wer betroffen ist, ist auf Community-Wissen und Eigeninitiative angewiesen. Das ist bei einem Update dieser Tragweite, das zwei aktiv ausgenutzte Zero-Days schließt, bemerkenswert dünn.
Was Sie jetzt tun sollten
So verlockend es nach dieser Aufzählung ist, den September-Patchday komplett zu überspringen: Tun Sie es nicht. Die beiden Zero-Days werden real angegriffen, und die Netzwerk-RCEs in DNS, DHCP und Co. sind kein Papiertiger. Die Antwort heißt nicht „nicht patchen“, sondern „gezielt patchen“. Konkret:
Trennen Sie Clients und Server. Die aktuell dokumentierten Totalausfälle betreffen vor allem RDS-/Terminalserver und den Domänenkanal. Rollen Sie die Client-Updates dort aus, wo die Zero-Days am meisten wehtun, also zuerst auf exponierten und sensiblen Endgeräten. Halten Sie im Gegenzug die kumulativen Server-Updates auf produktiven Terminalservern zurück, bis Microsoft nachbessert, und flankieren Sie das mit einer strengen Beschränkung der RDP-Exposition (kein RDP ins Internet, RD-Gateway, MFA, Netzsegmentierung).
Testen Sie vor der Fläche. Ein Testring aus repräsentativen Geräten hätte in diesem Monat mehr gebracht als jede Release Note. Wer erst auf einer Handvoll Maschinen prüft und dann breit ausrollt, fängt genau solche Regressionen ab, bevor sie den Betrieb treffen.
Halten Sie die Workarounds bereit, falls es Sie doch erwischt. Bei toten RDS-Servern hilft zuverlässig nur die Deinstallation des jeweiligen Server-Updates (KB5122876, KB5122882 oder KB5122871), zur Not per DISM, samt vorübergehendem Pausieren der Updates. Ein bloßer Neustart genügt nicht. Bei gebrochener Domänen-Vertrauensstellung nach KB5124008 gibt es drei Wege: das Update deinstallieren, den Rechner aus der Domäne nehmen und neu beitreten, oder den sicheren Kanal mit Domänen-Administratorrechten reparieren (etwa über Test-ComputerSecureChannel -Repair beziehungsweise Reset-ComputerMachinePassword). Beim schwarzen Bildschirm installieren Sie den korrekten Grafiktreiber neu. Und vor dem Secure-Boot-Update lohnt der Blick auf die Größe der WinRE-Partition.
Kurz: Priorisieren Sie nach tatsächlicher Ausnutzung, staffeln Sie den Rollout, und behalten Sie das Windows Release Health Dashboard im Auge, falls Microsoft doch noch einen Known Issue Rollback oder einen sauberen Fix nachreicht.
Fazit
Der September 2026 ist ein Lehrstück. Nicht darüber, wie gefährlich die Bedrohungslage ist, das wissen wir. Sondern darüber, dass der größte Feind eines gut gewarteten Systems inzwischen der Hersteller selbst sein kann. Ein Patchday, der zwei aktiv ausgenutzte Zero-Days schließt und im selben Atemzug Terminalserver, Domänenanmeldung und Bildschirme lahmlegt, ist kein Sicherheitsgewinn, sondern ein Nullsummenspiel mit Extra-Arbeit. Solange die Update-Qualität so bleibt, ist die eigentliche Kunst nicht mehr das Patchen, sondern das Überleben des Patches. Und keine noch so kluge KI ändert daran etwas, solange sie nur die Lücken zählt und nicht die Scherben.
Nachtrag (11. September 2026): Der chirurgische RDS-Fix, mit Dank an LazyAdmin
Kurz nach Veröffentlichung dieses Beitrags hat Rudy Mens auf LazyAdmin einen Weg dokumentiert, der die oben empfohlene RDS-Deinstallation überflüssig macht und die Sicherheitspatches erhält. Weil das genau die Lücke schließt, die dieser Artikel offengelassen hatte, hier die Kurzfassung mit Verweis auf die Originalquelle.
Die Ursache lässt sich damit erstmals benennen, weiterhin ohne offizielle Microsoft-Bestätigung. Beim Sitzungsabbau ruft die Routine RDPSERVERBASE!WDLIB_Close die Funktion RtlWaitOnAddress ohne Timeout auf, sobald ein bestimmtes internes Feature-Flag mit der Nummer 3802373433 aktiv ist. Der Thread wartet dann endlos. Da der Local Session Manager sämtliche Änderungen am Sitzungszustand über einen einzigen kritischen Abschnitt serialisiert, blockiert dieser hängende Thread alles Nachfolgende, also neue Verbindungen, Abmeldungen und Broker-Anfragen, bis zum harten Reset.
Betroffen sind alle aktuellen Server-Versionen über ihre September-CUs, und zwar etwas weiter gefasst als anfangs berichtet auch Server 2016: KB5123099 (Server 2016), KB5122876 (Server 2019), KB5122882 (Server 2022, Build 20348.5622) und KB5122871 (Server 2025, Build 26100.33438).
Ob ein Host tatsächlich diesen Defekt hat, verraten drei Signaturen: Event 20498 (Quelle TerminalServices-RemoteConnectionManager) über eine zu lange dauernde Client-Verbindung, Event 6005 (Winlogon) über eine hängende SessionEnv-Benachrichtigung beim Disconnect, sowie der Dienst TermService im Status StopPending statt Running.
Wichtig vorab: Es handelt sich um einen inoffiziellen Eingriff in eine undokumentierte Windows-Funktion. Testen Sie ihn zuerst auf einem unkritischen Host und legen Sie die unten genannte Sicherung an.
Der Fix für noch erreichbare Hosts deaktiviert gezielt das fehlerhafte Feature-Flag per Registry-Override und lässt alle Sicherheitspatches installiert. Zuerst die vorhandenen Overrides sichern:
powershell
New-Item -Path C:\temp -ItemType Directory -Force | Out-Null
reg export "HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides" C:\temp\FeatureOverrides-backup.regDann den Override setzen. Der Zweig 4 steht für die Priorität und passt in den meisten Umgebungen; bei bereits vorhandenen Overrides vorher die exportierte .reg prüfen:
powershell
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\4\3802373433" -Force
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\4\3802373433" -Name "EnabledState" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\4\3802373433" -Name "EnabledStateOptions" -Value 0 -Type DWordDer Override greift nach einem Neustart des Dienstes TermService. Ein kompletter Server-Neustart ist nicht nötig, die aktiven RDP-Sitzungen werden dabei aber getrennt:
powershell
Restart-Service -Name TermService -ForceAnschließend 24 bis 48 Stunden lang auf die Events 20498 und 6005 achten, vor allem rund um Abmeldungen. Tauchen sie nicht wieder auf und bleibt TermService auf Running, hält der Override.
Für bereits blockierte, nicht mehr erreichbare Hosts bleibt nur der harte Reset und danach das Entfernen des September-CU, bevor der Deadlock erneut zuschlägt. Ein wichtiges Detail: wusa /uninstall /kb:5122882 scheitert, weil die September-Updates als kombiniertes Paket aus Servicing Stack Update (SSU) und kumulativem Update ausgeliefert werden. Das SSU lässt sich nicht entfernen, also weist der Installer das gesamte Paket ab. Der Weg führt über DISM:
powershell
dism.exe /Online /Get-Packages /Format:Table | findstr /i "Package_for_RollupFix"
dism.exe /Online /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~20348.5622.1.2 /NoRestartDen Paketnamen aus der ersten Zeile exakt übernehmen; der SSU-Anteil bleibt erwartungsgemäß installiert. Danach die KB gegen die automatische Neuinstallation sperren, per WSUS-Ablehnung oder GPO-Verzögerung.
Zwei Einordnungen zum Schluss. Erstens, ganz praktisch: Der Feature-Flag-Override ist die klar bessere Wahl, weil die DISM-Deinstallation sämtliche September-Patches entfernt, inklusive des Fixes für die 9,8er-RDS-Lücke CVE-2026-69525. Reservieren Sie den Rollback für Hosts, die ohnehin schon tot sind. Zweitens, mit dem gebotenen Sarkasmus: Es ist bezeichnend, dass die brauchbarste Handlungsanleitung zu diesem Schlamassel nicht vom Hersteller kommt, sondern von einem einzelnen Blogger, der Microsofts undokumentiertes Feature-Flag reverse-engineert hat. Ein offizieller Fix oder ein Known Issue Rollback fehlen weiterhin. Sobald Microsoft nachliefert, aktualisiere ich diesen Beitrag.